എല്ലാ യൂണിറ്റ് ടെസ്റ്റുകളും, ഇന്റഗ്രേഷൻ ടെസ്റ്റുകളും, മോക്ക്-സെർവർ പരിശോധനകളും വിജയിച്ചിട്ടും, ഒരു സമീപകാല ഡെപ്ലോയ്മെന്റ് മൂന്ന് മൈക്രോസർവീസുകളെ തകരാറിലാക്കി. ടീം അവരുടെ API മോക്കുകൾക്ക് പകരം കോൺട്രാക്ട് ടെസ്റ്റിംഗ് ഉപയോഗിച്ചു. ആറ് മാസത്തിനുള്ളിൽ കോൺട്രാക്ട് എണ്ണം മൂന്നിൽ നിന്ന് 47 ആയി ഉയരുകയും പ്രതിമാസ ഇന്റഗ്രേഷൻ പരാജയ നിരക്ക് രണ്ട് സംഭവങ്ങളിൽ നിന്ന് പൂജ്യമായി കുറയുകയും ചെയ്തു.
എന്തുകൊണ്ടാണ് മോക്കുകൾ (mocks) നിങ്ങളെ സംരക്ഷിക്കാത്തത്
ഒരു മോക്ക് സെർവർ ഒരു കൺസ്യൂമർ പ്രതീക്ഷിക്കുന്ന രൂപം (shape) മാത്രമേ അനുകരിക്കുകയുള്ളൂ; പ്രൊവൈഡർ യഥാർത്ഥത്തിൽ ആ രൂപം നൽകുന്നുണ്ടോ എന്ന് അത് ഒരിക്കലും പരിശോധിക്കില്ല. ഒരു പ്രൊവൈഡർ ഒരു ഫീൽഡിന്റെ പേര് മാറ്റിയാൽ—ഉദാഹരണത്തിന് name എന്നതിൽ നിന്ന് display_name എന്നതിലേക്ക്—മോക്ക് ഇപ്പോഴും പഴയ പേലോഡ് തന്നെ നൽകുന്നു, കൺസ്യൂമറുടെ ടെസ്റ്റുകൾ വിജയിച്ചതായി (green) കാണിക്കുന്നു, എന്നാൽ ലൈവ് സിസ്റ്റം തകരാറിലാകുന്നു. ചൊവ്വാഴ്ച ഉച്ചയ്ക്ക് 2 മണിക്ക് ഉണ്ടായ പ്രൊഡക്ഷൻ പരാജയം കൃത്യമായി ഇതേതായിരുന്നു: യഥാർത്ഥ കോൺട്രാക്ടിനെക്കുറിച്ച് മോക്ക് "നുണ പറഞ്ഞു".
കോൺട്രാക്ട് ടെസ്റ്റിംഗ് വിടവുകൾ നികത്തുന്നു
കോൺട്രാക്ട് ടെസ്റ്റിംഗ് ഒരു API-യുടെ രണ്ട് വശങ്ങളും കോഡ് പ്രൊഡക്ഷനിൽ എത്തുന്നതിന് മുമ്പ് ഒരു പൊതുവായ നിർവചനത്തിൽ (shared definition) യോജിക്കാൻ നിർബന്ധിക്കുന്നു. ഇതിന് രണ്ട് പൊതുവായ സമീപനങ്ങളുണ്ട്:
- Consumer-driven contracts – കൺസ്യൂമിംഗ് സർവീസ് പ്രതീക്ഷകൾ എഴുതുന്നു; പ്രൊവൈഡിംഗ് സർവീസ് അവ പരിശോധിക്കുന്നു. ഒരേസമയം വികസിച്ചുകൊണ്ടിരിക്കുന്ന ഇന്റേണൽ മൈക്രോസർവീസുകൾക്ക് ഇത് നന്നായി പ്രവർത്തിക്കുന്നു.
- Provider-driven contracts – പ്രൊവൈഡർ ഒരു സ്പെസിഫിക്കേഷൻ പ്രസിദ്ധീകരിക്കുന്നു; കൺസ്യൂമർമാർ അവരുടെ കോഡ് അതിനോട് ഒത്തുനോക്കുന്നു. പബ്ലിക് API-കൾക്ക് സാധാരണയായി ഉപയോഗിക്കുന്ന രീതിയാണിത്.
ആദ്യത്തെ സമീപനം പൊതുവെ ഒരു മൈക്രോസർവീസ് ആർക്കിടെക്ചറിനുള്ളിലെ തകരാറുകൾ തടയുന്നു.
ഒരു കൺസ്യൂമർ-ഡ്രിവൺ കോൺട്രാക്ട് എങ്ങനെ പ്രവർത്തിക്കുന്നു
- കൺസ്യൂമർ പ്രൊവൈഡറിൽ നിന്ന് തനിക്ക് കൃത്യമായി എന്താണ് വേണ്ടതെന്ന് വിവരിക്കുന്ന ഒരു ടെസ്റ്റ് എഴുതുന്നു.
- ഈ ടെസ്റ്റ് പ്രവർത്തിപ്പിക്കുന്നത് വഴി ഒരു pact file നിർമ്മിക്കപ്പെടുന്നു – ഇത് ആ പ്രതീക്ഷകൾ രേഖപ്പെടുത്തുന്ന ഒരു JSON ഡോക്യുമെന്റാണ്.
- പ്രൊവൈഡർ അതിന്റെ CI പൈപ്പ്ലൈനിൽ pact file ഉപയോഗിച്ച് യഥാർത്ഥ സർവീസ് പ്രവർത്തിപ്പിക്കുന്നു.
- പ്രൊവൈഡർ ഒരു ഫീൽഡ് മാറ്റിയാൽ, വെരിഫിക്കേഷൻ പരാജയപ്പെടുകയും ബിൽഡ് തടയപ്പെടുകയും ചെയ്യുന്നു.
വെരിഫിക്കേഷൻ യഥാർത്ഥ പ്രൊവൈഡർ കോഡിൽ തന്നെ പ്രവർത്തിക്കുന്നതിനാൽ, ഏതൊരു തകരാറുകളും ഡെപ്ലോയ്മെന്റിന് മുമ്പ് തന്നെ കണ്ടെത്താൻ സാധിക്കുന്നു.
നിങ്ങളുടെ ടെസ്റ്റ് പിരമിഡിൽ കോൺട്രാക്ട് ടെസ്റ്റുകൾ എവിടെ വരുന്നു
- Unit tests – വേഗതയേറിയത്, ഐസൊലേറ്റഡ് ലോജിക് പരിശോധിക്കുന്നു.
- Contract tests – ഇടത്തരം വേഗതയുള്ളത്, API കരാറുകൾ നിലനിൽക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുന്നു.
- End-to-end tests – സാവധാനത്തിലുള്ളത്, മുഴുവൻ ബിസിനസ് ഫ്ലോകളും പരിശോധിക്കുന്നു.
യൂണിറ്റ് ടെസ്റ്റുകളുടെ വേഗത്തിലുള്ള ഫീഡ്ബാക്കിനും എൻഡ്-ടു-എൻഡ് ടെസ്റ്റുകളുടെ വിപുലമായ കവറേജിനും ഇടയിലുള്ള ഒരു പാലമായി കോൺട്രാക്ട് ടെസ്റ്റുകളെ കാണുക. ഏറ്റവും കൂടുതൽ തകരാറുകൾ സംഭവിക്കുന്ന ഇന്റഗ്രേഷൻ പോയിന്റുകൾ ലക്ഷ്യം വെച്ച് രണ്ട് അല്ലെങ്കിൽ മൂന്ന് പ്രധാന എൻഡ്പോയിന്റുകളിൽ നിന്ന് തുടങ്ങുക.
യഥാർത്ഥ ലോകത്തെ ഉപയോഗത്തിന്റെ കഥ
ഈ ലേഖനത്തിന് പ്രചോദനമായ ടീം ഏറ്റവും ദുർബലമായ കോളുകൾക്കായി മൂന്ന് കോൺട്രാക്റ്റുകൾ ഉപയോഗിച്ചാണ് തുടങ്ങിയത്. ആറ് മാസത്തിന് ശേഷം, സർവീസുകൾ തമ്മിലുള്ള ഭൂരിഭാഗം ട്രാഫിക്കും ഉൾക്കൊള്ളുന്ന 47 കോൺട്രാക്റ്റുകൾ അവരുടെ പക്കലുണ്ടായിരുന്നു. ആ കാലയളവിൽ API തകരാറുകൾ ഉണ്ടാകുന്ന സംഭവങ്ങൾ പ്രതിമാസം രണ്ട് എന്നതിൽ നിന്ന് പൂജ്യമായി കുറഞ്ഞു.
കോൺട്രാക്ട് ടെസ്റ്റിംഗ് എപ്പോഴാണ് അത്ര ഗുണകരമല്ലാത്തത്
- എല്ലാ സർവീസുകളും ഒരു സിംഗിൾ റെപ്പോസിറ്ററിയിൽ സൂക്ഷിക്കുന്ന ഒരു സോളോ ഡെവലപ്പർ ആണെങ്കിൽ.
- API വളരെ സ്ഥിരതയുള്ളതും വർഷങ്ങളായി മാറ്റമില്ലാത്തതുമാണെങ്കിൽ.
- ഉടൻ ഉപേക്ഷിക്കാൻ ഉദ്ദേശിക്കുന്ന ഒരു പ്രോട്ടോടൈപ്പ് നിർമ്മിക്കുകയാണെങ്കിൽ.
ഇത്തരം സാഹചര്യങ്ങളിൽ കോൺട്രാക്റ്റുകൾ പരിപാലിക്കുന്നതിനുള്ള പ്രയത്നം അതിന്റെ ഗുണത്തേക്കാൾ കൂടുത