staging की समस्याएँ
- pre-live, production के समान नहीं होता
- release queue बन जाती है
- release बहुत बड़े हो जाते हैं
- बदलावों के लिए ownership की कमी रहती है
- process को responsibility की जगह लेने दी जाती है
Squeaky Ship कैसे करता है
- केवल वही merge करें जो live किया जा सके: बदलावों को local development environment में पर्याप्त रूप से test किया जाता है
- flat branching strategy का उपयोग: जब कोई feature merge के लिए तैयार हो, तो rebase करें और testing करें. समस्या होने पर roll forward करें
- high-risk features के लिए हमेशा feature flags का उपयोग
- manual deployment: बदलाव के बाद लगातार monitoring. monitoring/logging/alerts पूरे सिस्टम में लागू. blue/green deployment
निष्कर्ष
- सच्चे CI/CD के लिए staging environment छोड़ने से software shipping के बारे में एक अलग mindset बनाया जा सकता है
- अगर बदलाव live होने से पहले कोई buffer नहीं है, तो यह भरोसा होना चाहिए कि बदलाव production के लिए उपयुक्त हैं
- अपने हर बदलाव के लिए ownership लें और सावधानी बरतें
- infrastructure cost और complexity घटती है, और development lifecycle को सरल तथा तेज़ किया जा सकता है
3 टिप्पणियां
संगठन के भीतर staging environment बनाते समय जो स्थिरता का एहसास हुआ था, उसे सोचकर इससे आसानी से सहमति नहीं बनती।
फिर भी deploy में देरी होना या बदलावों की मात्रा बढ़ जाना जैसी कमियों से मैं सहमत हूँ।
मुझे लगता है कि सिर्फ staging environment का मौजूद होना भी इसलिए अर्थपूर्ण है, क्योंकि इससे यह जांचा जा सकता है कि दूसरे environment में deploy किया जा सकता है या नहीं, और क्या यह software की उस मूल प्रकृति? को पूरा करता है जिसे replicate किया जा सकता है।
हम्म, मुझे नहीं पता कि "ownership" / "सावधानी" जैसी चीज़ों के लिए अधूरे लोगों पर निर्भर होना सही है या नहीं। कम-से-कम जैसा कहा गया है वैसा पूरी तरह काम करने वाले कंप्यूटर से मदद लेना, अगर आप कंप्यूटर प्रोग्रामर हैं, तो वही काम नहीं है जो आपको करना चाहिए?
और concept को थोड़ा विस्तार देकर, स्टेजिंग = final approval के लिए (जो spec हमने बात की थी उससे आख़िर में वही है या नहीं, product data डालने पर वह सोच से ज़्यादा बदसूरत तो नहीं दिखता, वगैरह जैसी जाँच के लिए) डेव = developer आदि लोगों और feature पर चर्चा के लिए (demo के लिए)
इसी तरह इस्तेमाल कर रहे हैं।
उम्.. मेरा मानना है कि ऐसी समस्याएँ इस बात पर निर्भर करती हैं कि आप किस तरह की service विकसित कर रहे हैं।
चाहे आप कितना भी test कर लें, समस्याएँ हो सकती हैं, और यह देखना होगा कि क्या users उसे स्वीकार कर सकते हैं।
Facebook जैसी software, जहाँ थोड़ी malfunction हो जाए तो लोग उसे इतना गंभीरता से नहीं लेते, वहाँ यह तरीका संभव है,
लेकिन अगर वह mission-critical infrastructure या paid service है, तो लगता है कि समस्या न हो इसके लिए पूरी तैयारी करनी चाहिए।