Rails 部署實踐 - 持續部署

採用容器化技術能夠讓我們更加容易的部署到任何環境，相較於過去我們需要使用 Chef 這類工具在新節點加入時進行 Porvision（環境準備）或者預先進行鏡像的製作（像是 AWS 的 AMI 硬碟）等等，使用容易更加容易，那麼我們就沒有理由不進行持續的部署。

持續整合

如果想要進行持續部署，那麼持續整合就會是一個不可或缺的條件。要確保持續整合的程式碼沒有問題、可以安全地透過持續部署發佈出去我們就會需要借助一些工具。

• 程式碼風格檢測，像是使用 Rubocop 來確保團隊撰寫的風格不會差異太大
• 自動化測試
  • 端對端測試（E2E Testing）用於驗證使用者可操作的功能正常
  • 單元測試（Unit Testing）用於驗證端對端測試沒有涵蓋的細節（Ex. 驗證條件）
• 安全性掃描，像是使用 Trivy 用於檢查容器鏡像以及內含的套件是否有已知漏洞

以上是比較常見的處理，根據不同團隊和專案需求可能會有更多更複雜的步驟，經過這些預先處理後，我們才算是初步的具備持續部署的條件。

目前我們會專注在持續部署的配置上，關於持續整合的部分暫時不會詳細討論。

持續部署

當我們完成持續整合的配置之後，我們就可以開始利用像是 GitLab CI、GitHub Actions 這類工具，幫助我們進行部署的準備。

在前面的章節中，我們都是用「人工」的方式操作以及建置，這表示大多數的處理都是「線性」的，然而在持續部署中我們可以將這些任務拆解成並行的任務同時處理產生「生成物（Artifacts）」最後再進行合併。

以 Rails 專案為例子，我們可以將 Assets Precompile（素材預先編譯）的動作抽離出容器鏡像的建置，假設還有一些設定檔、資料的抓取也都可以在這個階段同時進行，當我們完成這些處理產生生成物之後，就可以使用 Docker 建置出最終用於部署的容器鏡像，然後發布（Deploy）出去。

如果想在第一時間收到更新，歡迎訂閱弦而時習之在這系列文章更新時收到通知，如果有希望了解的知識，可以利用Rails 部署實踐回饋表單告訴我。