CI/CD Pipeline 之 stage: prod-deploy
本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。
本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。 鐵人賽原文網址：https://ithelp.ithome.com.tw/articles/10221679）
前三天我們搞定了 CI/CD Pipeline 的 build、deploy 與 test，今天輪到 prod-deploy。
在我們的假想情境中，dev 與 stg 環境分別對應 develop 與 master branch，兩者的 CI/CD Pipeline 基本上大同小異。而 production 環境則對應 production branch，CI/CD Pipeline 則多了一個 stage: prod-deploy。
（Production branch 多了一個需要 User 去手動觸發的 CI Job prod-deploy。）
Stage: prod-deploy
首先我們要問 prod-deploy 與 deploy 到底差在哪裡？關鍵在於 Production 環境是一個客戶與使用者們正在使用中的環境，如果要將程式部署至此種環境，需要考慮的問題就多了，特別是根據程式部署時該程式（服務）是否可以下線（停機）又會產生巨大的差異。
如果 prod-deploy 時，程式（服務）是可以下線的，那麼目標 Server 就可以維持在一個靜止的狀態，維運人員就可以輕易的在部署之前先對資料庫、環境、檔案做備份，按部就班的部署程式。如果部署失敗了，也可以盡快從備份還原至上一個版本，將損害降到最小。
但如果必須要在程式（服務）維持上線的狀態下部署，那麼通常你的 Production 環境應該有一定的規模，也許有一些 HA 的架構或 Load balancer 的機制，是由多台 Server 支撐著程式（服務）。在此種狀況下，為了不影響到線上的使用者，就必須使用一些不一樣的部署策略，像是藍綠部署（Blue/Green Deployment）、金絲雀發佈（Canary Release）或 Rolling Release⋯⋯等。如果要談這些，又是另一個鐵人賽 30 天，所以同樣的這邊就不過度深入，讓我們繼續回到假想情境。
既然我們的情境是一個全新團隊正在開發全新的產品，目前產品還不算是公開發表，只有募集一批測試使用者，因此目前的 Production 環境是可以停機進行部署的。在這樣的情境 prod-deploy 要處理的問題與 deploy 差不多，一樣是 GitLab Runner 本身是否具備部署程式至 Production 環境的能力與相關的授權。如果這些問題都克服了，那麼 .gitlab-ci.yml 內的 prod-deploy 這項 CI Job 應該會類似如下：
prod-deploy:
stage: prod-deploy
only:
- production
script:
- ansible-playbook prod-deploy.yml
when: manual
environment:
name: production
url: https://production.website.com
在 Day 10 已經有提過，只要設置 when: manual 在 GitLab CI 就會自動讓該項 CI Job 變成需要人工手動觸發，只有 User 手動按下 UI 介面上的「箭頭」，GitLab Runner 才會開始執行它。
（when: manual 的 Job 會是一個齒輪的圖示，需要 User 按下右邊的箭頭才會開始執行。）
【新增補充】GitLab 的介面已經改版，下面提到的 Operations 已經被改成別的名稱，如果想知道最新的介面長成什麼模樣，你可以直接註冊一個 gitlab.com 帳號，並建立一個 project 就知道了。
今天新增加的 environment: 則是幫助你在 GitLab 上可以有獨立的介面管理部署動作。只要有成功設置 environment:，並且有成功執行過該 CI Job，在 Operations > Environments 就會出現類似下圖的介面。
（如果你針對 dev 與 stg 的 deploy 也有設置 environment:，也會一併條列於此。）
（如果部署出了問題，隨時可以按下 Re-deploy，GitLab Runner 就會幫你再次執行該 CI Job，自動重新部署。）
針對每個 environment 還可以點進去查看每一次 deploy 的紀錄。
（每一筆紀錄也會顯示並連結是對應哪一個 Commit 與哪一個 CI Job，方便關聯查看相關資訊。）
Environments 被歸納在 Operations 之下，你可以看到在 Operations 之中還有其他像是 Metrics、Error Tracking⋯⋯等和維運有關的功能。這些也是 GitLab 隨著 GitLab Workflow 發展的越來越完整，而出現的新功能，讓 GitLab 不只能做到 CI/CD，還能涉足 Ops 部分工作，成為資訊彙整的中心。
（Operations 的功能越來越多，其實最初 Environments 是獨立一個功能，在近幾次改版 GitLab 新增了 Operations 之後，才被收編在旗下。）
小結
今天我們談了最簡單的 prod-deploy，艦長只能說可以先停機再接續處理服務的維護與部署是幸福的。在現實的職場中，多是不能停機，必須即時處理的狀況，如果後續的文章進度許可，我們應該也有機會談到這方面的一些經驗談。那麼回到今天的內容，針對 prod-deploy 可能會有哪些需要處理的麻煩事呢？
- 你的 CI Server/Worker 是否具備
prod-deploy的能力與權限？ - 續上，CI Server 如具備了
prod-deploy的權限，那權限控管安全嗎？CI Server 本身的安全性足夠嗎？ - 如何做到不停機部署？如何做到大量部署至多台 Server？
- 誰擁有權限按下
prod-deploy的按鈕？又如何控管權限？ deploy與pord-deploy自動化部署腳本的內容會是一致的嗎？有必要一致嗎？- 除了程式部署之外，還有哪些額外的動作需要處理？例如是否需要設置 Nginx？是否有 DB Migrate 的動作需要處理？
扯到 Production 環境，通常要考慮的事情就會像峭壁一樣突然陡峭的攀升，上面也只是簡單列舉部分項目。後面我們還會繼續改善我們的 CI/CD Pipeline，並解答這幾天提出的一些疑問，鐵人賽我們繼續努力！