प्रमाण के साथ release का निर्णय लें

निर्णय सटीक बताएँ

हरी pipeline कुछ checks का प्रमाण है। वह release निर्णय का पूरा विवरण नहीं है। जिम्मेदार व्यक्ति को जानना चाहिए कि क्या बदलेगा, कहाँ बदलेगा और कौन-से परिणाम अभी बाकी हैं।

काल्पनिक customer export के लिए स्वीकार किए commit और उससे बने artifact की पहचान करें। Target environment का नाम दें। संबंधित tests, review और स्वीकृत exceptions के links दें। Application के साथ होने वाले data या infrastructure changes शामिल करें।

NIST का SSDF सुरक्षित development practices देता है, जबकि SLSA provenance artifact कैसे बना यह बताने में मदद करता है। इनमें से कोई इस service के लिए release उचित है या नहीं, यह निर्णय लेने की जरूरत नहीं हटाता। NIST SSDF, SLSA provenance।

तीन घटनाएँ अलग रखें

Merge source change को branch में लाता है। Deployment artifact को environment में रखता है। Feature exposure व्यवहार को उपयोगकर्ताओं के लिए उपलब्ध करता है। ये घटनाएँ एक साथ हो सकती हैं, लेकिन जरूरी नहीं कि एक ही घटना हों।

Service निष्क्रिय feature deploy करके बाद में उपलब्ध कर सकती है। दिखाई देने वाला feature आने से पहले database migration production को प्रभावित कर सकता है। PR merge को हर असर का विवरण मानने के बजाय वास्तविक क्रम तय करें।

Export में feature flag शुरुआती exposure सीमित कर सकता है। वह अपने आप नए endpoint की सुरक्षा या schema migration को उलटा नहीं करता। जहाँ असर होता है, उसी बिंदु पर control जाँचें।

प्रमाण के संक्षिप्त record का review करें

ऐसा record इस्तेमाल करें जिसे दूसरा जिम्मेदार व्यक्ति जाँच सके:

• उद्देश्य और प्रभावित उपयोगकर्ता।
• Commit और artifact की पहचान।
• संबंधित behavior, security और compatibility checks।
• Target environment और execution identity।
• जिम्मेदार व्यक्ति और समाप्ति की शर्तों के साथ बचे exceptions।
• Monitoring, recovery का तरीका और response का जिम्मेदार व्यक्ति।

दावे स्पष्ट रखें। “Tests pass हैं” से बेहतर है release commit के results का link और coverage का स्पष्ट विवरण। “Rollback उपलब्ध है” से बेहतर है बताई गई सीमाओं वाली जाँची प्रक्रिया।

तय करें कि कैसे रोकना है

Execution से पहले release की शर्तें तय करें। काल्पनिक export में दूसरी organization का access सफल हो, artifact स्वीकार किए digest से अलग हो या recovery उपलब्ध न हो, तो रुकें। ये उदाहरण की शर्तें हैं, हर स्थिति पर लागू checklist नहीं।

Deployment के बाद उपयोगकर्ताओं के लिए महत्वपूर्ण signals देखें। Error behavior और response times का service के स्वीकार किए targets से मिलान करें। Healthy process से यह सिद्ध नहीं होता कि user workflow काम करता है।

शर्त पूरी न हो तो सहमत response अपनाएँ। इसका अर्थ exposure बंद करना, compatible code rollback करना या डेटा recover करना हो सकता है। ऐसी कार्रवाई चुनें जो बड़ी विफलता बनाए बिना मौजूदा विफलता हल करे।

Release के बाद निर्णय बनाए रखें

वास्तविक deployed artifact और परिणाम दर्ज करें। Execution योजना से अलग हो, तो अंतर स्पष्ट करें। Incidents और अप्रत्याशित काम से मिली जानकारी अगले release design में शामिल करें।

Automated delivery system को यह record जाँचना आसान बनाना चाहिए। Reviewer को असंबद्ध chats, logs और screenshots से release दोबारा नहीं जोड़ना पड़े। स्पष्ट प्रमाण से teams नियमित काम automate कर सकती हैं और निर्णयों की जवाबदेही बनाए रख सकती हैं।