You push a fix at four on a Friday. By Saturday morning, alerts are ringing. You trace the incident to a pull request me

നിങ്ങൾ വെള്ളിയാഴ്ച നാലുമണിക്ക് ഒരു ഫിക്സ് പഷ് ചെയ്യുന്നു. ശനിയാഴ്ച രാവിലെയാകുമ്പോഴേക്കും അലേർട്ടുകൾ മുഴങ്ങിക്കൊണ്ടിരിക്കുന്നു. പതിനെട്ട് മണിക്കൂർ മുമ്പ് മെർജ് ചെയ്ത ഒരു pull request-ലൂടെയാണ് ഈ പ്രശ്നം ഉണ്ടായതെന്ന് നിങ്ങൾ കണ്ടെത്തുന്നു. ബ്രാഞ്ച് കംപൈൽ ചെയ്തു, ടെസ്റ്റുകൾ പാസായി, പക്ഷേ PR ഡിസ്ക്രിപ്ഷൻ ശൂന്യമാണ്. ഇതിലേക്ക് ലിങ്ക് ചെയ്തിട്ടുള്ള ഒരു വർക്ക് ഐറ്റവും ഇല്ല. അപ്രൂവൽ ഹിസ്റ്ററിയിൽ ഒന്നും കാണുന്നില്ല. നിങ്ങൾ ഒരു ghost merge ആണ് കാണുന്നത്, മെയിൻ ബ്രാഞ്ചിൽ എത്തുന്നതിന് മുമ്പ് തന്നെ കണ്ടുപിടിക്കേണ്ടിയിരുന്ന ഒരു പ്രശ്നം പരിഹരിക്കാൻ ഇപ്പോൾ നിങ്ങളുടെ വാരാന്ത്യം ചെലവഴിക്കേണ്ടി വരുന്നു.

ചെറിയ ടീമുകൾ എല്ലാ ദിവസവും ഈ റിസ്ക് നേരിടുന്നുണ്ട്. ഓരോ മെർജിന്മേലും നിരീക്ഷണം നടത്താൻ ഒരു റിലീസ് മാനേജരോ, പ്രത്യേക പോളിസി എൻജിനുകൾ നിർമ്മിക്കാൻ ഒരു പ്ലാറ്റ്‌ഫോം ടീമോ നിങ്ങളുടെ പക്കലില്ല. നിങ്ങളുടെ പക്കൽ Azure DevOps ഉണ്ട്, അതിന്റെ ഇൻബിൽറ്റ് ബ്രാഞ്ച് പോളിസികൾ വളരെ പരിമിതമാണ്. അവ ഒന്നുകിൽ കടുത്ത നിയന്ത്രണങ്ങൾ ഏർപ്പെടുത്തും അല്ലെങ്കിൽ വളരെ അയഞ്ഞതാകുകയും ചെയ്യും. രണ്ട് റിവ്യൂവർമാരെ ആവശ്യപ്പെടുമ്പോൾ അടിയന്തരമായ hotfixes തടസ്സപ്പെടുന്നു. നിയമങ്ങൾ ലഘൂകരിച്ചാൽ, ടിക്കറ്റുകൾ ഇല്ലാത്ത മാറ്റങ്ങൾക്കൊപ്പം ശൂന്യമായ ഡിസ്ക്രിപ്ഷനുകളും പ്രൊഡക്ഷനിലേക്ക് എത്തുന്നു. ഇതിനിടയിലുള്ള ഒരു മിതപാത കണ്ടെത്തുക എന്നത് പ്രയാസകരമാണ്.

