Heroku 工程團隊記錄了他們利用 Heroku 運行時（Heroku Runtime）從手動部署到自動化持續部署的過程，Heroku運行時是他們的應用程序託管環境。他們使用 Heroku 原語和自定義部署工具實現了這一目標。
Heroku 運行時團隊可以構建和運維單一（私有空間，Private Space/PS）及多租戶（公共運行時，Common Runtime/CR）環境。這包括容器編排、路由和日誌記錄。在此之前，該團隊需要遵循的部署流程是由多個手動步驟組成的，包括主要值班工程師的簽字、預留足夠的緩衝區以監控部署後的情況以及對多個儀表板的監控。如果還需要部署其他區域和服務，則必須等到該次部署全部穩定之後，這也會帶來相應的開銷。由於當時團隊規模較小，並且服務和區域僅限於美國和歐盟 2 種生產環境，所以這種方法是可行的。隨着團隊成員數量的增加以及將 CR 重新構建成一個面向多服務的長期項目，團隊必須進行自動化實踐並構建一個可以自動化部署工具。
InfoQ 聯繫了 Heroku 的主要技術人員 Bernerd Schaefer， 以進一步瞭解他們所面臨的挑戰以及相應解決方案的細節。
之前的流程依賴於團隊的規模和對預期效果的詳細手動計劃。Direwolf 是一個測試平臺，它可以上報跨區域的狀態。當團隊成員增加到 30 多人時，這個過程會變得很繁瑣。再加上 CR管理架構改造（將 CR 的單體 Ruby 應用程序分割成多服務）的挑戰。團隊決定推行完全自動化。該應用程序在兩個生產環境中運行，手動步驟會導致更高的協調成本。
團隊的解決方案是使用現有的 Heroku 原語和一個名爲 cedar-service-deployer 的自定義工具。每個服務都會成爲管道（Pipeline）的一部分，並且共享服務作爲長期項目的一部分部署在跨多個預生產（staging）和生產（prod）環境中。cedar-service-deployer tools 工具是使用 Go 編寫的，它可以掃描管道以發現不同階段之間的差異。如果掃描到任何差異，它將運行檢查程序以查看是否可以將代碼提交到下一個階段。這些檢查包括髮布時間、足夠的集成測試時間、正在運行的事件（incident）、正在觸發的告警、只能從主幹分支進行升級等。Schaefer 說到，添加新檢查需要變更代碼，因爲該列表是固定的。同時，他還解釋到，團隊可以配置自己的告警：
團隊可以配置單個服務所需要檢查的服務項，特別是要監控哪些告警以確定服務的健康狀況。例如，某個服務可能有一個告警是用來檢查服務是否啓動的，一個是用來檢查其 HTTP 成功率是否超過99%，向部署程序中添加這些服務的團隊可以在 JSON 文件中配置告警，以便對部署程序服務在發佈期間進行監控。
監控和告警是部署的重要組成部分，因爲它們可以指出可能存在的問題。Heroku 使用 Librato 收集度量指標和告警。Schaefer 說，還有一些其他的系統也可以進行監控，但是到目前爲止，部署程序所控制的所有服務都是使用的 Librato。
Schaefer 進一步闡述了他們的監控理念：
我們一直在推動的一件事情是將監控引入到我們的標準服務工具包中，以便每個服務在默認情況下都具有有用的工具。當然，隨着服務投入生產並進入成熟階段，它們可能需要一些定製的工具。但是我們的目標是，服務開發人員可以專注於他們服務所提供的功能，併成爲對應功能的專家，而無需成爲度量指標收集、跟蹤或其他我們想知道的系統運行情況的專家。
儘管在大多數情況下，部署程序可以自動決定是否推送，但是我們仍提供了手動覆蓋的規則。Schaefer 解釋道：
系統總是允許運維人員使用現有的手動工具來進行發佈。我們可能會在事件期間執行此操作，以便將關鍵的熱修復程序補丁發佈到受影響的環境中。在一個事件中，很少還會推送其他的變更，因爲如果有某項事件正在進行中的話，我們會盡力減少其他對生產環境的變更，而且人們很少會急於將產品發佈上去，但是如果需要的話，這種能力也是存在的。
部署程序的無狀態特性意味着它的工作方式可以嘗試在管道中任意兩個階段之間進行升級，而不是綁定到單個“發佈”版本上。這使得多個提交點可以同時出現在部署管道的不同階段。
原文鏈接：