ਤੁਸੀਂ ਸ਼ੁੱਕਰਵਾਰ ਨੂੰ ਚਾਰ ਵਜੇ ਇੱਕ ਫਿਕਸ ਪੁਸ਼ ਕਰਦੇ ਹੋ। ਸ਼ਨੀਵਾਰ ਸਵੇਰ ਤੱਕ, ਅਲਰਟ ਵੱਜਣ ਲੱਗ ਪੈਂਦੇ ਹਨ। ਤੁਸੀਂ ਇਸ ਘਟਨਾ ਦਾ ਪਤਾ ਅਠਾਰਾਂ ਘੰਟੇ ਪਹਿਲਾਂ ਮਰਜ ਕੀਤੇ ਗਏ ਇੱਕ pull request ਤੱਕ ਲਗਾਉਂਦੇ ਹੋ। ਬ੍ਰਾਂਚ ਕੰਪਾਈਲ ਹੋ ਗਈ, ਟੈਸਟ ਪਾਸ ਹੋ ਗਏ, ਪਰ PR description ਖਾਲੀ ਹੈ। ਇਸ ਨਾਲ ਕੋਈ work item ਲਿੰਕ ਨਹੀਂ ਹੈ। ਅਪਰੂਵਲ ਹਿਸਟਰੀ ਵਿੱਚ ਕੁਝ ਵੀ ਨਹੀਂ ਦਿਖ ਰਿਹਾ। ਤੁਸੀਂ ਇੱਕ 'ghost merge' ਦੇਖ ਰਹੇ ਹੋ, ਅਤੇ ਹੁਣ ਤੁਸੀਂ ਆਪਣੇ ਵੀਕੈਂਡ ਦਾ ਸਮਾਂ ਉਸ ਗੜਬੜ ਨੂੰ ਸਾਫ਼ ਕਰਨ ਵਿੱਚ ਬਿਤਾ ਰਹੇ ਹੋ ਜੋ main ਬ੍ਰਾਂਚ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਫੜੀ ਜਾਣੀ ਚਾਹੀਦੀ ਸੀ।

ਛੋਟੀਆਂ ਟੀਮਾਂ ਹਰ ਰੋਜ਼ ਇਸ ਜੋਖਮ ਨਾਲ ਜਿਉਂਦੀਆਂ ਹਨ। ਤੁਹਾਡੇ ਕੋਲ ਹਰ ਮਰਜ 'ਤੇ ਨਜ਼ਰ ਰੱਖਣ ਵਾਲਾ ਕੋਈ ਰਿਲੀਜ਼ ਮੈਨੇਜਰ ਨਹੀਂ ਹੈ। ਤੁਹਾਡੇ ਕੋਲ ਬੇਸਪੋਕ (bespoke) ਪਾਲਿਸੀ ਇੰਜਣ ਬਣਾਉਣ ਵਾਲੀ ਕੋਈ ਪਲੇਟਫਾਰਮ ਟੀਮ ਨਹੀਂ ਹੈ। ਤੁਹਾਡੇ ਕੋਲ Azure DevOps ਹੈ, ਅਤੇ ਇਸ ਦੀਆਂ ਬਿਲਟ-ਇਨ ਬ੍ਰਾਂਚ ਪਾਲਿਸੀਆਂ ਇੱਕ ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਸਾਧਨ ਹਨ। ਇਹ ਜਾਂ ਤਾਂ ਦਰਵਾਜ਼ਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਕਰ ਦਿੰਦੀਆਂ ਹਨ ਜਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖੁੱਲ੍ਹਾ ਛੱਡ ਦਿੰਦੀਆਂ ਹਨ। ਦੋ ਰਿਵਿਊਅਰਾਂ ਦੀ ਮੰਗ ਕਰੋ ਅਤੇ ਤੁਸੀਂ ਜ਼ਰੂਰੀ hotfixes ਨੂੰ ਰੋਕ ਦਿੰਦੇ ਹੋ। ਨਿਯਮਾਂ ਨੂੰ ਢਿੱਲਾ ਛੱਡੋ ਅਤੇ ਬਿਨਾਂ ਟਿਕਟ ਵਾਲੇ ਬਦਲਾਅ ਦੇ ਨਾਲ ਖਾਲੀ description ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਚਲੇ ਜਾਂਦੇ ਹਨ। ਇੱਥੇ ਬਹੁਤ ਘੱਟ ਹੀ ਕੋਈ ਵਿਚਕਾਰਲਾ ਰਸਤਾ ਮਿਲਦਾ ਹੈ।

