அண்மையில் மேற்கொள்ளப்பட்ட ஒரு deployment, அனைத்து unit test, integration test மற்றும் mock-server சரிபார்ப்புகளும் வெற்றிகரமாக முடிந்தும், மூன்று மைக்ரோசர்வீஸ்களை (microservices) செயலிழக்கச் செய்தது. அந்தத் குழு தங்கள் API mocks-க்கு பதிலாக contract testing முறையைப் பயன்படுத்தியது. ஆறு மாதங்களில், ஒப்பந்தங்களின் எண்ணிக்கை மூன்றிலிருந்து 47 ஆக உயர்ந்ததுடன், மாதாந்திர integration-failure விகிதம் இரண்டு சம்பவங்களிலிருந்து பூஜ்ஜியமாகக் குறைந்தது.
மாக்ஸ்கள் (Mocks) உங்களைப் பாதுகாக்க ஏன் முடியாது
ஒரு mock server, ஒரு நுகர்வோர் (consumer) எதை எதிர்பார்க்கிறாரோ அதன் வடிவத்தை மட்டுமே பிரதிபலிக்கிறது; வழங்குநர் (provider) உண்மையில் அந்த வடிவத்தை வழங்குகிறாரா என்பதை அது ஒருபோதும் சரிபார்ப்பதில்லை. ஒரு வழங்குநர் ஒரு புலத்தின் (field) பெயரை மாற்றினால்—உதாரணமாக name-லிருந்து display_name-க்கு மாற்றினால்—அந்த mock இன்னும் பழைய தரவையே (payload) வழங்கும், நுகர்வோரின் சோதனைகள் (tests) சரியாகவே காட்டும், ஆனால் நேரடி அமைப்பு (live system) செயலிழந்துவிடும். செவ்வாய்க்கிழமை மதியம் 2 மணிக்கு நடந்த அந்தத் தயாரிப்புத் தோல்வி (production failure) சரியாக அதுதான்: அந்த mock உண்மையான ஒப்பந்தத்தைப் பற்றி "பொய்" கூறியது.
ஒப்பந்தச் சோதனை (Contract testing) இடைவெளியை நிரப்புகிறது
எந்தவொரு குறியீடும் (code) தயாரிப்புச் சூழலுக்கு (production) செல்வதற்கு முன்பே, ஒரு API-இன் இரு தரப்பினரும் ஒரு பொதுவான வரையறையில் உடன்பட ஒப்பந்தச் சோதனை கட்டாயப்படுத்துகிறது. இதில் இரண்டு பொதுவான அணுகுமுறைகள் உள்ளன:
- நுகர்வோர் சார்ந்த ஒப்பந்தங்கள் (Consumer-driven contracts) – நுகர்வோர் சேவை தனது எதிர்பார்ப்புகளை எழுதுகிறது; வழங்கும் சேவை அவற்றைச் சரிபார்க்கிறது. இது ஒன்றாக இணைந்து வளரும் உள் மைக்ரோசர்வீஸ்களுக்கு (internal microservices) சிறப்பாகச் செயல்படும்.
- வழங்குநர் சார்ந்த ஒப்பந்தங்கள் (Provider-driven contracts) – வழங்குநர் ஒரு விவரக்குறிப்பை (specification) வெளியிடுகிறார்; நுகர்வோர் தங்கள் குறியீட்டை அதனுடன் ஒப்பிட்டுச் சரிபார்க்கிறார்கள். இது பொதுவான API-களுக்கான வழக்கமான முறையாகும்.
முதல் அணுகுமுறை பொதுவாக ஒரு மைக்ரோசர்வீஸ் கட்டமைப்பிற்குள் ஏற்படும் ஒருங்கிணைப்புத் தோல்விகளைத் தடுக்கிறது.
நுகர்வோர் சார்ந்த ஒப்பந்தம் எவ்வாறு செயல்படுகிறது
- நுகர்வோர், வழங்குநரிடமிருந்து தனக்குத் துல்லியமாக என்ன தேவை என்பதை விவரிக்கும் ஒரு சோதனையை எழுதுகிறார்.
- அந்தச் சோதனையை இயக்குவதன் மூலம் ஒரு pact file உருவாக்கப்படுகிறது – இது அந்த எதிர்பார்ப்புகளைப் பதிவு செய்யும் ஒரு JSON ஆவணம் ஆகும்.
- வழங்குநர் தனது CI pipeline-இல் pact file-ஐக் கொண்டு தனது உண்மையான சேவையை இயக்குகிறார்.
- வழங்குநர் ஒரு புலத்தை மாற்றினால், சரிபார்ப்பு தோல்வியடையும் மற்றும் build தடுக்கப்படும்.
சரிபார்ப்பு உண்மையான வழங்குநர் குறியீட்டின் (provider code) மீது இயங்குவதால், எந்தவொரு பாதிப்பை ஏற்படுத்தும் மாற்றமும் deployment-க்கு முன்பே கண்டறியப்படுகிறது.
உங்கள் சோதனை பிரமிடில் (test pyramid) ஒப்பந்தச் சோதனைகள் எங்கு இருக்க வேண்டும்
- Unit tests – வேகமானவை, தனிமைப்படுத்தப்பட்ட தர்க்கத்தை (logic) சோதிக்கின்றன.
- Contract tests – நடுத்தர வேகம், API ஒப்பந்தங்கள் சரியாக இருப்பதை உறுதி செய்கின்றன.
- End-to-end tests – மெதுவானவை, முழுமையான வணிகச் செயல்பாடுகளைச் சோதிக்கின்றன.
ஒப்பந்தச் சோதனைகளை, unit test-களின் விரைவான பின்னூட்டத்திற்கும் (feedback), end-to-end தொகுப்புகளின் விரிவான கவரேஜிற்கும் இடையிலான ஒரு பாலமாகப் பாருங்கள். அடிக்கடி தோல்வியடையும் integration புள்ளிகளைக் கண்டறிந்து, இரண்டு அல்லது மூன்று முக்கியமான endpoints-களுடன் தொடங்கவும்.
நிஜ உலகப் பயன்பாட்டு கதை
இந்தக் கட்டுரையைத் தூண்டிய குழு, தங்களின் மிகவும் பலவீனமான அழைப்புகளை (fragile calls) உள்ளடக்கிய மூன்று ஒப்பந்தங்களுடன் தொடங்கினர். ஆறு மாதங்களுக்குப் பிறகு, சேவைகளுக்கு இடையிலான பெரும்பாலான போக்குவரத்தை (inter-service traffic) உள்ளடக்கிய 47 ஒப்பந்தங்களை அவர்கள் வைத்திருந்தனர். அந்த காலகட்டத்தில், API முறிவுச் சம்பவங்கள் மாதத்திற்கு இரண்டு என்பதிலிருந்து பூஜ்ஜியமாகக் குறைந்தது.
ஒப்பந்தச் சோதனை எப்போது தேவையில்லை
- நீங்கள் அனைத்து சேவைகளையும் ஒரே களஞ்சியத்தில் (single repository) வைத்திருக்கும் ஒரு தனி டெவலப்பர் (solo developer) ஆக இருந்தால்.
- அந்த API விதிவிலக்கான நிலைத்தன்மை கொண்டது மற்றும் பல ஆண்டுகளாக மாறாமல் இருந்தால்.
- நீங்கள் விரைவில் கைவிடப்படவிருக்கும் ஒரு முன்மாதிரியை (prototype) உருவாக்கி இருந்தால்.
அத்தகைய சூழ்நிலைகளில், ஒப்பந்தங்களைப் பராமரிப்பதற்கான கூடுதல் பணி (overhead), அதன் பலனை விட அதிகமாக இருக்கலாம்.
சாத்தியமான குறைபாடுகள் மற்றும் அவற்றை எவ்வாறு கையாள்வது
- ஒப்பந்தங்களை அவை விவரிக்கும் குறியீட்டுடன் (code) சேர்த்து பதிப்புப்படுத்தவும் (versioned).
- காலாவதியான ஒப்பந்தங்களைத் தவிர்க்க, ஒவ்வொரு CI ஓட்டத்திலும் சரிபார்ப்பைத் தானியக்கமாக்கவும் (automate).
- தற்செயலான முறிவுகளைக் கண்டறிய, pull requests-களில் ஒப்பந்த மாற்றங்களைச் சரிபார்க்கவும்.
முக்கியக் கருத்து
உங்கள் சேவைகள் ஒன்றோடு ஒன்று பேசிக்கொள்ள முடியும் என்று உங்களை நீங்களே நம்பிக்க, இன்னும் கைமுறையாக உருவாக்கப்பட்ட mocks-களை மட்டுமே நீங்கள் நம்பியிருந்தால், நீங்கள் ஒரு பொய்யான வாக்குறுதியின் மீது பந்தயம் கட்டுகிறீர்கள். ஒப்பந்தச் சோதனை அந்தப் பந்தயத்தை ஒரு சரிபார்க்கக்கூடிய ஒப்பந்தமாக மாற்றுகிறது; இது பாதிப்பை ஏற்படுத்தும் மாற்றங்கள் தயாரிப்புச் சூழலைச் சென்றடைவதற்கு முன்பே அவற்றைக் கண்டறிந்து, அந்தத் குழுவின் புள்ளிவிவரங்கள் காட்டுவது போல, ஒருங்கிணைப்புத் தோல்விகளை முற்றிலும் நீக்க முடியும்.