माझे CI/CD Pipeline ३ महिने यशस्वी झाले — मग मी लॉग्स वाचले

हिरवे चेकमार्क पाहून छान वाटते. प्रत्येक pull request यशस्वी झाला. प्रत्येक deploy व्यवस्थित चालला.

मग एका वापरकर्त्याने (user) एका बिघडलेल्या फीचरची तक्रार केली. ते कित्येक आठवड्यांपासून बिघडलेले होते.

मी पाइपलाइन लॉग्स उघडले. आमच्या यशस्वी बिल्ड्सनी आम्हाला फसवले होते.

आमची प्रक्रिया परिपूर्ण दिसत होती:

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

कित्येक महिने प्रत्येक टप्प्याचा सक्सेस रेट १००% होता.

एक्सपोर्ट (export) बटणावर क्लिक केल्यावर काहीच होत नव्हते. कोणतीही एरर (error) दिसत नव्हती. मी याचा शोध घेतला असता, तो ११ आठवड्यांपूर्वी केलेल्या एका बदलापर्यंत पोहोचलो. पाइपलाइन यशस्वी झाली होती. कोड रिव्ह्यू (code review) मंजूर झाला होता. ते फीचर सुरुवातीपासूनच बिघडलेले होते.

समस्या आमच्या कोडमध्ये नव्हती. ती आमच्या टेस्ट कोडमध्ये होती.

आमचे 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 मध्ये रिअल डेटाबेस, APIs आणि फाईल सिस्टम्सचा वापर होणे आवश्यक आहे. जर एखादी टेस्ट स्लो (slow) असेल, तर तिला mock वापरून लपवू नका. त्या वेगाचा वापर ऑप्टिमाइझ करण्यासाठी संकेत म्हणून करा.

  2. contract tests जोडा. यामुळे तुमचे mocks रिअल सर्व्हिसच्या वर्तनाशी (behavior) जुळतात याची खात्री होते. जर एखादा mock असा डेटा परत करत असेल जो रिअल सर्व्हिस देणार नाही, तर contract test फेल होईल.

  3. रिअल कव्हरेज (coverage) ट्रॅक करा. आम्ही केवळ पास रेट पाहणे थांबवले. टेस्ट्सने प्रत्यक्षात काय तपासले (exercise केले) याकडे आम्ही लक्ष दिले. आमचे कव्हरेज नंबर्स ९४% वरून ६७% वर आले. हे आमच्याकडे असलेले सर्वात प्रामाणिक मेट्रिक (metric) होते.

ग्रीन पाइपलाइनचा अर्थ असा नाही की तुमचा कोड काम करत आहे. याचा अर्थ असा आहे की तुमच्या टेस्ट्स पास झाल्या आहेत. या दोन्ही वेगवेगळ्या गोष्टी आहेत.

सर्वात धोकादायक बग्स (bugs) ते असतात ज्यांना तुमची पाइपलाइन 'ठीक आहे' असे सांगते.

स्वतःला हे प्रश्न विचारा:

  • माझ्या टेस्ट्स बग्स पकडत आहेत की फक्त mocks कन्फर्म करत आहेत?
  • माझे integration tests खरोखरच इंटिग्रेट (integrate) होतात का?
  • जर मी सर्व mocks काढून टाकले, तर किती टेस्ट्स अजूनही पास होतील?
  • मी कव्हरेज मोजत आहे की आत्मविश्वास (confidence)?

जी पाइपलाइन कधीच फेल होत नाही, ती विश्वसनीय नसते. ती अनटेस्टेड (untested) असते.

स्त्रोत: https://dev.to/kollittle/my-cicd-pipeline-passed-for-3-months-then-i-read-the-logs-4mbj