隨著軟體業的不斷發展，軟體專案的規模越來越大，軟體結構越來越複雜，技術要求越來越高，參與人員越來越多，管理也變得越來越難。在這樣乙個大背景下，如何提高軟體研發質量，相信是所有軟體公司都在關注的話題。但是，如何提供研發質量，這決不僅僅是乙個口號，我們必須有一套行之有效的方法加以管理。然而有效的管理帶來的負面影響往往是成本的提高，這包括時間的成本、人力的成本、資金的成本。在大多數軟體研發專案中，時間總是很緊，人力和資金也是有限的。這樣，管理者往往步入一種兩難的境地：一方面為了提高研發質量而需要加大對時間、人力、資金的投入，另一方面現實情況卻不允許我們這樣做，這也是很多管理制度不能真正實施下去的原因。難倒沒有第三種方案能兼顧二者嗎？時下正流行的持續整合技術為我們提供了乙個答案。
持續整合（continuous integration，簡稱ci），又被稱為持續構建（continuous build），最初是以一種研發管理的思想被提出來。2023年，持續整合的思想首先在kent beck的極限程式設計中被提了出來。kent beck在他的書中是這樣描述的：「團隊程式設計就是先分而治之地解決問題，然後整合。但整合的過程是不可預知的，你等待整合的時間越長，付出的代價就可能越高。因此，每完成一段時間程式設計，系統就應當進行一次整合，並進行相應的測試。」kent beck先生將這裡的「一段時間」設定在幾個小時，並提出了整合的同時應當進行測試的思想（這就是敏捷開發中的測試驅動設計）。
後來，持續整合的思想被敏捷開發所吸收，並進一步提出了增量開發的思想。過去，我們解決複雜軟體系統問題的程式設計思想是分而治之。所謂分而治之，就是將大系統劃分成若干小模組，再劃分為乙個個小問題，分別予以解決，最後再整合。運用這樣的思想，整合的週期必然很長，可能是數週甚至數月，其風險不言而喻。
增量開發改變了這樣的思想。雖然它依然是將大系統劃分為無數的小模組、小問題，但它不是一股腦地立即去解決所有問題，而是有選擇性地解決最核心、最主要的問題，然後再以進化的方式增量開發、逐漸完善，進而解決其它問題。在這樣乙個過程中，每進化一次就整合一次，產生乙個可執行的成果，以此迴圈往復，直到最終完成。這樣乙個過程就是迭代式軟體開發的過程（詳見[url=一次迭代式開發的研究：怎樣進行迭代式開發》[/url]）。
然而，採用持續整合的方式固然好，但每幾個小時就要整合一次、測試一次，如果人為地去完成，成本依然是巨大的。因而，在敏捷開發大師martin fowler的推動下，持續整合工具誕生了。
持續整合工具將不可靠的人為操作，轉變成了機械自動化操作，使不提高專案成本的前提下提高了研發質量成為了可能。
[url=如何提高研發質量與持續整合[/url]
[url=持續整合工具簡介[/url]
[url=持續整合工具是怎樣工作的？[/url]
（續）
持續整合質量保證方案
需求評審 介面 使用者介面 功能 效能 安全性 單元測試 junit 掃瞄 sonar 依賴檢查 引用包安全性 測試用例評審 實際評審和需求及開發會並行進行 介面測試 postman http介面 自定義測試工具 dubbo jsf http介面 robot framework 功能測試 robot...
整合與持續整合介紹
簡單來說，就是把開發好的 提交到系統中，就是整合。持續整合就是頻繁的 一天多次 將 整合到主幹。1 快速發現錯誤。每完成一點更新，就整合到主幹，可以快速發現錯誤，定位錯誤也比較容易。2 節省人力成本 3 加快軟體開發進度 4 實時交付 讓產品可以快速迭代，同時還能保持高質量。在整合到主幹之前，先進行...
fastlane與持續整合
如果xcode公升級到了最新版本，請執行sudo gem install fastlane，確保安裝最新版本的fastlane。fastlane會執行一些xcodebuild命令，有可能因超時而失敗，預設的timeout是10秒，retry times是4次，一般只需要把timeout延長就好了，方...