എന്റെ CI/CD പൈപ്പ്‌ലൈൻ 3 മാസമായി വിജയകരമായി നടക്കുന്നു — എന്നിട്ട് ഞാൻ ലോഗുകൾ വായിച്ചു

പച്ച ടിക്ക് മാർക്കുകൾ കാണുമ്പോൾ സന്തോഷം തോന്നും. എല്ലാ pull request-കളും പാസായി. എല്ലാ deploy-കളും വിജയകരമായി നടന്നു.

എന്നാൽ ഒരു ഫീച്ചർ പ്രവർത്തിക്കുന്നില്ലെന്ന് ഒരു ഉപയോക്താവ് റിപ്പോർട്ട് ചെയ്തു. ആ ഫീച്ചർ ആഴ്ചകളായി തകരാറിലായിരുന്നു.

ഞാൻ പൈപ്പ്‌ലൈൻ ലോഗുകൾ പരിശോധിച്ചു. വിജയകരമായി പൂർത്തിയായ ഞങ്ങളുടെ ബിൽഡുകൾ ഞങ്ങളോട് കള്ളം പറഞ്ഞിരിക്കുകയായിരുന്നു.

ഞങ്ങളുടെ പ്രക്രിയ തികച്ചും കൃത്യമാണെന്ന് തോന്നി:

  • Linting
  • Unit tests
  • Integration tests
  • Build
  • Deploy

മാസങ്ങളായി ഓരോ ഘട്ടത്തിലും 100% വിജയശതമാനമായിരുന്നു ഉണ്ടായിരുന്നത്.

എക്‌സ്‌പോർട്ട് (export) ബട്ടൺ ക്ലിക്ക് ചെയ്യുമ്പോൾ ഒന്നും സംഭവിക്കുന്നില്ലായിരുന്നു. ഒരു എററും (error) കാണിച്ചില്ല. 11 ആഴ്ചകൾക്ക് മുമ്പ് വരുത്തിയ ഒരു മാറ്റം മൂലമാണ് ഇത് സംഭവിക്കുന്നതെന്ന് ഞാൻ കണ്ടെത്തി. പൈപ്പ്‌ലൈൻ പാസായി. കോഡ് റിവ്യൂവും അംഗീകരിക്കപ്പെട്ടു. എന്നാൽ ആ ഫീച്ചർ തുടക്കം മുതലേ തകരാറിലായിരുന്നു.

പ്രശ്നം ഞങ്ങളുടെ കോഡിലായിരുന്നില്ല. ഞങ്ങളുടെ ടെസ്റ്റ് കോഡിലായിരുന്നു.

ഞങ്ങളുടെ integration tests എല്ലാത്തിനും mocks ആണ് ഉപയോഗിച്ചിരുന്നത്. ഞങ്ങൾ മുഴുവൻ export service-ഉം mock ചെയ്തിരുന്നു. യഥാർത്ഥ കോഡിന് പകരം ടെസ്റ്റ് പരിശോധിച്ചത് mock-നെ ആയിരുന്നു. ആ mock എപ്പോഴും സക്സസ് സ്റ്റാറ്റസ് (success status) ആണ് നൽകിയിരുന്നത്.

ഞങ്ങൾ 'over-mocking' എന്ന കെണിയിൽ വീണു:

  • Unit tests: യൂണിറ്റിനെ വേർതിരിച്ചറിയാൻ എല്ലാം mock ചെയ്തു. ഇത് കുഴപ്പമില്ല.
  • Integration tests: വേഗതയ്ക്കായി എല്ലാം mock ചെയ്തു. ഇത് ഒരു തെറ്റാണ്.
  • E2E tests: ഈ പ്രത്യേക ഫ്ലോ (flow) ശ്രദ്ധിക്കാതെ പോയി.

ഞങ്ങളുടെ integration tests വെറും ചിലവേറിയ unit tests മാത്രമായിരുന്നു. അവ ഞങ്ങളുടെ mocks പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് മാത്രമാണ് പരിശോധിച്ചത്. ഞങ്ങളുടെ കോഡ് പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് അവ പരിശോധിച്ചില്ല.

