तुमच्या एजंटमुळे प्रोडक्शनमध्ये बिघाड झाला नाही. तुमच्या पाइपलाइनमुळे झाला.

तुमच्या एजंटमुळे प्रोडक्शनमध्ये बिघाड झाला नाही. तुमच्या पाइपलाइनमुळे झाला.

अनेक टीम्स pull requests उघडण्यासाठी एजंट्सचा वापर करतात. ते linting, tests आणि builds तपासण्यासाठी CI वापरतात. त्यानंतर, एक scheduled job कोड staging मधून production मध्ये हलवते. ही मांडणी (setup) कालांतराने अपयशी ठरते.

समस्या एखाद्या घातक (malicious) एजंटमध्ये नाही. समस्या एका चुकीच्या प्रक्रियेत (process) आहे. तुम्ही दोन वेगळ्या प्रश्नांना एकाच गेटमध्ये (gate) एकत्रित केले आहे:

  • हे CI मध्ये पास झाले का?
  • हे सध्या मानवासाठी पाहण्यास सुरक्षित आहे का?

या दोन्ही गोष्टी एकच नाहीत. CI कोड काम करतो की नाही हे तपासते. एखादे फीचर ग्राहकांसाठी तयार आहे की नाही, हे ते तपासत नाही.

जर तुमची पाइपलाइन "merged" आणि "live" या दोन्ही गोष्टींना एकच मानत असेल, तर तुमच्याकडे एक समस्या आहे. तुम्ही ठरवल्याशिवाय continuous deployment चा भाग बनला आहात.

तुम्हाला या दोन घटना एकमेकांपासून वेगळ्या (decouple) कराव्या लागतील.

हे करण्यासाठी तुम्ही feature flags वापरू शकता. Feature flags म्हणजे फक्त एक boolean आणि एक if statement आहे. सुरुवात करण्यासाठी तुम्हाला महागड्या साधनांची (tools) गरज नाही. एक साधी config value किंवा environment variable देखील पुरेसे आहे.

माझी मांडणी (setup) या नियमांचे पालन करते:

  • PRs main मध्ये merge होतात, पण main हे 'live' राहत नाही.
  • एक वेगळा release step main ला production branch मध्ये प्रमोट करतो.
  • मला स्पष्टपणे 'go' म्हणावे लागेल. कोणतेही cron jobs किंवा timers नकोत.
  • release, build ट्रॅफिक हाताळण्यासाठी तयार होईपर्यंत थांबते.
  • साइट काम करत असल्याची खात्री करण्यासाठी एक automated check मुख्य endpoints ला हिट करते.
  • एक माणूस बदलांची अंतिम मॅन्युअल तपासणी करतो.

यामुळे एक गेट तयार होते. युजरला काहीही दिसण्यापूर्वी एक माणूस, एक मशीन आणि दुसरा माणूस या सर्वांना 'नाही' म्हणण्याची संधी मिळते.

जर एखादा बग (bug) तरीही युजरपर्यंत पोहोचला, तर तुम्हाला तो वेगाने revert करावा लागेल. यासाठी, database migrations साठी 'expand and contract' पॅटर्न फॉलो करा.

  • एक नवीन column 'nullable' म्हणून जोडा.
  • डेटा backfill करा.
  • जुन्या आणि नवीन दोन्ही columns मध्ये लिहा.
  • नवीन column मधून वाचा.
  • जुना column फक्त नंतरच्या release मध्ये काढून टाका (drop करा).

जर तुम्ही हे वगळले, तर तुमचे revert button निरुपयोगी ठरेल. जर एखाद्या migration मुळे जुन्या कोडला आवश्यक असलेला column drop झाला, तर तुम्ही roll back करू शकणार नाही. तुमची सिस्टीम तशीच बिघडलेली राहील.

एजंटमुळे या चुका अधिक वेगाने होतात. तुमच्या चुकीच्या प्रक्रियांना लपवून ठेवणारा 'manual friction' एजंट काढून टाकतो. तुम्ही ज्या शिस्तीकडे (discipline) दुर्लक्ष केले, ती कधीही ऐच्छिक नव्हती. ती फक्त शुक्रवारी संध्याकाळी ५:०० वाजेपूर्वी एखादा माणूस चूक लक्षात आणून देत असल्यामुळे लपली होती.

प्रक्रियेतून (loop) माणसाला बाहेर काढा, आणि ती शिस्त अनिवार्य होईल.

स्रोत: https://dev.to/mattstratton/your-agent-didnt-break-prod-your-pipeline-did-4g9o