# 什麼是持續整合和持續交付/部署？
本節探討持續整合和持續交付的實務做法，並說明持續交付和持續部署之間的區別。
## 持續整合
持續整合 (CI) 是一種軟體開發實務，開發人員會定期將其程式碼變更合併到一個中央儲存庫中，然後執行自動化建置和測試。CI 最常指的是軟體發行程序的建置或整合階段，並且同時需要自動化元件 (例如 CI 或建置服務) 和文化元件 (例如經常學習整合)。CI 的關鍵目標是更快發現和解決錯誤、改善軟體品質，以及減少驗證和發行新軟體更新所需的時間。
持續整合側重於整合較少量的遞交和較少量的程式碼變更。開發人員需定期遞交程式碼，至少每天一次。開發人員會從程式碼儲存庫中提取程式碼，確保在推送到組建伺服器之前先合併本地主機上的程式碼。在這個階段，組建伺服器會執行各種測試，並接受或拒絕程式碼遞交。
實作 CI 的基本挑戰，包括更頻繁地遞交至通用程式碼基底、維護單一原始檔儲存庫、自動化建置和自動化測試。其他挑戰包括在與生產相似的環境中進行測試，讓團隊能看到程序，並讓開發人員可輕鬆取得任何版本的應用程式。
## 持續交付和部署
持續交付 (CD) 是一項軟體開發實務，在此實務中會自動建置、測試和準備程式碼變更，以進行生產發行。持續交付會在建置階段完成之後，將所有程式碼變更部署到測試環境、生產環境或同時部署到兩者，藉此擴張持續整合。持續交付可以透過工作流程程序完全自動化，也可以在關鍵點透過手動步驟實現部分自動化。在適當地實作持續交付時，開發人員一律都會有已通過標準化測試程序，且準備好部署的建置成品。
透過持續部署，修訂版本會自動部署到生產環境，而不需要開發人員的明確核准，如此可能讓整個軟體的發行程序自動化。這反過來又可以在產品生命週期的早期提供持續的客戶回饋迴圈。
## 持續交付不是持續部署
關於持續交付的其中一個誤解是，這表示所遞交的每一項變更，都會在通過自動化測試後立即套用到生產環境中。但是，持續交付的重點不是立即將每一項變更都套用到生產，而是確保每一項更改都已準備好可進入生產環境。
在將變更部署到生產環境之前，可以實作一個決策程序，確保已授權該生產部署，且會經過稽核。這項決定可以由一個人決定，然後由工具執行。
使用持續交付，上線的決策會成為一項業務決策，而非技術決策。每次遞交都會進行技術驗證。
將變更推出到生產環境不是一項干擾性事件。部署不需要技術團隊停止進行下一組變更，且不需要專案計劃、交接文件，或是維護時段。部署會成為一項可重複執行的程序，在測試環境中多次執行及進行驗證。