持續集成編譯增量代碼
㈠ 持續集成的工具都有哪些
目前市場上主流的持續集成工具很多
例如 CruiseControL，hudson ，jenkins，還有apache的Continuum 等 開源的持續集成工具,
CruiseControl ：簡稱 CC ，持續集成工具，主要提供了基於版本管理工具 ( 如 CVS、VSS、SVN) 感知變化或每天定時的持續集成，並提供持續集成報告、 Email 、 Jabber 等等方式通知相關負責人，其要求是需要進行日構建的項目已編寫好全自動的項目編譯腳本 ( 可基於 Maven 或 Ant) 。由於該工具配置以及部署很麻煩 且版本很久沒有更新
hudson 但是由於被oracle收購 很多以前開源的東西 以後很可能被ORACLE私有化
Hudson是Jenkins的前身，是基於Java開發的一種持續集成工具，用於監控程序重復的工作，包括：
1、持續的軟體版本發布/測試項目。
2、監控外部調用執行的工作。
㈡ 淺談持續集成在軟體項目管理中的作用
淺談持續集成在軟體項目管理中的作用
【摘要】：持續集成是極限編程12個基本原則之一，正在被越來越多的團隊所採用。軟體項目管理涉及到九大知識領域，貫穿於軟體過程的始終，目的是為了讓軟體項目的整個軟體生命周期(從分析、設計、編碼到測試、維護全過程)都能在管理者的控制之下，以預定成本按期，按質的完成軟體交付用戶使用。持續集成這種軟體開發實踐，對於軟體項目管理的各個領域的管理有著積極的作用。
【關鍵詞】：持續集成軟體項目管理統一的代碼庫構建
一、引言
軟體項目經理不但要用管理知識管理整個項目.還要為他們的團隊選擇更好的技術實踐在軟體開發的眾多技術實踐中持續集成已經被越來越多的團隊所採用持續集成對於軟體項目管理的各個領域的管理有著積極的作用，持續集成的使用會給開發尉隊的管理帶來很多的好處.做為管理者的項目經理以及團隊成員都可以從中受益。
二、持續集成與軟體項目管理
1、什麼是持續集成
“持續集成”起源於極限編程開發.是它的12個基本原則之一”持續集成”是一種軟體開發實踐.它要求開發小組的每個成員頻繁的集成他們的工作成果.這個頻度通常是至少每天一次有時甚至每天多次開發團隊的成員頻繁的整合他們之問的工作.這種整合不是簡單的組裝軟體每次的集成通過一個包含測試的構建去盡快的探測潛在的錯誤.保證軟體現有的功能不被破壞，自動分析現有代碼的狀態f有無重復邏輯.代碼的復雜度等)並發布相關的報告。通過快速反饋，開發人員可以了解軟體集成的情況.對不成功的集成進行快速的修改.從而提高軟體開發的效率和質量
2、什麼是軟體項目管理
軟體項目管理是為了使軟體項目能夠按照預定的成本、進度、質量順利完成，而對人員(People)、產品(ProdU(2t)、過程(Protess)和項目fProject)進行分析和管理的活動。
為使軟體項目開發獲得成功.關鍵問題是必須對軟體項目的工作范圍、可能風險、需要資源(人、硬體/軟體)、要實現的.任務、經歷的里程碑、花費工作量(成本)、進度安排等做到心中有數.掌握整個軟體的開發進程。
三、持續集成對軟體項目管理的作用
l、對項目目標管理的作用
軟體項目的目標是開發出可運行的、客戶滿意的軟體系統持續集成有統一的代碼庫。要求開發人員定期地、不斷地向代碼庫提交代碼。新近提交的代碼會經過編譯與測試.與代碼庫中舊有的代碼相整合，形成安全穩定運行的代碼庫.既軟體系統。這樣。能夠在最快、最短的時問內形成結果代碼.逐步實現項目目標。這樣的代碼提交形式對軟體項目的目標管理有利.項目經理能夠最快速度地得到項目的最新代碼庫.並且新提交代碼的問題也會及早地暴露出來，在最短的時間內得到解決。持續集成已經被證明對於小到中型規模的項目目標的實現是有價值的，對於大的項目，仍然是有用的。
2、對項目時間管理的作用
生產力的發展過程是不斷採用物化勞動取代人自身的勞動的過程，是不斷自動化的過程。開發的構建過程中如果大量的採取手動過程不僅降低了團隊的生產率.更嚴重的是它將許多不確定的因素引入到產品的構建過程.這使得發現以及解決問題變得異常困難。這樣會更加地降低了團隊的開發效率。持續集成的構建都是使用構建工具自動化地進行的通過使用持續集成工具將構建過程自動化.便於分析並找出問題。大大提高了團隊的開發效率。
穩定而高效的開發效率保證了開發團隊在一個輕松愉快的環境中工作.同時團隊成員可以有更多的時問和精力學習新技術並將其應用在軟體開發中.自動化測試.集成將開發人員從簡單、繁瑣的低級腦力勞動中解放出來，從而進行更高層次的思考持續集成的自動構建過程，極大的提高了軟體的開發效率，對項目經理的項目時間管理有利。
3、對項目質量管理的作用
持續集成過程要求編程人員事先編寫好很多的測試用例.在代碼的提交過程中就對代碼進行測試.這樣的及早測試能夠最快速地發現軟體代碼中的錯誤和缺陷.及時修改，從而提高軟體的質量。
持續集成的測試包括：單元測試、功能測試、集成測試，進行部署等等持續集成要求有一個全面的單元測試驗證集.使持續集成能夠獲得短集成周期。在一般的項目中，編寫測試代碼都至少會額外增加30%的工作量初看.在時間和資金上這也許是很大的開銷，然而，在持續集成過程中，編寫測試代碼是必要的，而且這樣也省去了人工測試的時間.確保了軟體產品的質量.對軟體項目的質量管理有利。
4、對項目風險管理的作用
持續集成過程通常在開發人員提交代碼後開始.伺服器自動更新代碼.編譯，運行單元測試、功能測試、集成測試，進行部署這個持續集成的過程可以幫助開發人員快速發現並解決問題(編譯失敗，測試失敗等)。與開發人員的機器相比，持續集成伺服器運行在相對穩定、干凈的環境中f減小跟蹤調試的難度)，持續集成過程的失敗通常意味著最近一次更新破壞了軟體現有功能或引入了新的缺陷。在持續集成過程結束後.除了構建結果(War，Jar等)，通常會生成代碼分析報告(測試覆蓋率等)，幫助項目管理人員更好的了解並改善項目。
這種快速反饋集成結果.並進行快速修改的工作方式.在第一時間消除了代碼中的Bug.極大地減小了系統發生錯誤、不能在用戶環境中運行、系統集成時涌現大量問題的風險。這樣使整個的項目進度完全掌握在項目經理手中.減少了項目的風險.有利於項目經理的風險管理。
5、對項目人力資源管理的作用
軟體開發過程最終表現為人與人之間各種形式的合作。安全感與信心是合作最基礎也是最重要的部分通過使用持續集成工具.開發人員可以了解到新的代碼是否引人了缺陷。管理人員可以通過使用各種形式的報告對項目進行評估。不斷發布的構建結果.使測試人員得以自始至終的參與到整個開發過程中。而不是在軟體開發的最後階段才加入團隊
持續集成所做的一切加強了團隊成員的溝通.項目中的所有人都知道系統現在的狀態.目前已經做了那些變動。溝通中最重要的一件事是主線的構建狀態。使用持續集成伺服器。這上面有個構建.它會告訴你構建的狀態和上次主線構建的狀態。將構建的結果反饋的形式很多.比如構建成功則綠燈亮.失敗就出現紅燈。還可以使用網站發布構建結果.這樣那些不在一起工作的人也能看到目前項目的狀態這樣的工作方式使團隊成員及時了解項目情況。得到及時、准確的溝通，可以增強團隊成員的安全感和信心，使團隊在一個好的氛圍中工作。這樣利於項目經理管理項目團隊中的成員。
㈢ 如何理解持續集成、持續交付、持續部署
我們經常聽到持續集成，持續交付，持續部署，它們是什麼，聯系和區別是什麼?讓我告訴你我的想法。
是什麼
集成指軟體作為軟體的一部分的部分交付，以盡早發現個體開發部分的問題;
部署是能夠盡早交付到運行的開發/測試部分的代碼，以便盡早進行測試;
交付是指研究和開發盡快交付給客戶，以便盡早發現生產環境中的問題。
我個人認為持續的集成，持續的交付，持續的部署是值得傳播的。在開發過程中，對集成的最大恐懼導致返工，而持續集成、持續交付和持續部署可以及早發現並及早解決，從而避免了這個問題。
㈣ 為什麼要持續集成
在沒有應用持續集成之前，傳統的開發模式是項目一開始就劃分模塊，然後等所有的代碼都開發完成之後再集成到一起進行測試，隨著軟體技術的發展，各種軟體方法百花齊放，軟體規模也在擴大，軟體需求越來越復雜，軟體已經不能簡單地通過劃分模塊的方式來開發，需要項目內部互相合作，劃 分模塊這種傳統的模式的弊端也越來越明顯，由於很多 bug 在項目的早期就存在，到最後集成的時候才發現問題，開發者需要在集成階段花費大量的時間來尋找 bug 的根源，加上軟體的復雜性，問題的根源很難定位，甚至出現不得不調整底層架構的情況，在這個階段的除蟲會議（bug meetings）特別多，會議的內容基本上都是討論 bug 是怎麼產生的，最後往往發展成為不同模塊的負責人互相推諉責任。
持續集成最大的優點是可以避免這種傳統模式在集成階段的除蟲會議。持續集成主張項目的開發人員頻繁的將他們對源碼的修改提交(check in)到一個單一的源碼庫，並驗證這些改變是否對項目帶來了破壞，持續集成包括以下幾大要點：
訪問單一源碼庫，將所有的源代碼保存在單一的地點（源碼控制系統）， 讓所有人都能從這里獲取最新的源代碼（以及以前的版本）。
支持自動化創建腳本，使 創建過程完全自動化，讓任何人都可以只輸入一條命令就完成系統的創建。
測試完全自動化，要求開發人員提供自測試的代碼，讓 任何人都可以只輸入一條命令就運行一套完整的系統測試。
提供主創建，讓任何人都可以只輸入一條命令就可以開始主創建。
提倡開發人員頻繁的提交（check in）修改過的代碼。
持續集成的關鍵是完全的自動化，讀取源代碼、編譯、連接、測試，整個創建過程都應該自動完成。對於一次成功的創建，要求在這個自動化過程中的每一步都不能出錯，而最重要的一步是測試，只有最後通過測試的創建才是成功的創建。
在持續集成裡面創建不再只是傳統的編譯和連接那麼簡單，創建還應該包括自測試，自測試的代碼是開發人員提交源碼的時候同時提交的，是針對源碼的單元測試（源自 XP 的實踐），將所有的這些自測試代碼整合到一起形成測試集，在 所有的最新的源碼通過編譯和連接之後還必須通過這個測試集的測試才算是成功的創建。這 種測試的主要目的是為了驗證創建的正確性，M cConnell 稱之為冒煙測試，在 持續集成裡面，這 叫做集成驗收測試Build Verify Test，簡稱 BVT。BVT 測試是質量的基礎，QA 小組不會感受到 BVT 的存在，他們只針對成功的
創建進行測試（如功能測試）。
BVT 測試應該盡量的詳盡，詳盡的測試才能發現更多的問題，而由此得到的反饋結果也更有參考意義，測試應該全部執行完畢，這樣得到的反饋結果才是完整的，而不是遇到錯誤就放棄測試過程。
持續集成和日創建相比還有以下特點：
持續集成強調了集成頻率，和日創建相比，持續集成顯得更加頻繁，目前推薦的最佳實踐是每一個小時就集成一次。
持續集成強調及時反饋，日創建的目的是得到一個可以使用的穩定的發布版本，而持續集成強調的是集成失敗之後向開發人員提供快速的反饋，當 然成功創建的結果也是得到穩定的版本。
日創建並沒有強調開發人員提交（check in）源碼的頻率，而持續集成鼓勵並支持開發人員盡快的提交對源碼的修改並得到盡快的反饋。
從上面列出的續集成和日創建相比的特點來看，很明顯， 頻率和反饋這兩個詞出現的特別多，持 續集成有一個與直覺相悖的基本要點，那 就是 經常性的集成比偶爾集成要好。Martin Fowler 認為對於持續集成來說，集成越頻繁，效果越好 ，如果你的集成不是經常進行的（少於每天一次），那麼集成就是一件痛苦的事情，如果集成偶爾才進行一次（一周甚至一個月）， 等到集成階段發現bug，然後找原因解決bug，會耗費你大量的時間與精力，而且這種方式有點象傳統的集成模式，這違背了持續集成的初衷。
根據Martin Fowler 的觀點，項目 bug 的增加和時間並不是線性增長的關系，而是和時間的平方成正比，兩次集成間隔的時間越長，bug 增加的數量越超過你的預期，解決 bug 付出的工作量也越大，而你越覺得付出的工作量越大，你就越想推遲到以後去集成，企圖到最後一次性解決問題，結果 bug 產生的就更多，導致下一次集成的工作量更大，你越感覺到集成的痛苦，就越將集成的時間推後，最後形成惡性循環。
因此如果集成的結果是讓你感到痛苦，也許就說明你應該更頻繁地進行集成。頻繁的集成和及時的反饋鞭策著項目小組積極的面對問題，而 不是將問題推到最後來解決，如 果方法正確，更頻繁的集成應該能減少你的痛苦，讓你節約大量時間。
因為持續集成最終是通過測試來驗證創建，所以你會發現對於持續集成的頻率的要求跟Kent Beck 提出的測試驅動的開發方法裡面測試第一的理念完全一致。需要注意的是從項目的一開始就引入持續集成可以盡早的發現 bug，但是並不代表持續集成可以幫你你抓到所有的 bug。持續集成的排錯能力取決於測試技術，眾所周知，無法證明已經經過測試的代碼就已經找到了所有的錯誤。