持續整合簡介

2021-09-02 11:56:09 字數 1411 閱讀 5628

想起我剛畢業後,進入一家以軟體外包為主的外企做開發。它使用傳統的瀑布式的軟體開發流程,沒有使用任何的敏捷實踐。我每天上班開啟電腦,拿到自己的任 務,然後從版本控制更新**,開啟工程按下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...