ആ വിടവ് നികത്താനാണ് ഞങ്ങൾ Gatekeeper നിർമ്മിച്ചത്. ഇത് Azure DevOps-നായി പ്രത്യേകം രൂപകൽപ്പന ചെയ്ത ഒരു AI-powered PR review ഡെസ്ക് ആണ്, എന്നാൽ ആധുനിക ഡെവലപ്പർ ടൂളുകളെക്കുറിച്ച് നിങ്ങൾ കരുതുന്നതെല്ലാം മറന്നേക്കൂ. ഇതിൽ Docker container-ഓ, സബ്‌സ്‌ക്രിപ്ഷൻ പ്ലാനോ, ക്ലൗഡ് ഡിപ്ലോയ്‌മെന്റ് പൈപ്പ്‌ലൈനോ ഇല്ല. Gatekeeper എന്നത് ഒരു സിംഗിൾ HTML ഫയൽ മാത്രമാണ്. നിങ്ങൾ ഇത് ബ്രൗസറിൽ തുറന്ന്, നാല് മൂല്യങ്ങൾ നൽകി ഒരു ബട്ടൺ അമർത്തുക മാത്രം ചെയ്താൽ മതി. തുടർന്ന് ഈ ടൂൾ മൂന്ന് ലളിതമായ ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു: ഈ PR ഒരു ടിക്കറ്റുമായി ബന്ധപ്പെട്ടിട്ടുണ്ടോ? ഒരു മനുഷ്യൻ ഇത് യഥാർത്ഥത്തിൽ റിവ്യൂ ചെയ്തോ? കോഡിന്റെ ഗുണനിലവാരം എങ്ങനെയുണ്ട്?

എല്ലാം ഒരു ഫയലിൽ പാക്കേജ് ചെയ്യാനുള്ള തീരുമാനം വെറുമൊരു തമാശയല്ല. അത് യഥാർത്ഥ പ്രവർത്തനപരമായ ബുദ്ധിമുട്ടുകൾ പരിഹരിക്കുന്നു. ഒന്നാമതായി, ഹോസ്റ്റ് ചെയ്യാനോ പണം നൽകാനോ ഉള്ള ഇൻഫ്രാസ്ട്രക്ചർ ആവശ്യമില്ല. നിങ്ങൾ ഒരു App Service സജ്ജീകരിക്കുകയോ egress costs-നെ കുറിച്ച് ആശങ്കപ്പെടുകയോ ചെയ്യേണ്ടതില്ല. രണ്ടാമതായി, നിങ്ങളുടെ ക്രെഡൻഷ്യലുകൾ ഒരിക്കലും നിങ്ങളുടെ മെഷീനിൽ നിന്ന് പുറത്തുപോകില്ല. നിങ്ങളുടെ Azure DevOps personal access token ബ്രൗസർ മെമ്മറിയിൽ മാത്രമേ ഉണ്ടാകൂ, പേജ് റിഫ്രഷ് ചെയ്യുന്ന നിമിഷം അത് ഇല്ലാതാകുന്നു. ചോരാൻ സാധ്യതയുള്ള രഹസ്യങ്ങളുടെ ഡാറ്റാബേസോ വിശ്വസിക്കേണ്ട OAuth സെർവറോ ഇതിലില്ല. മൂന്നാമതായി, ഇത് ഉപയോഗിക്കുന്നത് വളരെ എളുപ്പമാണ്. ഒരു വിക്കി (wiki) വഴി ആരെയും ഇതിലേക്ക് കൊണ്ടുവരേണ്ടതില്ല. നിങ്ങൾക്ക് ഈ ഫയൽ ഒരു ഇമെയിലോ Slack thread-ഓ ആയി അയക്കാം. സ്വീകർത്താവിന് അത് തുറന്ന് ഉടൻ തന്നെ റിവ്യൂ തുടങ്ങാം.

The Fact Layer: Determinism First

Gatekeeper അതിന്റെ റിവ്യൂവിനെ രണ്ട് വ്യത്യസ്ത ലെയറുകളായി തിരിക്കുന്നു, ആ വേർതിരിവാണ് അതിന്റെ വിശ്വാസ്യതയുടെ അടിസ്ഥാനം.

