在軟體工程實踐中，需要將開發完成的最終產品交付給使用者（或發布給測試部門），就需要我們將源**編譯為可執行檔案。將各個分別開發的模組集合為乙個完整的系統，這個過程成為系統整合，我們用乙個系統來描述這個整合過程。
整合系統：輸入指定的軟體資產，輸出根據軟體資產生產出的軟體產品以及其他副產品的系統。
對於一般系統而言（以vc開發為例），軟體的生產過程包括：原始碼獲取，原始碼檢查，原始碼編譯，測試，部署。經歷以上幾個過程之後得到乙個可用的系統。
故一般而言整合系統通常會按照順序經歷以下幾個模組組成：
1. 版本檢查：用於獲取**和其他必要的檔案。
2. 原始碼檢查：對於源**的靜態分析，檢查可能存在的錯誤。
3. 原始碼編譯：通過編譯器和聯結器編譯原始檔，生產可執行檔案或庫。
4. 測試：通過對編譯出來的檔案進行一定測試，並獲得測試結果。
5. 部署：若測試通過則檔案可以作為最終得到的產物用於交付。
在實踐過程中軟體的最終整合會存在各種各樣的問題而導致整合失敗，需要大量的修改和測試，而得到最終可以的交付的產品。故每次版本發布時的加班不可避免，而交付的延期也時常發生，軟體的質量不可保證。為了解決這些問題或者說減少修復這些問題所需要付出的成本，我們盡量讓這些問題提早發生（問題越早發生修復的代價越小）。因此我們可以以一定頻率對工程的更改進行整合，若整合失敗則盡早修復，以保證能夠得到可交付的產品，這樣的實踐稱為持續整合。
我們可以將系統整合的工作交由專案經理負責，讓專案經理定期整合系統並發布版本，我們稱之為人肉整合系統：
1. 版本檢查：svn或者git工具能夠check out出**的工具都可以。
2. 原始碼檢查：使用beyondcompare等工具對比原有版本，通過codereview的方式用肉眼對**進行檢查，好壞全憑專案經理的經驗。
3. 原始碼編譯：vs工程的生成功能，將源**編譯，連線，生成可執行檔案或庫。
4. 測試：跑完單元測試，對檔案的功能進行測試，或檢查是否功能完備或者bug是否已經得到修復。
5. 部署：將生成的檔案打包交付。
人肉整合系統處理了整合最大的問題，通過專案經理以一定頻率反覆執行以上過程保證交付。但是專案經理的精力完全被消耗在這個重複勞動的過程中，而且質量保證完全取決於專案經理的經驗和能力，並且不能量化結果對於決策的支援有限。以上幾個模組會被按順序重複執行，若有一定的工具可以自動完成以上模組的各個功能則可以將專案經理從繁複的重複勞動中解脫出來，大大的節省專案成本。故我們需要構建乙個自動持續整合系統來取代人肉整合系統，感謝開源工具讓我們能夠使用自動化的工具完成以上各個模組的功能，並通過ci工具反覆執行，自動整合系統同樣包含一下模組：
1. 版本檢查：svn或者git工具能夠check out出**的工具都可以。
2. 原始碼檢查：使用cpplint檢查**規範，使用cppcheck靜態檢查**缺陷，使用cppncss或sourcemonitor分析**複雜度。
3. 原始碼編譯：通過命令列呼叫vs工程的生成功能，將源**編譯，連線，生成可執行檔案或庫。
4. 測試：執行gtest和gmock進行單元測試和回歸測試，通過opencppcoverage來檢查**覆蓋率。
5. 部署：將生成的檔案打包交付。
可持續整合 Devops簡述
devops development和operations的組合詞 是一組過程 方法與系統的統稱，用於促進開發 應用程式 軟體工程 技術運營和質量保障 qa 部門之間的溝通 協作與整合。它是一種重視 軟體開發人員 dev 和 it運維技術人員 ops 之間溝通合作的文化 運動或慣例。透過自動化 軟體...
持續整合（一）
一 提出 整合軟體 的過程不是新問題，如果專案開發的規模比較小，比如乙個人的專案，如果它對 外部系統 的依賴很小，那麼軟體整合不是問題，但是隨著軟體專案複雜度的增加 即使增加乙個人 就會對整合和確保 軟體元件 能夠在一起工作提出了更多的要求 要早整合，常整合 早整合，頻繁的整合幫助專案在早期發現專案...
持續整合簡介
想起我剛畢業後，進入一家以軟體外包為主的外企做開發。它使用傳統的瀑布式的軟體開發流程，沒有使用任何的敏捷實踐。我每天上班開啟電腦，拿到自己的任務，然後從版本控制更新 開啟工程按下build，準備進行今天的開發任務。突然發現build失敗 通常是編譯不過 大喊一聲 誰break build啦 也沒有人...