將新專案版本投入生產需要在部署速度和解決方案可靠性之間進行仔細平衡。 Slack看重快速迭代、短回饋週期、及時回應使用者請求。 此外，該公司還有數百名程式設計師，他們努力提高工作效率。
我們今天發布的該資料的譯本的作者表示，一個努力堅持這種價值觀並同時成長的公司必須不斷完善其專案部署系統。 公司需要投資工作流程的透明度和可靠性，這樣做是為了確保這些流程與專案的規模相對應。 在這裡，我們將討論在 Slack 中開發的工作流程，以及導致公司使用當今存在的專案部署系統的一些決策。
如今專案部署流程如何運作
Slack 中的每個 PR（拉取請求）都必須接受程式碼審查，並且必須成功通過所有測試。 只有在滿足這些條件後，程式設計師才能將自己的程式碼合併到專案的master分支中。 但是，此程式碼僅在北美時間的工作時間部署。 因此，由於我們的員工都在工作場所，我們已做好充分準備來解決任何意外問題。
我們每天都會進行大約 12 次規劃部署。 在每次部署期間，指定為部署負責人的程式設計師負責將新版本投入生產。 這是一個多步驟的過程，可確保組裝順利投入生產。 借助這種方法，我們可以在錯誤影響所有用戶之前檢測到錯誤。 如果錯誤太多，可以回滾組件的部署。 如果發布後發現特定問題，可以輕鬆發布修復程式。
Checkpoint系統的接口，用於Slack中部署項目
將新版本部署到生產環境的過程可以被認為是由四個步驟組成。
▍1. 建立發布分支
每個版本都以新的版本分支開始，這是我們 Git 歷史中的一個點。 這允許您為版本分配標籤，並提供一個可以即時修復在準備版本發佈到生產過程中發現的錯誤的位置。
▍2. 在暫存環境中部署
下一步是將程式集部署到臨時伺服器上，並對專案的整體效能執行自動測試（冒煙測試）。 登台環境是不接收外部流量的生產環境。 在此環境中，我們執行額外的手動測試。 這讓我們更有信心修改後的專案可以正常運作。 僅自動化測試不足以提供這種程度的置信度。
▍3. 在 Dogfood 和 Canary 環境中部署
部署到生產環境從測試環境開始，由一組為我們內部 Slack 工作區提供服務的主機表示。 由於我們是非常活躍的 Slack 用戶，因此採用這種方法幫助我們在部署初期發現了許多錯誤。 在我們確保系統的基本功能沒有被破壞之後，程式集被部署在金絲雀環境中。 它代表約佔生產流量 2% 的系統。
▍4. 逐步發佈到生產環境
如果新版本的監控指標穩定，並且在金絲雀環境中部署專案後沒有收到任何投訴，我們將繼續將生產伺服器逐步轉移到新版本。 部署流程分為以下階段：10%、25%、50%、75%和100%。 這樣，我們就可以慢慢將生產流量轉移到新版本的系統上。 同時，如果發現任何異常情況，我們也有時間去調查情況。
▍部署過程中出現問題怎麼辦？
修改程式碼始終存在風險。 但由於訓練有素的「部署領導者」的存在，我們能夠應對這一問題，他們管理將新版本投入生產的過程，監控監控指標並協調程式設計師發布程式碼的工作。
如果確實出現問題，我們會盡力儘早發現問題。 我們調查問題，找到導致錯誤的 PR，將其回滾，徹底分析，然後創建新的建置。 確實，有時這個問題在專案投入生產之前才被注意到。 在這種情況下，最重要的是恢復服務。 因此，在開始調查問題之前，我們立即回滾到先前的工作版本。
部署系統的建置區塊
讓我們來看看專案部署系統背後的技術。
▍快速部署
回想起來，上述工作流程似乎有些顯而易見。 但我們的部署系統並沒有立刻變成這樣。
當公司規模小得多時，我們的整個應用程式可以在 10 個 Amazon EC2 執行個體上運行。 在這種情況下部署專案意味著使用 rsync 來快速同步所有伺服器。 以前，新程式碼距離生產只有一步之遙，由暫存環境代表。 組件是在這樣的環境中創建和測試的，然後直接投入生產。 這樣的系統很容易理解；它允許任何程式設計師隨時部署他所寫的程式碼。
但隨著我們客戶數量的成長，支持該專案所需的基礎設施規模也在不斷擴大。 很快，鑑於系統的不斷增長，我們基於將新程式碼推送到伺服器的部署模型不再發揮作用。 也就是說，新增每台新伺服器意味著增加完成部署所需的時間。 即使基於並行使用 rsync 的策略也有一定的限制。
我們最終透過轉向完全並行的部署系統來解決這個問題，該系統的設計與舊系統不同。 也就是說，現在我們沒有使用同步腳本將程式碼傳送到伺服器。 現在，每個伺服器都獨立下載新組件，因為它們知道需要透過監視 Consul 金鑰變更來完成此操作。 伺服器並行載入程式碼。 這使我們即使在系統不斷增長的環境中也能保持高速部署。
1.生產伺服器監控Consul密鑰。 2. 金鑰發生變化，這告訴伺服器它們需要開始下載新程式碼。 3. 伺服器下載帶有應用程式代碼的 tarball 文件
▍原子部署
幫助我們實現多層部署系統的另一個解決方案是原子部署。
在使用原子部署之前，每次部署都可能會導致大量錯誤訊息。 事實上，將新檔案複製到生產伺服器的過程不是原子的。 這導致呼叫新函數的程式碼在函數本身可用之前就可用的時間很短。 當呼叫此類程式碼時，會導致返回內部錯誤。 這表現為 API 請求失敗和網頁損壞。
研究這個問題的團隊透過引入「熱」和「冷」目錄的概念解決了這個問題。 hot目錄中的程式碼負責處理生產流量。 在“冷”目錄中，程式碼在系統運行時只是準備使用。 在部署期間，新程式碼會複製到未使用的冷目錄中。 然後，當伺服器上沒有活動進程時，將執行即時目錄切換。
1. 將應用程式程式碼解壓縮到「冷」目錄中。 2. 將系統切換到「冷」目錄，使其變成「熱」（原子操作）
結果：重點轉向可靠性
2018 年，該專案發展到如此規模，以至於非常快速的部署開始損害產品的穩定性。 我們擁有一個非常先進的部署系統，我們投入了大量的時間和精力。 我們需要做的就是重建和改進我們的部署流程。 我們已經發展成為一家相當大的公司，其開發成果已在世界各地用於組織不間斷的通訊並解決重要問題。 因此，可靠性成為我們關注的焦點。
我們需要讓部署新 Slack 版本的過程更加安全。 這種需求促使我們改進我們的部署系統。 事實上，我們在上面討論了這個改進的系統。 在系統深處，我們繼續使用快速、原子的部署技術。 部署的方式已經改變。 我們的新系統旨在在不同層級、不同環境中逐步部署新程式碼。 我們現在使用比以前更先進的支援工具和系統監控工具。 這使我們能夠在錯誤到達最終用戶之前捕獲並修復錯誤。
但我們不會就此止步。 我們正在不斷改進這個系統，使用更先進的輔助工具和工作自動化工具。
親愛的讀者！ 在您工作的地方，部署新專案版本的流程是如何進行的？
來源： www.habr.com