Slack की Deploy प्रक्रिया

• सभी PR के लिए code review और test pass होना ज़रूरी है

• merge किया गया code केवल North America के कार्य-समय में ही deploy किया जाता है (ताकि समस्या होने पर उसे हल किया जा सके)

• दिन में लगभग 12 बार नियमित deployment होता है

• हर deployment के लिए एक deployment owner तय किया जाता है

1. release branch बनाना

2. staging पर deploy करके manual test करना

3. internal Slack (dogfooding tier) पर deploy करने के बाद Canary deployment करना (जहां कुल traffic का केवल 2% route किया जाता है)

4. 10, 25, 50, 75, 100 प्रतिशत तक चरणबद्ध deployment करना

risk management के लिए deployment owners को train किया जाता है, और उन्हें सभी चरणों की निगरानी तथा communication की ज़िम्मेदारी दी जाती है

समस्याओं को जितनी जल्दी हो सके पकड़ना, कारण बने PR की पहचान करना, उसे निकालना, और फिर नया build deploy करना

अगर production तक पहुंचने के दौरान ऐसा कोई मुद्दा सामने आया हो जो पहले पकड़ा न गया हो, तो जांच शुरू करने से पहले पहले rollback किया जाता है

कंपनी के शुरुआती दिनों में जब केवल 10 EC2 instances चल रहे थे, तब deployment बस rsync करने जितना सरल था

production deployment से पहले केवल एक staging चरण होता था, और test के बाद तुरंत deploy कर दिया जाता था

जैसे-जैसे ग्राहक बढ़ते गए, केवल rsync से काम चलाना मुश्किल होता गया

→ full parallel pull-based system में बदलाव

नए build को script से server पर डालने के बजाय, हर server Consul key बदलने के signal पर एक साथ build pull करता है

→ Hot/Cold folders में बांटा गया atomic deploy

deployment के समय नए code को उस Cold directory में copy किया जाता है जो अभी उपयोग में नहीं है, जबकि मौजूदा service Hot directory से serve करती रहती है

जब server पर कोई active process नहीं रहता, तब Hot/Cold directories को आपस में swap कर दिया जाता है ताकि नया code तुरंत serve होने लगे

[xguru]

Hashicorp का Consul https://www.consul.io/

Slack का backend HHVM पर चलने वाला PHP/Hacklang है, इसलिए शायद वह Hot/Cold swap संभव है

https://www.quora.com/What-is-the-tech-stack-behind-Slack