是軟體工程領域中的一種最佳實踐，即鼓勵研發人員頻繁向主幹分支提交
**，頻率為每天至少一次，每次提交都觸發完整的編譯構建和自動化測試流程。縮短
反饋週期，及時修復問題。
維護乙個單一的**庫
維護乙個單一的製品倉庫
使構建自動化
使構建自測試
沒人每天都向主線提交**
每次提交都應該在整合機上進行構建
快速構建
使任何人都能輕易獲得可執行檔案
人人都能看到正在發生什麼
自動化部署
把我們所有要交付的二進位製包放在同乙個地方去管理，這樣的好處是，當我們線上有問題需要回退的時候，需要重新部署的時候，我們在通過原始碼去重新構建製品，沒把發找回當時的環境了，所以存製品的優勢可以直接從製品中恢復線上。
要進行到第三點，要有很多任務具的建設，很多規範的建設，很多度量的建設。
持續整合（一）
一 提出 整合軟體 的過程不是新問題，如果專案開發的規模比較小，比如乙個人的專案，如果它對 外部系統 的依賴很小，那麼軟體整合不是問題，但是隨著軟體專案複雜度的增加 即使增加乙個人 就會對整合和確保 軟體元件 能夠在一起工作提出了更多的要求 要早整合，常整合 早整合，頻繁的整合幫助專案在早期發現專案...
持續整合簡介
想起我剛畢業後，進入一家以軟體外包為主的外企做開發。它使用傳統的瀑布式的軟體開發流程，沒有使用任何的敏捷實踐。我每天上班開啟電腦，拿到自己的任務，然後從版本控制更新 開啟工程按下build，準備進行今天的開發任務。突然發現build失敗 通常是編譯不過 大喊一聲 誰break build啦 也沒有人...
持續整合 CI
引子 記得剛加入趨勢開始開發工作 的時候曾被告知，趨勢有一套auto build的系統，會每天夜裡自動把當天check in的 進行構建，生成qa可測試 的build。每個rd都得小心提交code，因為專案結束的時候會看auto build的失敗率。可是構建失敗總是在所難免，尤其是每次要提交cand...