मुझे बताइए कि आपकी टीम में merge हुई pull request और उस कोड के प्रोडक्शन में चलने के बीच क्या होता है।

merge होते ही CI type checks, lint, और असली डेटाबेस पर unit तथा integration tests चलाता है, फिर commit से tag किया गया एक immutable artifact बनाता है। वह artifact अपने आप staging पर डिप्लॉय होता है, smoke tests चलते हैं, फिर वह health checks और ऑटोमैटिक rollback वाले क्रमिक rollout के पीछे प्रोडक्शन में जाता है। जोखिम भरा बर्ताव किसी feature flag के पीछे रहता है, ताकि कोड release करना और feature launch करना अलग अलग घटनाएं बनी रहें।

पिछली जिस टीम में मैं था, वहां main में merge होते ही CI शुरू हो जाता था: type check, lint, unit tests, फिर Postgres container पर integration tests, कुल मिलाकर लगभग सात मिनट। पास होने पर हम commit SHA से tag की गई container image बनाते थे, और आगे वही image बढ़ती थी; हर एनवायरनमेंट के लिए कुछ दोबारा build नहीं होता, क्योंकि तब आप ऐसा कुछ शिप कर रहे होते हैं जिसे आपने कभी टेस्ट ही नहीं किया। वह अपने आप staging पर डिप्लॉय होती थी, असली endpoints पर छोटा smoke suite चलता था, और फिर वह health checks के साथ rolling deploy की तरह प्रोडक्शन में जाती थी, जहां हम कुछ मिनट error rate और latency देखते थे और किसी के सीमा पार करने पर ऑटोमैटिक rollback हो जाता था। migrations deploy से पहले अलग कदम की तरह चलती थीं और हमेशा पीछे से मेल खाती थीं, तो कोड का rollback कभी schema को अधर में नहीं छोड़ता था। यूज़र को दिखने वाली हर चीज़ किसी flag के पीछे जाती थी, डिफ़ॉल्ट रूप से बंद, फिर अंदरूनी यूज़र्स के लिए, फिर एक प्रतिशत के लिए। वह फर्क बाकी सब से ज़्यादा मायने रखता था, क्योंकि इसका मतलब था कि खराब launch रात नौ बजे का आपात deploy नहीं, बस एक config का toggle था।