自動化是將繁瑣的工作交給機器執行。作為程式設計師，我們擅長為其他人打造自動化服務，但自己的工作卻應用得不夠。

持續整合的核心#

持續整合（Continuous Integration, CI） 的關鍵是：快速回饋。

盡早提交程式碼去整合。通過盡早整合，減少改動量，降低整合的難度。

持續整合的紀律#

1. 只有 CI 伺服器處於綠色狀態才能提交程式碼
2. CI 伺服器一旦檢查出錯，要立即修復
3. 本地檢查通過之後再提交

持續整合作為主線#

持續整合可以將諸多實踐貫穿起來：

flowchart TB
    subgraph 任務分解路線
        CI1[持續整合] --> A1[穩定的開發分支]
        A1 --> A2[頻繁提交]
        A2 --> A3[足夠小的任務]
        A3 --> A4[任務分解]
    end

    subgraph 測試驅動路線
        CI2[持續整合] --> B1[可檢查]
        B1 --> B2[測試防護網]
        B2 --> B3[測試覆蓋率]
        B3 --> B4[單元測試]
        B4 --> B5[可測試程式碼]
        B5 --> B6[軟體設計]
    end

    style CI1 fill:#4CAF50,color:#fff
    style CI2 fill:#4CAF50,color:#fff

主分支開發模型#

主分支開發（Trunk-Based Development） 是一種更好的開發分支模型：

• 所有開發者在同一個主分支上工作
• 頻繁提交小改動
• 避免長期分支帶來的合併地獄

多個功能並行開發時如何處理？

可以考慮使用 Feature Toggle（功能開關）：在程式碼中用條件判斷控制功能的啟用與否。

在遺留系統上工作#

如果在遺留系統上做改造，可以考慮使用 Branch by Abstraction：

1. 建立抽象層
2. 讓舊實現和新實現都實現這個抽象
3. 逐步遷移到新實現
4. 移除舊實現

重構#

在不改變軟體外部行為的前提下，改善其內部結構。

重構的時機#

• 有測試保護時才重構
• 小步前進，頻繁驗證
• TDD 的「紅-綠-重構」循環

重構的前提#

1. 有足夠的測試覆蓋
2. 每次只做一小步
3. 頻繁運行測試

沒有測試保護的「重構」不是重構，是冒險。

自動化的思維#

自動化不只是寫程式碼：

• 考慮不自動化之前是怎麼做的
• 是否有現成的服務可以購買
• 有時候不寫程式碼而解決問題，可能才是好方案

很多需求的提出，只是因為「我們有一個開發團隊」而已。問問看是否真的需要自己開發。

迭代 0#

在專案開始之前，做好一些基礎準備：

• 開發環境設置
• CI/CD 管線建立
• 程式碼規範確定
• 基礎架構搭建
• 團隊約定建立

設計你的迭代 0 清單，給自己的專案做體檢。

有效的回饋方式#

• CI 監視器：大螢幕顯示建置狀態
• 即時通知：建置失敗時發送通知
• 本地預檢：提交前在本地運行檢查

實戰指南#