ആദ്യത്തെ ലെയർ നേരിട്ട് Azure DevOps REST API-യുമായി സംവദിക്കുന്ന പ്യുവർ JavaScript ആണ്. മാറ്റമില്ലാത്ത വസ്തുതകളാണ് ഇത് പരിശോധിക്കുന്നത്. ഒരു pull request ഒരു വർക്ക് ഐറ്റവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു, അല്ലെങ്കിൽ ബന്ധപ്പെട്ടിട്ടില്ല. ഒരു റിവ്യൂവർ അപ്രൂവൽ വോട്ട് നൽകിയിട്ടുണ്ട്, അല്ലെങ്കിൽ നൽകിയിട്ടില്ല. ഡിസ്ക്രിപ്ഷൻ ശൂന്യമാണ്, അല്ലെങ്കിൽ അതിൽ വാചകങ്ങൾ അടങ്ങിയിരിക്കുന്നു. ചർച്ചകൾ പരിഹരിക്കപ്പെട്ടു, അല്ലെങ്കിൽ അവ ഇപ്പോഴും തുടരുന്നു.

പ്രത്യേകമായി പറഞ്ഞാൽ, Fact Layer നാല് കാര്യങ്ങളാണ് പരിശോധിക്കുന്നത്:

• Ticket mapping: ഈ PR കുറഞ്ഞത് ഒരു വർക്ക് ഐറ്റമായെങ്കിലും ലിങ്ക് ചെയ്തിട്ടുണ്ടോ?
• Reviewer sign-off: ആരെങ്കിലും അപ്രൂവ് ചെയ്യാൻ വോട്ട് ചെയ്തോ, അതോ എണ്ണം ഇപ്പോഴും പൂജ്യമാണോ?
• Description quality: ഡിസ്ക്രിപ്ഷൻ ശൂന്യമാണോ, അതോ വെറുമൊരു പ്ലേസ്‌ഹോൾഡർ മാത്രമാണോ?
• Open discussions: മറുപടിക്കായി കാത്തിരിക്കുന്ന പരിഹരിക്കപ്പെടാത്ത കമന്റ് ത്രെഡുകൾ ഉണ്ടോ?

ഈ പരിശോധനകൾ പേജിലുടനീളം വിഷ്വൽ സ്റ്റാമ്പുകൾ (visual stamps) നൽകുന്നു. വലിയ ചുവന്ന NOT MAPPED സ്റ്റാമ്പ് അവഗണിക്കാൻ പ്രയാസമാണ്. ഒരു ടേബിൾ സെല്ലിനുള്ളിലെ ചെറിയ പച്ച ടിക്ക് മാർക്ക് ശ്രദ്ധിക്കപ്പെടാതെ പോകാൻ സാധ്യതയുണ്ട്. പ്രോസസ്സ് പരാജയങ്ങൾ വ്യക്തമായി കാണിക്കപ്പെടണം എന്ന് ഞങ്ങൾ നേരത്തെ തന്നെ മനസ്സിലാക്കിയിരുന്നു. ഒരു ഡെവലപ്പർ മെർജ് ചെയ്യാൻ ധൃതി കാണിക്കുമ്പോൾ, സൂക്ഷ്മമായ സൂചനകൾ ഫലപ്രദമാകില്ല. അവ്യക്തത പൂർണ്ണമായും ഒഴിവാക്കാനാണ് Fact Layer നിലകൊള്ളുന്നത്.

ഈ ലെയർ നിശ്ചിതമായ (deterministic) API റെസ്പോൺസുകളെ ആശ്രയിക്കുന്നതിനാൽ, ഇതിന്റെ കൃത്യത വളരെ വലുതാണ്. സ്റ്റാമ്പിൽ NO APPROVAL എന്ന് കാണിക്കുന്നുണ്ടെങ്കിൽ, ആരും അപ്രൂവ് ബട്ടൺ ക്ലിക്ക് ചെയ്തിട്ടില്ലെന്ന് നിങ്ങൾക്ക് ഉറപ്പിക്കാം. UNRESOLVED THREADS എന്ന് കാണിക്കുന്നുണ്ടെങ്കിൽ, ചർച്ചകൾ ഇപ്പോഴും നടക്കുന്നുണ്ടെന്നാണ് അർത്ഥം. ഈ ലെയർ