CI/CD 是持續整合（continuous integration）和持續交付（continuous delivery，或持續部署）的簡稱，指把程式修改由開發人員的電腦送到運行中網站或 App 的步驟自動化。團隊不必每次都靠人手建置、檢查和發佈，而是由流水線（pipeline）對每項修改按同一次序執行同一套約定好的步驟。
CI 和 CD 各指甚麼
- 持續整合（CI）：開發人員頻繁把修改合併到共用的程式碼庫，每次合併都會自動觸發建置和一組檢查，例如自動化測試。問題在修改後不久便會出現，仍然容易追查。
- 持續交付（CD）：檢查通過後，修改會被打包並準備好，可以發佈到測試或正式環境。最後的發佈通常仍由人員批准。
- 持續部署：再進一步，通過所有檢查的修改會自動上線，不需要人手批准。並非每個團隊或企業都想這樣做。
「CD」可以指交付，也可以指部署，因此不妨向供應商確認他們指的是哪一種。
典型流水線會做甚麼
流水線因項目而異，常見步驟包括：
- 建置：把原始碼轉成可以運行的版本。
- 自動化測試：測試較小的邏輯單元，也測試較完整的流程。每次修改後重複執行以往的檢查，正是回歸測試的概念。
- 程式碼和依賴項檢查：按項目的設定，套用格式規則，並檢查項目所用的程式庫有沒有已知問題。
- 部署到 Staging 環境：把建置結果放到 Staging 環境 供進一步審閱。
- 發佈到正式環境：經批准後或自動把修改發佈到正式系統，並最好設有回復到上一版本的方法。
如果其中一個步驟失敗，流水線會停下來並通知團隊，有問題的修改就不會繼續前進。
委託開發軟件時為何要留意
- 減少人手失誤：寫成程式的步驟每次都以同一方式執行，較不容易被遺漏。
- 及早得到回饋：有問題的修改在流水線內已被發現，不用等客戶發現。
- 發佈規模較小：頻密的小修改，比一次過發佈一大批內容更容易審閱，也更容易撤回。
- 有發佈記錄：流水線記錄顯示哪個版本去了哪裏，以及通過了哪些檢查。
CI/CD 做不到的事
- 不能取代良好的測試。流水線只會執行已經存在的檢查。如果沒有測試涵蓋預約或付款，流水線通過並不代表這些功能沒有問題。
- 不能取代業務方面的審閱。員工和客戶仍需確認軟件符合實際工作，例如透過用戶驗收測試。
- 設定和維護都需要投入。需要有測試、環境、權限，以及負責保持流水線運作的人。
- 並非每個項目都同樣需要。很少更新的小型網站，用較簡單的流程可能已經足夠。
以下為說明用例子：一間小公司經營網上預約系統。開發人員修改了時段的選擇方式。流水線建置這項修改，執行包括預約流程在內的自動化測試，再部署到 Staging 環境。員工在 Staging 環境試用新畫面，再由指定人員批准發佈到正式系統。如果預約測試失敗，修改會在到達 Staging 環境前停下，開發人員也會收到通知。
應向開發團隊查詢的問題
- 有沒有自動化流水線？它會執行哪些步驟？
- 哪些測試會自動執行？涵蓋哪些主要流程？
- 每項修改是否都會經過 Staging 環境？
- 誰負責批准發佈到正式環境？發佈如何安排時間？
- 發佈後如何回復到上一版本？由誰操作？
- 交接後，誰負責維護流水線，並保管其存取金鑰和機密資料？
針對關鍵用戶流程的自動化檢查，可以是流水線的其中一個步驟，也可以在用戶收到修改前，針對 Staging 版本或發佈候選版本執行。想了解 technine.io 的做法，請參閱我們的自動化 UI 測試服務。系統上線後，發佈、監察和維護通常由託管支援及 SLA涵蓋。
常見問題
CI/CD 只適用於大型企業嗎？
不是。這些做法適用於任何規模的項目，小項目的流水線也可以很簡單。不少程式碼託管和雲端平台都內置基本的流水線工具，但仍然需要有人決定執行哪些檢查，並持續更新。
用了 CI/CD，網站是否每天更新很多次？
不一定。CI/CD 讓發佈有固定做法，風險也較低。多久發佈一次屬於業務決定，不少團隊按預定時間表發佈。
CI/CD 等於 DevOps 嗎？
不等於。DevOps 是讓開發和營運團隊互相配合的較廣泛工作方式，CI/CD 是其中一套做法。