मौजूदा system में सुरक्षित बदलाव करें

बदलाव से जुड़े contracts पहचानें

मौजूदा software के callers, stored data, scheduled jobs और संचालन प्रक्रियाएँ होती हैं। कुछ dependencies उस file में नहीं दिखतीं जिसे आप edit करना चाहते हैं। Agent ऐसा बदलाव बना सकता है जो स्थानीय स्तर पर सही हो, लेकिन इनमें से कोई contract तोड़ दे।

Implementation से पहले प्रभावित डेटा पढ़ने और लिखने वाले components पहचानें। Routes, background jobs, reports और external integrations देखें। जाँचें कि दूसरी teams या पुराने client versions वर्तमान व्यवहार पर निर्भर हैं या नहीं।

Agent से इस dependency map के प्रमाण दिखाने को कहें। Search result उपयोगी शुरुआत है, लेकिन dynamic calls और बाहरी consumers के लिए जिम्मेदार व्यक्ति को dependency की पुष्टि करनी पड़ सकती है।

वर्तमान व्यवहार को जाँचने योग्य बनाएँ

कम documentation वाले module में स्थिर रहने वाले व्यवहार पर केंद्रित checks जोड़ें। ये checks वर्तमान contract बताती हैं। इनसे यह सिद्ध नहीं होता कि हर मौजूदा व्यवहार सही या वांछनीय है।

वर्तमान व्यवहार किसी requirement से टकराए तो टकराव दर्ज करें। केवल test में दर्ज होने के कारण security defect बनाए न रखें। इच्छित व्यवहार और दोष को अलग करने के लिए जरूरी निर्णय लें।

वास्तविक परिस्थितियों जैसे, लेकिन गैर-संवेदनशील fixtures इस्तेमाल करें। जहाँ पुराने data shapes और अधूरे records मिल सकते हैं, उन्हें fixtures में शामिल करें। केवल नए डेटा के साथ जाँचा गया नया schema migration की समस्याएँ छिपा सकता है।

Versions के बीच transition का review करें

customer_name का नाम display_name करने का काल्पनिक उदाहरण लें। सीधे नाम बदलने से deployment के दौरान पुराना application instance टूट सकता है। एक pull request में दोनों files update करने से deployment atomic नहीं हो जाता।

चरणबद्ध तरीका compatibility बनाए रख सकता है:

1. पुराना field हटाए बिना नया field जोड़ें।
2. तय करें कि नए writes जरूरी values को एक समान कैसे रखेंगे।
3. दोबारा शुरू की जा सकने वाली प्रक्रिया से मौजूदा records का backfill करें।
4. डेटा पूरा होने और उसे पढ़ने वाले components का व्यवहार जाँचें।
5. पढ़ने वाले components को नए field पर ले जाएँ।
6. पुराने field के consumers हटने के बाद ही उसे हटाएँ।

सटीक तरीका database और write patterns पर निर्भर है। Dual writes में एक write fail होने पर inconsistency आ सकती है। Database transaction या synchronization का दूसरा स्पष्ट तरीका जरूरी हो सकता है। System की guarantees जाँचे बिना यह उदाहरण लागू न करें।

Martin Fowler इस सामान्य transition को parallel change कहते हैं, जिसे expand-and-contract भी कहते हैं। मुख्य विचार है कि हटाने से पहले compatible transition हो।

Recovery की योजना rollback से अलग बनाएँ

Code rollback application का पुराना version लौटाता है। इससे data migration अपने आप वापस नहीं होता। पुराना version नए डेटा को न भी समझे। Destructive migration ऐसी जानकारी हटा सकता है जिसे code rollback वापस नहीं ला सकता।

हर चरण की recovery कार्रवाई पहचानें। Restartable backfill को फिर शुरू करना सुरक्षित हो सकता है। गलत transformation के लिए सुरक्षित रखे source data से सुधार जरूरी हो सकता है। Destructive operation के लिए जाँची हुई restore प्रक्रिया जरूरी हो सकती है।

पूछें कि recovery का निर्णय किसकी जिम्मेदारी है और उसमें कितना समय लग सकता है। “हमारे पास backups हैं” को यह प्रमाण न मानें कि recovery सेवा की requirement पूरी करती है।

बदलाव को review करने योग्य रखें

असंबंधित cleanup को कार्यात्मक बदलाव से अलग रखें। Pull request में compatibility plan, verification के परिणाम और हटाने की शर्तें दें। वह बिंदु बताएँ जिसके बाद rollback में अतिरिक्त काम लगेगा।

Agent consumers का निरीक्षण करने और migration code तैयार करने में मदद कर सकता है। जिम्मेदार व्यक्ति को transition और recovery plan फिर भी स्वीकार करना है। अंतिम design सुरक्षित बदलाव का केवल एक हिस्सा है।