想起我剛畢業後，進入一家以軟體外包為主的外企做開發。它使用傳統的瀑布式的軟體開發流程，沒有使用任何的敏捷實踐。我每天上班開啟電腦，拿到自己的任務，然後從版本控制更新**，開啟工程按下build，準備進行今天的開發任務。突然發現build失敗（通常是編譯不過），大喊一聲「誰break build啦」，也沒有人響應，自己乙個人鬱悶，接著檢視是哪些檔案導致編譯失敗，找到最後的提交人，讓他去fix build。後來團隊裡如果某個人break build，其他某些團隊成員就在msn的簽名上寫著「*** break build，今天要請客吃飯」等等。其實build失敗在軟體開發過程中會經常出現，不同的程式設計師實現自己的模組，寫單元測試，完成後提交**，難免會造成衝突導致build失敗。但是對於開發者來說，應當能夠最快的獲得當前build的反饋，如果該build失敗必須在最短的時間內修復它，以免它影響其他人的開發進度。
build具體包括哪些內容呢？它不僅僅指的是編譯**，而是指編譯**，執行所有的測試（包括單元測試，功能測試等），執行**分析（比如分析**是否符合編碼規範），部署系統（產生可執行的軟體，或者把**部署到web伺服器上）。build是一系列的過程用來保證**能夠執行，能夠正確的執行，最後能發布出來。
在敏捷開發中，有乙個很重要的實踐叫做持續整合。而什麼是持續整合呢？簡單來說，持續整合是頻繁、持續的在多個團隊成員的工作中進行整合，並且給與反饋。乙個典型的持續整合週期包括以下幾個步驟：
持續整合伺服器不斷從版本控**務器上檢查**狀態，看**是否有更新。
等**完全更新以後，呼叫自動化編譯指令碼，進行**編譯。
執行所有的自動化測試。
進行**分析。
產生可執行的軟體，能夠提供給測試人員進行測試。
如果其中任何乙個步驟失敗，就表示該build失敗，持續整合伺服器會給予相應的反饋。一般來說，持續整合伺服器會有相應的管理介面，可以看到build的狀態以及相應的資訊，如果build失敗，可以檢視原因，是編譯失敗還是測試失敗。或者在每次build後，持續整合伺服器發郵件通知，從郵件中可以看到最新build的狀態。當然，也可以自定義反饋方法，比如在thoughtworks中國，有個團隊的持續整合反饋就是火山燈，黃色表示正在進行build，綠色表示build成功，而紅色則表示build失敗，一旦發現燈變紅了，所有人都不能提交**，而應該盡快修復該build。還有乙個團隊更有創意，用語音來進行反饋。如果build成功，就會有語言提示說「build ***x成功」，如果失敗，就會有提示「build ***x失敗，是由***提交的」，被唸到名字的成員就得停下來修復這個build。
持續整合實踐的目的不是減少build失敗的次數，而是盡早發現問題，在最短的時間內解決問題，減少風險和浪費。如果想嘗試持續整合，首先需要的是持續整合伺服器，比如cruisecontrol或者vsts；然後需要把現有的build自動化，比如寫ant指令碼；最後就是在持續整合伺服器上進行配置，比如配置版本控制，整合間隔時間，如何部署，如何反饋等。
持續整合簡介
一 持續整合 持續整合是一種軟體開發的實踐，即團隊開發成員經常整合他們的工作，通常每個成員每天至少整合一次，也就意味著每天可能會發生多次整合。每次整合都通過自動化的構建 包括編譯，發布，自動化測試 來驗證，從而盡快地發現整合錯誤。許多團隊發現這個過程可以大大減少整合的問題，讓團隊能夠更快的開發內聚的...
持續整合簡介
想起我剛畢業後，進入一家以軟體外包為主的外企做開發。它使用傳統的瀑布式的軟體開發流程，沒有使用任何的敏捷實踐。我每天上班開啟電腦，拿到自己的任 務，然後從版本控制更新 開啟工程按下build，準備進行今天的開發任務。突然發現build失敗 通常是編譯不過 大喊一聲 誰break build啦 也沒有...
持續整合 hudson sonar簡介
hudson是乙個可擴充套件的持續整合引擎。主要用於 持續 自動地構建 測試軟體專案.監控一些定時執行的任務。sonar是乙個開源的質量管理平台，專注於從專案到類方法的持續的分析和測量技術質量，它把 質量相關軟體整合到一起統一管理 簡單來說，hudson是持續 自動地構建 測試軟體專案，而sonar...