ਉਸੇ ਖਾਲੀਪਣ ਕਾਰਨ ਅਸੀਂ Gatekeeper ਬਣਾਇਆ ਹੈ। ਇਹ Azure DevOps ਲਈ ਖਾਸ ਤੌਰ 'ਤੇ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਇੱਕ AI-ਪਾਵਰਡ PR ਰਿਵਿਊ ਡੈਸਕ ਹੈ, ਪਰ ਆਧੁਨਿਕ ਡਿਵੈਲਪਰ ਟੂਲਜ਼ ਬਾਰੇ ਤੁਸੀਂ ਜੋ ਵੀ ਮੰਨਦੇ ਹੋ, ਉਸ ਨੂੰ ਭੁੱਲ ਜਾਓ। ਇਸ ਵਿੱਚ ਕੋਈ Docker ਕੰਟੇਨਰ, ਕੋਈ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਪਲਾਨ, ਅਤੇ ਕੋਈ ਕਲਾਉਡ ਡਿਪਲਾਈਮੈਂਟ ਪਾਈਪਲਾਈਨ ਨਹੀਂ ਹੈ। Gatekeeper ਇੱਕ ਸਿੰਗਲ HTML ਫਾਈਲ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਆਪਣੇ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਖੋਲ੍ਹਦੇ ਹੋ, ਚਾਰ ਵੈਲਯੂਜ਼ ਭਰਦੇ ਹੋ, ਅਤੇ ਇੱਕ ਬਟਨ ਦਬਾਉਂਦੇ ਹੋ। ਫਿਰ ਇਹ ਟੂਲ ਤਿੰਨ ਸਧਾਰਨ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਕੀ ਇਹ PR ਕਿਸੇ ਟਿਕਟ ਨਾਲ ਲਿੰਕ ਹੈ? ਕੀ ਕਿਸੇ ਇਨਸਾਨ ਨੇ ਅਸਲ ਵਿੱਚ ਇਸਦੀ ਰਿਵਿਊ ਕੀਤੀ ਹੈ? ਅਤੇ ਕੀ ਕੋਡ ਦੀ ਕੁਆਲਿਟੀ ਚੰਗੀ ਹੈ?

ਸਭ ਕੁਝ ਇੱਕ ਸਵੈ-ਨਿਰਭਰ (self-contained) ਫਾਈਲ ਵਿੱਚ ਪੈਕੇਜ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੋਈ ਚਮਕ-ਧਮਕ ਨਹੀਂ ਸੀ। ਇਹ ਅਸਲ ਕਾਰਜਸ਼ੀਲ (operational) ਮੁਸ਼ਕਲਾਂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ। ਪਹਿਲਾ, ਇਸ ਨੂੰ ਹੋਸਟ ਕਰਨ ਜਾਂ ਇਸ ਲਈ ਭੁਗਤਾਨ ਕਰਨ ਲਈ ਕੋਈ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਨਹੀਂ ਹੈ। ਤੁਸੀਂ ਕੋਈ App Service ਪ੍ਰੋਵੀਜ਼ਨ ਨਹੀਂ ਕਰ ਰਹੇ ਹੋ ਜਾਂ egress costs ਬਾਰੇ ਚਿੰਤਾ ਨਹੀਂ ਕਰ ਰਹੇ ਹੋ। ਦੂਜਾ, ਕ੍ਰੈਡੈਂਸ਼ੀਅਲਜ਼ ਕਦੇ ਵੀ ਤੁਹਾਡੀ ਮਸ਼ੀਨ ਤੋਂ ਬਾਹਰ ਨਹੀਂ ਜਾਂਦੇ। ਤੁਹਾਡਾ Azure DevOps personal access token ਸਿਰਫ਼ ਬ੍ਰਾਊਜ਼ਰ ਮੈਮੋਰੀ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਪੇਜ ਨੂੰ ਰਿਫ੍ਰੈਸ਼ ਕਰਦੇ ਹੀ ਖ਼ਤਮ ਹੋ ਜਾਂਦਾ ਹੈ। ਲੀਕ ਹੋਣ ਲਈ ਕੋਈ ਸੀਕਰੇਟਸ (secrets) ਦਾ ਡੇਟਾਬੇਸ ਨਹੀਂ ਹੈ ਅਤੇ ਕਿਸੇ OAuth ਸਰਵਰ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਤੀਜਾ, ਇਸ ਨੂੰ ਅਪਣਾਉਣਾ ਬਹੁਤ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਕਿਸੇ ਨੂੰ ਵੀ wiki ਰਾਹੀਂ onboard ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਤੁਸੀਂ ਫਾਈਲ ਨੂੰ ਈਮੇਲ ਨਾਲ ਅਟੈਚ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ Slack thread ਵਿੱਚ ਪਾ ਸਕਦੇ ਹੋ। ਪ੍ਰਾਪਤਕਰਤਾ ਇਸਨੂੰ ਖੋਲ੍ਹਦਾ ਹੈ ਅਤੇ ਤੁਰੰਤ ਰਿਵਿਊ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ।

Fact Layer: ਪਹਿਲਾਂ ਨਿਰਧਾਰਵਾਦ (Determinism)

Gatekeeper ਆਪਣੇ ਰਿਵਿਊ ਨੂੰ ਦੋ ਵੱਖ-ਵੱਖ ਲੇਅਰਾਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ, ਅਤੇ ਇਹ ਵੱਖਰੇਵੇਂ ਦੀ ਉਸਦੀ ਭਰੋਸੇਯੋਗਤਾ ਦੀ ਰੀੜ੍ਹ ਦੀ ਹੱਡੀ ਹੈ।

