認識部署
「部署」是程式開發中相當重要的一項工作，甚至說是最重要的也不為過。完成「部署」，使用者才有辦法使用。可以使用的程式，才是一份有價值的程式。
我們來看一下從開發程式到交付給使用者的過程中，通常有哪些步驟
今天要來看看我們如何在部署流程加入 CI/CD 來減少部署的成本，以及這些改變帶來什麼好處。
第零階段：沒有 CI/CD 的部署方式
在還沒有 CI/CD 時，基本上就是有各式各樣的 「腳本 (shell script)」 來輔助工程師完成部署。整個部署作業都是設計在工程師的「筆電」上進行
部署流程:
部署流程痛點
這樣的流程有幾個明顯的特色:
- 大量人工作業 (費時)
- 複雜且沒有結構的腳本 (難維護、難上手、不可靠)
- 筆電環境 (可靠度差)
費時
工程師要花很多時間才可以完成部署。粗略的調查處理部署的時間約 30 分 ~ 2 小時左右，遇到非預期的錯誤更是大大的拉長處理時間。
難維護
沒有結構的腳本包含許多任務，讓腳本變得十分複雜。隨著時間的推進累積了不少的技術債，更加拉高維護難度了。
難上手
繁鎖的步驟、複雜的腳本跟環境都讓工程師無法快速上手，大概要花上 3 ~ 4 個工作天才有辦法獨立進行部署作業。
不可靠
整個部署過程的可靠度是很差的，大量人工作業容易發生人為錯誤，沒有結構的腳本常常遇到非預期的失敗，筆電會因為每個人的使用方式不同，遇到一些奇奇怪怪的問題。
第一階段：在 CI 自動化測試
通過「測試」是部署前的關鍵步驟，也是平常開發時很頻繁會做的工作。
所以我們先從「自動化測試」下手，建立 CI pipeline，把「測試」跟一些「程式碼檢查」的工作，交給 CI 處理。
CI 選用 Gitlab，他功能完善的，基本的使用情境都可以辦到，節省到處找工具的時間。跟第三方的系統整合性良好，未來想要擴充其他功能也很容易。
CI 流程:
有了 CI 的幫助，部署流程有些微的簡化:
分析成果
節省時間
有了 CI 自動跑測試，工程師省下來部署前要跑測試的時間大概 10 分鐘。 粗略的調查部署時間大約 20分 ~ 2小時。
開發程式時明顯有感，只要程式推到 Gitlab，過個幾分鐘就可以知道測試結果
更可靠的測試成果
相較於在筆電上跑測試會有各種不確定因素影響結果，在 CI 內跑測試是最正確的程式碼跟最乾淨的環境，保證了測試結果的可信度。
第二階段：在 CI 建置，替換工具
在要部署的時候才開始建置(build)程式碼總是要花上很長的一段等待時間，所以這件工作也交給 CI 處理。由 CI 準備好可以部署的程式碼壓縮檔，放到 AWS S3 上。
CI 流程擴充:
shell script 已經發展成難以理解的地步，無法跟上總個部署方式的變化，所以用 Ansible Playbook 取代。Ansible Playbook 有多伺服器管理功能以及許多的模組可以使用，我們可以製作出結構清楚而已容易使用的 Playbook。
再來為了讓部署不再被「筆電」這個不穩定的因素干擾，我們開了一台部署專用的伺服器。
部署流程簡化:
分析成果
節省時間
整個建置工作交給 CI 後，工程師省下的相當多的時間，配合著 CI 環境的需要，一些細節也一併改善，部署時間有了大符的縮短，所需時間約剩 10 ~ 20 分鐘。
好維護
換成 Ansible Playbook 後，可以輕鬆的配合架構的變化進行調整，設計架構時不再有後顧之憂。
易上手
Ansible Playbook 的環境建置簡單，加上有了部署伺服器，一人準備完成，團隊全員受惠。使用上也很輕鬆，簡單的指令啟動，有清楚的執行過程回饋，遇到狀況容易排除。工程師只要花半天時間，便可以獨立作業了。
更可靠的程式跟環境
統一於 CI 建置程式還額外的保證程式是正確可靠的，不會有混入不相關的檔案或是缺少檔案。
有了部署伺服器，團隊不再需要每個人都為了部署去調效自己的筆電。只要登入伺服器就可以進行部署。
第三階段：設定檔加入版本控制
登入伺服器去調整設定檔是一個高風險的行為。一個不小心的失誤，系統可能就直接停擺。
在這個階段我們將「程式設定檔」加入「版本控制」裡，並由 Ansible Playbook 一起跟程式部署。
CI 流程不變:
部署流程簡化:
分析成果
節省時間
這次再度少了一個人工作業步驟，部署時間又少了一點，大約 5 ~ 10 分鐘便可以完成部署。
降低風險
因為不會在正式環境上修改檔案，正式環境的服務出事的風險變得更低。
有修改記錄
設定檔的有了「版本控制」，代表我們可以查看每次的異動內容，更可以自由的還原或是切換到任何一個版本。
第四階段：用 CI/CD 自動化部署
我們有以 javascript 開發的前端專案，運作的環境在 AWS S3 跟 CDN，部署的環境相對單純。
因此我們選擇將這個專案的部署方式做更進一步的改進，全部交給 CI/CD 處理。
CI/CD 流程:
分析成果
節省時間
全部工作交給 CI/CD 處理後，不再有人工部署的時間。
無障礙上手
工程師只要知道什麼動作會觸發部署，並決定什麼時候要觸發就可以了。
減少部署成本總結
我們來看一看這一系列的改變，減少哪些成本，增加哪些優勢。
解決痛點成果
節省時間成本
部署時間從最久要 2 小時，縮減到最久只要 10 分鐘。如果每週部署一次的話，一個月省下了 7 小時 20 分鐘。不過實際的部署頻率應該是更高，所以節省的時間不只這樣。
維護容易
部署流程經過一連串的改進之後，建立很清楚的流程，流程中的每個步驟都有明確的任務。加上所選擇的 Gitlab CI 跟 Ansible Playbook，讓部署這件事更加有彈性，可以視系統架構的變化輕鬆的調整。
上手簡單
複雜的流程跟環境被大符度的簡化之後，工程師學習的難度大大降低了，花費的時間也明顯減少。我調查團隊成員在學習處理部署這件事需要的時間從約 4 天變成約 30 分鐘，時間數據或許不是那麼客觀，但也足夠呈現出工程師對難度降低是明顯有感的。
可靠度增加
隨著人工作業的步驟變少，我們更加的不用擔心人為的操作失誤。 規畫良好的 CI/CD pipeline 保證了程式碼隨時都是通過測試的可部署版本。
額外的好處
除了解決原本我們觀注的問題之外，還另外帶來其他額外的好處
完整的記錄
現在的系統中 CI 每次執行都會有記錄，設定檔每次異動都會有記錄。這些記錄提升了部署運作的透明度，幫助我們隨時了解開發跟部署的狀況。
更專注於開發
除了部署，CI 上的自動化測試也大大的減少開發過程的測試時間，省下來的這些時間，讓工程師可以更專注在開發上。
結束了嗎?
CI/CD 無法一步到位，是持續在進化的。直接現在，我們不時的會踩到問題，但我們依然不斷的尋找更好的解決辦法，持續的在最佳化我們的 CI/CD 流程。