നിങ്ങളുടെ ഏജന്റ് പ്രൊഡക്ഷൻ തകർത്തതല്ല. നിങ്ങളുടെ പൈപ്പ്‌ലൈൻ ആണ് തകർത്തത്.

നിങ്ങളുടെ ഏജന്റ് പ്രൊഡക്ഷൻ തകർത്തതല്ല. നിങ്ങളുടെ പൈപ്പ്‌ലൈൻ ആണ് അത് ചെയ്തത്.

പല ടീമുകളും പുൾ റിക്വസ്റ്റുകൾ (pull requests) ഓപ്പൺ ചെയ്യാൻ ഏജന്റുകളെ ഉപയോഗിക്കുന്നു. ലിന്റിംഗ് (linting), ടെസ്റ്റുകൾ, ബിൽഡുകൾ എന്നിവ പരിശോധിക്കാൻ അവർ CI ഉപയോഗിക്കുന്നു. തുടർന്ന്, ഒരു ഷെഡ്യൂൾഡ് ജോബ് സ്റ്റേജിംഗിൽ (staging) നിന്ന് കോഡിനെ പ്രൊഡക്ഷനിലേക്ക് മാറ്റുന്നു. ഈ രീതി ഒടുവിൽ പരാജയപ്പെടും.

പ്രശ്നം ഒരു ദുരുദ്ദേശ്യപരമായ ഏജന്റല്ല. പ്രശ്നം മോശമായ ഒരു പ്രക്രിയയാണ്. നിങ്ങൾ രണ്ട് വ്യത്യസ്ത ചോദ്യങ്ങളെ ഒരൊറ്റ ഘട്ടത്തിലേക്ക് (gate) ചുരുക്കി:

  • ഇത് CI പാസ്സാണോ?
  • ഇത് ഇപ്പോൾ ഒരു മനുഷ്യൻ കാണാൻ സുരക്ഷിതമാണോ?

ഇവ രണ്ടും ഒരേ കാര്യമല്ല. കോഡ് പ്രവർത്തിക്കുന്നുണ്ടോ എന്നാണ് CI പരിശോധിക്കുന്നത്. ഒരു ഫീച്ചർ ഉപഭോക്താക്കൾക്കായി തയ്യാറാണോ എന്ന് അത് പരിശോധിക്കുന്നില്ല.

നിങ്ങളുടെ പൈപ്പ്‌ലൈൻ 'merged' എന്നതിനെയും 'live' എന്നതിനെയും ഒരേ കാര്യമായി കാണുന്നുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് ഒരു പ്രശ്നമുണ്ട്. നിങ്ങൾ തീരുമാനിക്കാതെ തന്നെ 'continuous deployment'-ലേക്ക് എത്തിയിരിക്കുന്നു.

നിങ്ങൾ ഈ രണ്ട് സംഭവങ്ങളെയും വേർതിരിക്കണം (decouple).

ഇത് ചെയ്യാൻ നിങ്ങൾക്ക് ഫീച്ചർ ഫ്ലാഗുകൾ (feature flags) ഉപയോഗിക്കാം. ഫീച്ചർ ഫ്ലാഗുകൾ എന്നത് വെറുമൊരു ബൂളിയനും (boolean) ഒരു if സ്റ്റേറ്റ്‌മെന്റും മാത്രമാണ്. ഇത് തുടങ്ങാൻ നിങ്ങൾക്ക് വിലകൂടിയ ടൂളുകൾ ആവശ്യമില്ല. ഒരു ലളിതമായ കോൺഫിഗ് വാല്യൂ (config value) അല്ലെങ്കിൽ എൻവയോൺമെന്റ് വേരിയബിൾ (environment variable) മതിയാകും.