ഇത് പരിഹരിക്കാൻ ഞാൻ മൂന്ന് മാറ്റങ്ങൾ വരുത്തി:

  1. Mocks ഉപയോഗിക്കുന്നത് unit tests-ൽ മാത്രം പരിമിതപ്പെടുത്തുക. Integration tests യഥാർത്ഥ ഡാറ്റാബേസുകൾ (databases), APIs, ഫയൽ സിസ്റ്റങ്ങൾ എന്നിവയുമായി ബന്ധപ്പെട്ടിരിക്കണം. ഒരു ടെസ്റ്റ് സാവധാനത്തിലാണെങ്കിൽ, അത് ഒരു mock ഉപയോഗിച്ച് മറച്ചുവെക്കരുത്. ആ വേഗത കുറവ് ഒരു സൂചനയായി കണ്ട് അത് ഒപ്റ്റിമൈസ് (optimize) ചെയ്യാൻ ശ്രമിക്കുക.

  2. Contract tests ചേർക്കുക. നിങ്ങളുടെ mocks യഥാർത്ഥ സർവീസിന്റെ സ്വഭാവത്തോട് യോജിക്കുന്നുണ്ടെന്ന് ഇവ ഉറപ്പാക്കുന്നു. ഒരു യഥാർത്ഥ സർവീസ് നൽകാൻ സാധ്യതയില്ലാത്ത ഡാറ്റ ഒരു mock നൽകുന്നുണ്ടെങ്കിൽ, contract test പരാജയപ്പെടും.

  3. യഥാർത്ഥ കവറേജ് (coverage) ട്രാക്ക് ചെയ്യുക. വെറും പാസ് റേറ്റ് (pass rate) മാത്രം നോക്കുന്നത് ഞങ്ങൾ നിർത്തി. ടെസ്റ്റുകൾ യഥാർത്ഥത്തിൽ എന്തൊക്കെയാണ് പരിശോധിക്കുന്നത് എന്ന് ഞങ്ങൾ ശ്രദ്ധിച്ചു. ഞങ്ങളുടെ കവറേജ് കണക്കുകൾ 94%-ൽ നിന്ന് 67%-ലേക്ക് കുറഞ്ഞു. ഞങ്ങൾക്ക് ലഭിച്ച ഏറ്റവും സത്യസന്ധമായ അളവുകോലായിരുന്നു ഇത്.

പൈപ്പ്‌ലൈൻ പച്ച നിറത്തിൽ കാണപ്പെടുന്നു എന്നതിനർത്ഥം നിങ്ങളുടെ കോഡ് പ്രവർത്തിക്കുന്നു എന്നല്ല. നിങ്ങളുടെ ടെസ്റ്റുകൾ പാസായി എന്നാണ്. ഇവ രണ്ടും രണ്ടാണ്.

പൈപ്പ്‌ലൈൻ എല്ലാം ശരിയാണെന്ന് പറയുന്ന ബഗുകളാണ് (bugs) ഏറ്റവും അപകടകാരികൾ.

സ്വയം ഈ ചോദ്യങ്ങൾ ചോദിക്കുക:

  • എന്റെ ടെസ്റ്റുകൾ ബഗുകൾ കണ്ടെത്തുന്നുണ്ടോ അതോ വെറും mocks ശരിയാണെന്ന് ഉറപ്പിക്കുകയാണോ ചെയ്യുന്നത്?
  • എന്റെ integration tests യഥാർത്ഥത്തിൽ കാര്യങ്ങൾ സംയോജിപ്പിക്കുന്നുണ്ടോ (integrate)?
  • എല്ലാ mocks-ഉം നീക്കം ചെയ്താൽ എത്ര ടെസ്റ്റുകൾ പാസായി നിൽക്കും?
  • ഞാൻ അളക്കുന്നത് കവറേജ് ആണോ അതോ ആത്മവിശ്വാസമാണോ?

ഒരിക്കലും പരാജയപ്പെടാത്ത ഒരു പൈപ്പ്‌ലൈൻ വിശ്വസനീയമല്ല. അത് പരീക്ഷിക്കപ്പെടാത്തതാണ് (untested).

Source: https://dev.to/kollittle/my-cicd-pipeline-passed-for-3-months-then-i-read-the-logs-4mbj