ਪਹਿਲੀ ਲੇਅਰ ਸ਼ੁੱਧ JavaScript ਹੈ ਜੋ ਸਿੱਧਾ Azure DevOps REST API ਨਾਲ ਗੱਲ ਕਰਦੀ ਹੈ। ਇਹ ਉਹਨਾਂ ਤੱਥਾਂ ਦੀ ਜਾਂਚ ਕਰਦੀ ਹੈ ਜੋ ਬਦਲਦੇ ਨਹੀਂ ਹਨ। ਜਾਂ ਤਾਂ ਇੱਕ pull request ਕਿਸੇ work item ਨਾਲ ਲਿੰਕ ਹੈ, ਜਾਂ ਨਹੀਂ ਹੈ। ਜਾਂ ਤਾਂ ਕਿਸੇ ਰਿਵਿਊਅਰ ਨੇ ਅਪਰੂਵਲ ਵੋਟ ਦਿੱਤੀ ਹੈ, ਜਾਂ ਨਹੀਂ। description ਜਾਂ ਤਾਂ ਖਾਲੀ ਹੈ, ਜਾਂ ਇਸ ਵਿੱਚ ਅਸਲ ਵਾਕ ਹਨ। ਸਰਗਰਮ ਚਰਚਾਵਾਂ (discussions) ਜਾਂ ਤਾਂ ਹੱਲ ਹੋ ਚੁੱਕੀਆਂ ਹਨ, ਜਾਂ ਉਹ ਅਜੇ ਵੀ ਖੁੱਲ੍ਹੀਆਂ ਹਨ।

ਖਾਸ ਤੌਰ 'ਤੇ, Fact Layer ਚਾਰ ਚੀਜ਼ਾਂ ਲੱਭਦੀ ਹੈ:

  • Ticket mapping: ਕੀ PR ਘੱਟੋ-ਘੱਟ ਇੱਕ work item ਨਾਲ ਲਿੰਕ ਹੈ?
  • Reviewer sign-off: ਕੀ ਕਿਸੇ ਨੇ ਅਪਰੂਵ ਕਰਨ ਲਈ ਵੋਟ ਦਿੱਤੀ ਹੈ, ਜਾਂ ਗਿਣਤੀ ਅਜੇ ਵੀ ਜ਼ੀਰੋ ਹੈ?
  • Description quality: ਕੀ description ਖਾਲੀ ਹੈ, ਜਾਂ ਸਿਰਫ਼ ਇੱਕ ਛੋਟਾ ਜਿਹਾ placeholder ਹੈ?
  • Open discussions: ਕੀ ਕੋਈ ਅਣਸੁਲਝੇ comment threads ਜਵਾਬ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਹਨ?

ਇਹ ਚੈੱਕ ਪੇਜ 'ਤੇ ਵਿਜ਼ੂਅਲ ਸਟੈਂਪ (visual stamps) ਪੈਦਾ ਕਰਦੇ ਹਨ। ਇੱਕ ਵੱਡਾ ਲਾਲ NOT MAPPED ਸਟੈਂਪ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ। ਇੱਕ ਟੇਬਲ ਸੈੱਲ ਵਿੱਚ ਲੁਕਿਆ ਹੋਇਆ ਛੋਟਾ ਹਰਾ ਚੈੱਕਮਾਰਕ ਦੇਖਣਾ ਆਸਾਨ ਹੈ। ਅਸੀਂ ਜਲਦੀ ਹੀ ਸਿੱਖ ਲਿਆ ਸੀ ਕਿ ਪ੍ਰਕਿਰਿਆ ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਉੱਚੀ (loud) ਹੋਣ ਦੀ ਲੋੜ ਹੈ। ਜਦੋਂ ਕੋਈ ਡਿਵੈਲਪਰ ਮਰਜ ਕਰਨ ਦੀ ਕਾਹਲੀ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਸੂਖਮਤਾ ਕੰਮ ਨਹੀਂ ਕਰਦੀ। Fact Layer ਦਾ ਮਕਸਦ ਅਸਪਸ਼ਟਤਾ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ ਕਰਨਾ ਹੈ।

ਕਿਉਂਕਿ ਇਹ ਲੇਅਰ ਨਿਰਧਾਰਤ (deterministic) API ਪ੍ਰਤੀਕਿਰਿਆਵਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਇਸਦੀ ਸ਼ੁੱਧਤਾ ਪੂਰਨ ਹੈ। ਜੇਕਰ ਸਟੈਂਪ NO APPROVAL ਕਹਿੰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਯਕੀਨ ਨਾਲ ਕਹਿ ਸਕਦੇ ਹੋ ਕਿ ਕਿਸੇ ਨੇ ਵੀ ਅਪਰੂਵ ਬਟਨ 'ਤੇ ਕਲਿੱਕ ਨਹੀਂ