എന്റെ സെറ്റപ്പ് ഈ നിയമങ്ങൾ പിന്തുടരുന്നു:

  • PR-കൾ main-ലേക്ക് മെർജ് ചെയ്യുന്നു, എന്നാൽ main ആണ് എപ്പോഴും ലൈവ് ആയിരിക്കുന്നത് എന്നല്ല ഇതിനർത്ഥം.
  • ഒരു പ്രത്യേക റിലീസ് സ്റ്റെപ്പ് main-നെ ഒരു പ്രൊഡക്ഷൻ ബ്രാഞ്ചിലേക്ക് മാറ്റുന്നു.
  • ഞാൻ വ്യക്തമായി 'go' എന്ന് പറയണം. ക്രോൺ ജോബുകളോ (cron jobs) ടൈമറുകളോ പാടില്ല.
  • ബിൽഡ് ട്രാഫിക് കൈകാര്യം ചെയ്യാൻ തയ്യാറാകുന്നത് വരെ റിലീസ് കാത്തിരിക്കുന്നു.
  • സൈറ്റ് പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കാൻ ഒരു ഓട്ടോമേറ്റഡ് ചെക്ക് പ്രധാന എൻഡ്‌പോയിന്റുകളിൽ (endpoints) പരിശോധിക്കുന്നു.
  • ഒരു മനുഷ്യൻ മാറ്റങ്ങളിൽ അവസാനമായി ഒരു മാനുവൽ ചെക്ക് നടത്തുന്നു.

ഇത് ഒരു ഗേറ്റ് (gate) സൃഷ്ടിക്കുന്നു. ഒരു ഉപഭോക്താവ് ഒന്നും കാണുന്നതിന് മുമ്പ് ഒരു മനുഷ്യനും ഒരു മെഷീനും മറ്റൊരു മനുഷ്യനും 'ഇല്ല' എന്ന് പറയാൻ അവസരം ലഭിക്കുന്നു.

ഒരു ബഗ് ഇപ്പോഴും ഉപഭോക്താവിലേക്ക് എത്തുകയാണെങ്കിൽ, നിങ്ങൾ വേഗത്തിൽ അത് തിരുത്തണം (revert). ഇതിനായി, ഡാറ്റാബേസ് മൈഗ്രേഷനുകൾക്കായി (database migrations) 'expand and contract' പാറ്റേൺ പിന്തുടരുക.

  • ഒരു പുതിയ കോളം 'nullable' ആയി ചേർക്കുക.
  • ഡാറ്റ ബാക്ക്ഫിൽ (backfill) ചെയ്യുക.
  • പഴയതും പുതിയതുമായ കോളങ്ങളിൽ ഡാറ്റ എഴുതുക.
  • പുതിയ കോളത്തിൽ നിന്ന് ഡാറ്റ വായിക്കുക.
  • പിൽക്കാല റിലീസിൽ മാത്രം പഴയ കോളം ഒഴിവാക്കുക (drop).

നിങ്ങൾ ഇത് ഒഴിവാക്കിയാൽ, നിങ്ങളുടെ 'revert' ബട്ടൺ ഉപയോഗശൂന്യമാകും. ഒരു മൈഗ്രേഷൻ പഴയ കോഡിന് ആവശ്യമുള്ള ഒരു കോളം ഒഴിവാക്കിയാൽ, നിങ്ങൾക്ക് പഴയ അവസ്ഥയിലേക്ക് മടങ്ങാൻ (roll back) കഴിയില്ല. നിങ്ങൾ തകർന്ന അവസ്ഥയിൽ തന്നെ തുടരും.

ഒരു ഏജന്റ് ഇത്തരം തെറ്റുകൾ വേഗത്തിൽ സംഭവിക്കാൻ കാരണമാകുന്നു. നിങ്ങളുടെ മോശമായ പ്രക്രിയകളെ മറച്ചുവെച്ചിരുന്ന മാനുവൽ ഘടകങ്ങളെ (manual friction) ഇത് ഇല്ലാതാക്കുന്നു. നിങ്ങൾ ഒഴിവാക്കിയ അച്ചടക്കം (discipline) ഒരിക്കലും ഒരു ഓപ്ഷനായിരുന്നില്ല. വെള്ളിയാഴ്ച വൈകുന്നേരം 5 മണിക്ക് മുമ്പ് ഒരു മനുഷ്യൻ തെറ്റ് കണ്ടുപിടിക്കുന്നത് കൊണ്ട് മാത്രം ആ കുറവ് മറയ്ക്കപ്പെട്ടിരുന്നു എന്ന് മാത്രം.

മനുഷ്യനെ ഈ പ്രക്രിയയിൽ നിന്ന് ഒഴിവാക്കിയാൽ, ആ അച്ചടക്കം നിർബന്ധിതമാകും.

Source: https://dev.to/mattstratton/your-agent-didnt-break-prod-your-pipeline-did-4g9o