持續(xù)集成

前言

　　前  言　　在我剛剛參加工作的時候，我看到雜志上有一張整頁的廣告，展示了鍵盤上的一個鍵，類似Enter鍵，上面標著“Integrate（集成）”（參見圖1）。鍵下面的文字是“假如一切如此容易。”我已記不清楚這個廣告是誰為了什么而做的，但它打動了我的心。在軟件開發(fā)方面，我曾想，這當然永遠不會實現(xiàn)，因為在我們的項目里，我們會花幾天的時間在“集成地獄”中掙扎，在接近項目里程碑的時候嘗試將大量軟件組件拼湊起來。但是我喜歡這個想法，所以我剪下了這張廣告，把它貼在我的墻上。對我來說，它代表了我成為一名高效率的軟件開發(fā)者的主要目標之一：將重復的、容易出錯的過程自動化。而且，它包含我的夢想，即將軟件集成變成項目中的“小事一樁”（Martin Fowler曾這樣說）--只是自然發(fā)生的事情。持續(xù)集成（CI）可以幫助您將項目中的集成變成小事一樁?！　D1 集成　　這本書講什么　　請考慮軟件項目中的一些典型的開發(fā)過程：編譯代碼、通過數(shù)據(jù)庫定義數(shù)據(jù)并操作數(shù)據(jù)、進行測試、復查代碼，最后部署軟件。另外，團隊肯定需要就軟件的狀態(tài)進行溝通。請想象一下，如果您可以按一個鍵就完成這些過程?！　∵@本書向您展示了如何創(chuàng)建一個虛擬的集成按鈕，將許多軟件開過過程都自動化。而且，我們介紹了如何持續(xù)地按下這個按鈕，從而減少創(chuàng)建可部署的應用程序時的風險，如較晚才發(fā)現(xiàn)缺陷、低品質的代碼等。在創(chuàng)建CI系統(tǒng)時，許多過程都被自動化，在每次修改開發(fā)的軟件時，都執(zhí)行這些過程?！　∈裁词浅掷m(xù)集成　　集成軟件的過程不是新問題。在一個人開發(fā)的項目中，依賴外部系統(tǒng)又比較少的話，軟件集成不會成為太大的問題，但是隨著項目復雜度的增加（即使只增加一個人），就會對集成和確保軟件組件能夠一起工作提出更多的要求--要早集成，常集成。等到項目快結束時才來集成會導致各種各樣的軟件品質問題，解決這些問題代價很大，常常會導致項目延期。CI以較小增量的方式迅速地解決這些風險?！　≡贛artin Fowler的熱門文章“Continuous Integration”（持續(xù)集成）中，他將CI描述為：　　……一種軟件開發(fā)實踐，即團隊的成員經(jīng)常集成他們的工作，通常每個成員每天至少集成一次--這導致每天發(fā)生多次集成。每次集成都通過自動化的構建（包括測試）來驗證，從而盡快地檢測出集成錯誤。許多團隊發(fā)現(xiàn)，這個過程會大大減少集成問題，讓團隊能夠更快地開發(fā)出一致的軟件。　　根據(jù)我的經(jīng)驗，這意味著：　　所有開發(fā)者都先在他們自己的工作站上執(zhí)行私有構建，然后再將他們的代碼提交到版本控制庫中，從而確保他們的變更不會導致集成構建失敗?！　￠_發(fā)者每天至少向版本控制庫提交一次代碼?！　〖蓸嫿刻煸谝慌_獨立的計算機上進行多次?！　∶看螛嫿ǘ急仨?00%通過測試?！　∩煽梢赃M行功能測試的產(chǎn)品（如WAR、配件、可執(zhí)行程序等）。　　修復失敗的構建是優(yōu)先級最高的事情?！　∧承╅_發(fā)者復查構建生成的報告，如編碼標準報告和依賴分析報告，尋找可以改進的地方?！　”緯懻摿薈I中自動化的方面，因為您會從自動化重復的、容易出錯的過程中得到許多好處。但是，正如Fowler所指出的，CI就是經(jīng)常集成工作的過程，這不一定需要自動化的過程。我們相信，既然已經(jīng)有許多工具讓CI成為自動化的過程，那么使用CI服務器來自動化CI實踐就是一種有效的方式。不管怎樣，也許手工集成的方式（利用自動化的構建）很適合您的團隊。　　快速反饋　　持續(xù)集成增加了您獲得反饋信息的機會。這樣，您每天都能多次了解項目的狀態(tài)。CI可以用來減少引入缺陷和修復缺陷之間的時間間隔，從而改進軟件的總體品質?！　￠_發(fā)團隊不應該相信因為CI系統(tǒng)自動化了，就可以避免集成問題。如果團隊只使用自動化的工具來編譯源代碼，就更是如此。有些人把編譯稱為“構建”，實際上不是的（參見第1章）。有效的CI實踐包含的東西比工具多得多。它包括本書中介紹的實踐，如經(jīng)常向版本控制庫提交代碼，立即修復失敗的構建，以及使用獨立的集成構建計算機等?！　I的實踐支持快速反饋。如果應用了有效的CI實踐，您可以每天多次了解到正在開發(fā)的軟件的健康狀況。而且，CI與重構、測試驅動開發(fā)等實踐配合得挺好，因為這些實踐的中心思想都是進行小的變更。從本質上來說，CI提供了一張安全網(wǎng)，確保變更能夠與軟件的其他部分一起工作。從更高的層面上講，CI增加了團隊整體的信心，減少了項目所需的人工，因為它通常是一個無人值守的過程，在軟件發(fā)生變更時執(zhí)行?！　￡P于“持續(xù)”的注釋　　我們在本書中使用“持續(xù)”這個術語，但是這種用法從技術上來說是不對的。“持續(xù)”意味著某事一旦啟動就不會停止。這意味著集成過程一直在執(zhí)行，但是即使對于最密集的CI環(huán)境來說，也不是這樣的。所以，我們在這本書中講述的更像是“經(jīng)常集成”。　　誰應該讀這本書　　在我的經(jīng)驗中，把軟件開發(fā)當成工作的人和把它當成職業(yè)的人之間有著顯著的差別。本書是為那些把軟件開發(fā)當成職業(yè)，并發(fā)現(xiàn)自己在做一些重復的過程的人（或者我們將幫助您意識到您正頻繁地這樣做）。我們描述CI的實踐和好處，讓您知道如何應用這些實踐，這樣您就可以將時間和專業(yè)知識用在更重要、更有挑戰(zhàn)性的問題上。這本書介紹了與CI相關的主要話題，包括如何利用持續(xù)反饋、測試、部署、審查和數(shù)據(jù)庫集成來實現(xiàn)CI。不論您在軟件開發(fā)中承擔哪種角色，您都可以將CI納入到自己的軟件開發(fā)過程之中。如果您是一位軟件開發(fā)專家，希望變得更有效率（在您擁有的時間里做更多的事情或得到更可靠的結果），您會從本書中學到很多東西?！　￠_發(fā)者　　如果您已注意到自己寧愿為用戶開發(fā)軟件而不是與軟件集成問題搏斗，那么這本書將幫助您消除原來的大部分“痛苦”。這本書不會要求您花更多的時間來集成，它是講如何讓大部分的軟件集成工作變成“小事一樁”，讓您能夠關注最喜歡做的事情：開發(fā)軟件。這本書中的許多實踐和例子向您展示了如何實現(xiàn)一個有效的CI系統(tǒng)?！　嫿?配置/發(fā)布管理　　如果您的工作是讓能工作的軟件發(fā)布出去，您會發(fā)現(xiàn)這本書特別有意思，因為我們在書中展示，通過在每次對版本控制庫進行變更時執(zhí)行一些過程，您可以生成一致的、能工作的軟件?？赡茉S多人在管理構建的同時還承擔項目中的其他角色，如開發(fā)。CI將替您完成一些“思考”，不必等到開發(fā)生命周期的末尾，它每天都能多次生成可測試的軟件?！　y試者　　CI為軟件開發(fā)提供了快速的反饋信息，消除了過去即使進行了“修復”之后，缺陷還會再次出現(xiàn)的痛苦。在實現(xiàn)了CI的項目中，測試者通常會提高滿意度，并提高對他們的角色的興趣，因為送來測試的軟件更為頻繁，每次要測試的范圍也較小。在開發(fā)生命周期中使用CI系統(tǒng)之后，您的測試是一直進行的，而不是像通常那樣有時忙得要死，有時又閑著沒事。以前測試者要么工作到很晚，要么又沒有東西可測試?！　〗?jīng)理　　對于團隊一致地、重復地交付工作軟件的能力，如果您希望有更大的信心，那么這本書將給您帶來巨大的沖擊。您可以更有效地管理時間、費用和品質，因為您決策的基礎是能工作的軟件、真實的反饋信息和測量指標數(shù)據(jù)，而不是項目進度計劃上的任務項。　　本書的組織結構　　本書分為兩個部分。第一部分介紹了CI，從頭開始討論了CI的概念和實踐。第一部分針對的是那些不熟悉CI的核心實踐的讀者。但是，如果沒有第二部分，這些CI的實踐是不完整的。第二部分自然地將核心概念擴展為CI系統(tǒng)執(zhí)行的有效過程，包括測試、審查、部署和反饋等?！　〉谝徊糠? CI的背景知識：原則與實踐　　第1章，啟程，讓您通過一些例子了解如何利用CI服務器來持續(xù)構建軟件?！　〉?章，引入持續(xù)集成，讓您熟悉常見的實踐方法，知道如何開始CI?！　〉?章，利用CI減少風險，通過場景式的例子說明CI可以緩解的主要風險。　　第4章，針對每次變更構建軟件，探討了利用自動化的構建，在每次變更時集成軟件?！　〉诙糠? 創(chuàng)建全功能的CI系統(tǒng)　　第5章，持續(xù)數(shù)據(jù)庫集成，進入一些更高級的概念，涉及構建數(shù)據(jù)庫和應用測試數(shù)據(jù)等過程，作為每次集成構建的一部分工作?！　〉?章，持續(xù)測試，介紹了在每次集成構建時測試軟件的概念和策略?！　〉?章，持續(xù)審查，介紹了利用不同的工具和技術進行自動化的、持續(xù)的審查（靜態(tài)和動態(tài)分析）。　　第8章，持續(xù)部署，探討了利用CI系統(tǒng)部署軟件的過程，以便于進行功能測試?！　〉?章，持續(xù)反饋，向您展示了如何利用持續(xù)反饋設備（如電子郵件、RSS、X10及Ambient Orb），這樣您在構建成功或失敗時就能收到通知?！　?ldquo;尾聲”探討了CI將來的可能性?！　「戒洝　「戒汚，CI資源，包含了與CI有關的URL、工具和文章的列表?！　「戒汢，評估CI工具，評估了市面上不同的CI服務器和相關的工具，討論了它們支持本書中描述的哪些實踐，指出了每種工具的優(yōu)點和不足，解釋了如何利用它們的一些有趣的功能。　　其他特點　　本書還包括了一些其他特點，幫助您更好地理解和應用書中的內容。　　實踐--在這本書中，我們介紹了40多個CI相關的實踐。許多章的副標題就是這些實踐。在多數(shù)章的開始有一張圖，說明了這一章要介紹的實踐，讓您能夠方便地尋找感興趣的內容。例如，“使用專門的集成構建計算機”和“經(jīng)常提交代碼”就是本書中討論的實踐?！　∈纠?-我們通過許多不同語言和平臺上的例子，展示了如何應用這些實踐?！　栴}--每一章都包含了一個問題列表，幫助您評估項目中CI實踐的應用情況?！　eb站點--本書的配套Web站點www.integratebutton.com提供了本書更新、代碼示例和其他材料?！　∧鷮W到什么　　通過閱讀這本書，您將學到一些概念和實踐，它們能幫助您每天多次創(chuàng)建一致的、能工作的軟件。我們首先關注這些實踐，然后是這些實踐的應用，在可能的時候我們都提供了示例來說明。這些示例使用了不同的開發(fā)平臺，如Java、Microsoft.NET，甚至還有Ruby。CruiseControl（Java版和.NET版）是本書中主要使用的CI服務器，但是，我們在配套網(wǎng)站（www.integratebutton.com）和附錄B中提供了使用其他服務器和工具的例子?！　‘斈鷱念^到尾閱讀這本書時，您會有下面的發(fā)現(xiàn)：　　實現(xiàn)CI如何能夠做到在開發(fā)生命周期中的每一步都生成可部署的軟件?！　I如何能夠減少缺陷引入和缺陷被發(fā)現(xiàn)之間的時間間隔，從而降低修復缺陷的成本?！　⊥ㄟ^經(jīng)常構建軟件，而不是等到開發(fā)的后期再構建軟件，如何能夠提高軟件的品質。　　本書沒有介紹什么　　本書沒有介紹構成CI系統(tǒng)的全部的工具--構建進度計劃、編程環(huán)境、版本控制等。它關注的是實現(xiàn)CI實踐，從而得到一個有效的CI系統(tǒng)。首先討論的是CI實踐，如果書中提到的某個工具不再使用，或者不能滿足您的特別需要，只要使用另一個工具來應用這些實踐就行了，目的是達到同樣的效果?！　”緯膊豢赡芙榻BCI所使用的每一種類型測試、反饋機制、自動化審查工具和部署的類型。即使這樣做，用處也不大。通過關注關鍵實踐，利用技術和工具的示例來講解數(shù)據(jù)庫集成、測試、審查和反饋。項目和團隊可以根據(jù)自己的理解進行不同的應用。我們希望這樣可以實現(xiàn)更宏大的目標。正如這本書中處處提到的，這本書的配套Web站點www.integratebutton.com包含使用其他工具和語言的例子，這些例子在本書中可能沒有提及?！　￡P于作者　　本書有三位作者和一位貢獻者。我編寫了大部分章節(jié)。Steve Matyas參與了第4、5、7、8章和附錄A的編寫，并提供了本書中的一些例子。Andy Glover編寫了第6、7、8章，提供了例子，并參與了本書其他部分的編寫。Eric Tavela編寫了附錄B。這樣在讀到使用第一人稱的句子時，您可以知道是誰在發(fā)表觀點。　　關于封面　　當我得知我們的書將作為著名的Martin Fowler簽名系列中的一本時，我非常興奮。我知道這意味著我可以挑選一座橋作為這本書的封面。其他幾位作者和我都是在華盛頓特區(qū)長大的。如果你不是來自這個地區(qū)的，可能不知道這個地區(qū)是變化很快的。更準確地說，我們來自北弗吉尼亞，所以覺得選擇弗吉尼亞的“天然橋”作為封面是很不錯的。我直到2007年初才去了那里--在我將它選為封面之后。它有一段有趣的歷史，我覺得難以置信，它竟然能每天讓汽車從上面開過（當然，我也開車從上面走過幾次）。我希望在閱讀了這本書之后，您會將CI作為下一個軟件開發(fā)項目中的自然組成部分?！　≈轮x　　我說不清楚有多少次在讀書時看到作者說“單靠自己是無法完成的”和其他一些事情。我總是對自己說：“他們只是在假謙虛。”可是，我確實錯了。這本書是一個浩大的工程，我要感謝這里列出的人?！　∥乙兄x我的出版商，Addison-Wesley。我特別要感謝我的責任編輯Chris Guzikowski，他和我一起度過了這個耗費心血的過程。他的經(jīng)驗、觀點和鼓勵對我?guī)椭浅４?。而且，我的項目編輯Chris Zahn，在幾個版本和幾輪編輯中提供了中肯的建議。我還要感謝Karen Gettman、Michelle Housley、Jessica D'Amico、Julie Nahil、Rebecca Greenberg，以及我的第一位責任編輯Mary O'Brien和其他人。　　Rich Mills為本書提供了CVS服務器，并在“頭腦風暴”會議上提出了絕妙的想法。我也要感謝我的指導者和朋友Rob Daly，2002年讓我開始職業(yè)寫作，并在我寫作的過程中進行了詳細的復查。John Steven對促成本書的編寫也起了幫助作用。　　我想感謝我的合作者、編輯和貢獻者。Steve Matyas和我度過了許多不眠之夜，創(chuàng)作您讀到的這本書。Andy Glover是我們抓過來的作者，他提供了大量有關項目的開發(fā)者測試的經(jīng)驗。Lisa Porter是我們的特約編輯，她不知疲倦地檢查每一個版本，進行編輯并提供建議，提高了這本書的品質。我要感謝Eric Tavela，他寫了CI工具的附錄，感謝Levent Gurses在附錄B中提供了Maven 2的經(jīng)驗?！　∥覀冇幸粋€平衡的技術復查者核心團隊，他們在本書的編寫過程中提供了很好的反饋意見。他們是Tom Copeland、Rob Daly、Sally Duvall、Casper Hornstrup、Joe Hunt、Erin Jackson、Joe Konior、Rich Mills、Leslie Power、David Sisk、Carl Tallis、Eric Tavela、Dan Taylor和Sajit Vasudevan?！　∥疫€要感謝Charles Murray和Cristalle Belonia的幫助，以及來自Urbancode公司的Maciej Zawadzki和Eric Minick的幫助?！　∥乙兄x幾個很好的人，我在Stelligent公司工作的每一天里，他們對我提供了支持和幫助。他們是Burke Cox、Mandy Owens、David Wood和Ron Wright。還有許多人這些年在我的工作中給了我啟發(fā)，他們是Rich Campbell、David Fado、Mike Fraser、Brent Gendleman、Jon Hughes、Jeff Hwang、Sherry Hwang、Sandi Kyle、Brian Lyons、Susan Mason、Brian Messer、Sandy Miller、John Newman、Marcus Owen、Chris Painter、Paulette Rogers、Mark、Simonik、Joe Stusnick和Mike Trail?！　∥乙哺兄xAddison-Wesley的技術復查團隊提供的反饋信息，包括Scott Ambler、Brad Appleton、Jon Eaves、Martin Fowler、Paul Holser、Paul Julius、Kirk Knoernschild、Mike Melia、Julian Simpson、Andy Trigg、Bas Vodde、Michael Ward和Jason Yip。　　我想感謝參加了CITCON芝加哥2006年會議的人，他們和我們分享了在CI和測試方面的經(jīng)驗。我特別要感謝Paul Julus和Jeffrey Frederick組織了這次會議，以及其他所有參加了這次會議的人?！　∽詈螅乙兄xJenn在本書編寫的日子里始終提供了堅定的支持。　　Paul M. Duvall　　于弗吉尼亞州費爾費克斯縣

內容概要

　　Jolt大獎素有“軟件業(yè)之奧斯卡”的美稱，本叢書精選自Jolt歷屆獲獎圖書，以植根于開發(fā)實踐中的獨到工程思想與杰出方法論為主要甄選方向。本書全面深入地討論持續(xù)集成的各個方面，介紹了一種增加項目可見性、降低項目失敗風險的有效實踐。此外，還介紹了測試驅動、代碼審查、數(shù)據(jù)庫集成、信息反饋等實踐和工具。全書列舉了持續(xù)集成系統(tǒng)的優(yōu)缺點，如何去使用持續(xù)集成系統(tǒng)，什么時候使用等，可操作性極強。
　　本書榮獲2008年Jolt世界圖書大獎，適合軟件開發(fā)人員及團隊閱讀，還可作為軟件工程方面的教材。

作者簡介

　　Paul M.
Duvall是Stelligent公司的CTO。Stelligent公司是一家咨詢公司，他們通過優(yōu)化軟件開發(fā)過程，幫助開發(fā)團隊可靠地、快速地開發(fā)出更好的軟件。他幾乎擔任過軟件開發(fā)項目中的所有職務，從開發(fā)者到測試者再到架構師和項目經(jīng)理。Paul向各個行業(yè)的客戶提供咨詢，包括金融業(yè)、房地產(chǎn)業(yè)、政府、醫(yī)療衛(wèi)生業(yè)，以及大型的獨立軟件提供商。他是許多知名軟件會議的特邀講演者。他為IBM
developerWorks撰寫了一系列的文章，名為“Automation for the People”，他是NFJS 2007
Anthology（Pragmatic Programmers，2007）的合著者，也是UML 2
Toolkit（Wiley，2003）的貢獻作者。他是臨床研究數(shù)據(jù)管理系統(tǒng)和方法的發(fā)明者之一，這個系統(tǒng)和方法正在申請專利。他經(jīng)常在www.testearly.com和www.integratebutton.com上寫日志。
　　Stephen M. Matyas III是AutomateIT的副總裁。AutomateIT是5AM
Solutions公司的一個服務機構，它幫助組織機構通過自動化來改進軟件開發(fā)。Steve在應用軟件工程方面有多重背景，他的客戶包括商業(yè)客戶和政府客戶。Steve擔任過許多種不同的角色，從業(yè)務分析師和項目經(jīng)理到開發(fā)者、設計者和架構師。他是UML
2 Toolkit（Wiley，2003）的貢獻作者。他實踐了許多迭代增量式的方法，包括敏捷方法和Rational Unified
Process（RUP）。他的大部分第一手的職業(yè)經(jīng)驗來自于Java/J2EE定制軟件開發(fā)和服務，在方法學、軟件品質和過程改進方面具有特珠的要求。他擁有弗吉尼亞理工大學的計算機科學學士學位。
　　Andrew
Glover是Stelligent公司的總裁。Stelligent公司是一家咨詢公司，他們通過優(yōu)化軟件開發(fā)過程，幫助開發(fā)團隊可靠地、快速地開發(fā)出更好的軟件。Andy經(jīng)常在北美的各種會議上作為講演嘉賓，他也是No
Fluff Just Stuff Software Symposium小組的講演者。他還是Groovy in
Action（Manning，2007），Java Testing Patterns（Wiley，2004）及NFJS 2006
Anthology（Pragmatic
Programmers，2006）的合著者之一。他也是一些在線文章的作者，這些文章發(fā)布在IBM的developerWorks，O’Reilly的ONJava、ONLamp和Dev2Dev門戶站點上。他經(jīng)常在上寫有關軟件品質的日志。
　　貢獻者簡介
　　Lisa
Porter是一個顧問團隊的高級技術作者，這個團隊向美國政府提供網(wǎng)絡安全的解決方案。Lisa在本書出版之前提供了技術編輯服務。她早些年曾支持一個包含多個應用程序的大型軟件開發(fā)項目，在需求確定和項目成熟度/能力等活動方面受到了好評。她也進行外語翻譯和架構/工程方面的技術寫作。Lisa從2002年開始就從事編輯書籍和在線出版物的工作。
　　Eric Tavela是5AM Solutions公司的首席架構師。5AM
Solutions公司是一個軟件開發(fā)公司，該公司致力于將軟件工程的最佳實踐應用于生命科學的研究工作。Eric的主要工作背景是實現(xiàn)Java/J2EE應用程序及指導面向對象軟件開發(fā)和UML建模。

書籍目錄

出版說明
譯者序
Martin Fowler序
Paul Julius序
前言
作者簡介
貢獻者簡介
第1部分 CI的背景知識：原則與實踐
第1章 啟程
1.1 針對每次變更構建軟件
開發(fā)人員
版本控制庫
CI服務器
構建腳本
反饋機制
集成構建計算機
1.2 CI的特征
源代碼編譯
數(shù)據(jù)庫集成
測試
審查
部署
文檔與反饋
1.3 本章小結
1.4 問題
第2章 引入持續(xù)集成
2.1 CI生活中的一天
2.2 CI的價值是什么
減少風險
減少重復過程
生成可部署的軟件
增強項目的可見性
建立起更強大的產(chǎn)品信心
2.3 什么阻礙了團隊使用CI
2.4 如何進行“持續(xù)”集成
2.5 項目應該在何時以何種方式實現(xiàn)CI
2.6 集成的演進
2.7 CI如何與其他開發(fā)實踐配合
2.8 CI需要多少時間架設
2.9 CI與您
2.10 經(jīng)常提交代碼
2.11 不要提交無法構建的代碼
2.12 立即修復無法集成的構建
2.13 編寫自動化的開發(fā)者測試
2.14 必須通過所有測試和審查
2.15 執(zhí)行私有構建
2.16 避免簽出無法構建的代碼
2.17 本章小結
2.18 問題
第3章 利用CI減少風險
3.1 風險：沒有可部署的軟件
場景：“在我的機器上是行的”
解決方案
場景：與數(shù)據(jù)庫同步
解決方案
場景：點錯了
解決方案
3.2 風險：很晚才發(fā)現(xiàn)缺陷
場景：回歸測試
解決方案
場景：測試覆蓋
解決方案
3.3 風險：缺少項目可見性
場景：“您收到了備忘錄嗎？”
解決方案
場景：不能使軟件可見
解決方案
3.4 風險：低品質的軟件
場景：堅持編碼標準
解決方案
場景：維持架構
解決方案
場景：重復的代碼
解決方案
3.5 本章小結
3.6 問題
第4章 針對每次變更構建軟件
4.1 自動化構建
4.2 執(zhí)行單命令構建
4.3 將構建腳本從IDE中分離
4.4 集中放置軟件資產(chǎn)
4.5 創(chuàng)建一致的目錄結構
4.6 讓構建快速失敗
4.7 針對所有環(huán)境構建
4.8 構建類型和觸發(fā)機制
構建類型
私有構建
集成構建
發(fā)布構建
構建觸發(fā)機制
觸發(fā)構建
4.9 使用專門的集成構建計算機
4.10 使用CI服務器
4.11 執(zhí)行手工集成構建
4.12 執(zhí)行快速構建
收集構建測量數(shù)據(jù)
分析構建測量數(shù)據(jù)
選擇并實現(xiàn)改進
使用專門的集成構建計算機
增強集成構建計算機的硬件能力
改進測試性能
4.13 分階段構建
檢查基礎設施
優(yōu)化構建過程
單獨構建系統(tǒng)組件
改進軟件審查的性能
執(zhí)行分布式集成構建
重新評估
4.14 這對您如何生效
4.15 本章小結
4.16 問題
第2部分 創(chuàng)建全功能的CI系統(tǒng)
第5章 持續(xù)數(shù)據(jù)庫集成
5.1 自動化數(shù)據(jù)庫集成
創(chuàng)建數(shù)據(jù)庫
操作數(shù)據(jù)庫
創(chuàng)建一段構建數(shù)據(jù)庫的結合腳本
5.2 使用本地數(shù)據(jù)庫沙盒
5.3 利用版本控制庫共享數(shù)據(jù)庫資產(chǎn)
5.4 持續(xù)數(shù)據(jù)庫集成
5.5 讓開發(fā)者能夠修改數(shù)據(jù)庫
5.6 開發(fā)團隊共同關注修復失敗構建
5.7 讓DBA成為開發(fā)團隊的一員
5.8 數(shù)據(jù)庫集成和集成按鈕
測試
審查
部署
反饋與文檔
5.9 本章小結
5.10 問題
第6章 持續(xù)測試
6.1 自動化單元測試
6.2 自動化組件測試
6.3 自動化系統(tǒng)測試
6.4 自動化功能測試
6.5 對開發(fā)者測試分類
6.6 先執(zhí)行較快的測試
6.7 為缺陷編寫測試
6.8 讓組件測試可重復
6.9 將測試用例限制為一個斷言
6.10 本章小結
6.11 問題
第7章 持續(xù)審查
7.1 審查與測試的區(qū)別
7.2 應該以怎樣的頻度執(zhí)行審查
7.3 代碼測量指標：歷史
7.4 降低代碼復雜度
7.5 持續(xù)進行設計復查
7.6 通過代碼審查維持組織機構的標準
7.7 減少重復的代碼
使用PMD-CPD
7.8 判斷代碼覆蓋率
7.9 持續(xù)評估代碼品質
覆蓋率檢查頻度
覆蓋率與性能
7.10 本章小結
7.11 問題
第8章 持續(xù)部署
8.1 隨時隨地發(fā)布可工作的軟件
8.2 為庫中的資產(chǎn)打上標簽
8.3 得到干凈的環(huán)境
8.4 為每一個構建版打上標簽
8.5 執(zhí)行所有的測試
8.6 創(chuàng)建構建反饋報告
8.7 回滾構建的過程能力
8.8 本章小結
8.9 問題
第9章 持續(xù)反饋
9.1 所有正確的東西
正確的信息
正確的人
正確的時間
正確的方式
9.2 使用持續(xù)反饋機制
電子郵件
SMS（文本消息）
Ambient Orb和X10設備
Windows任務條
聲音
寬屏顯示器
9.3 本章小結
9.4 問題
后記：CI的未來
附錄A CI資源
附錄B 評估CI工具
參考文獻

章節(jié)摘錄

版權頁：   插圖：   CI的實踐與其他軟件開發(fā)實踐是互補的，如開發(fā)者測試、堅持編碼標準、重構和小發(fā)行版本。不論您是在使用RUP、XP、RUP結合XP、SCRUM、Crystal或其他任何一種方法學，都可以采用CI的實踐。下面的列表總結了CI的實踐是怎樣促進其他實踐的。 ■開發(fā)者測試：開發(fā)者編寫測試時通常使用某種xUnit框架，如JUnit或NUnit。這些測試可以通過構建腳本自動執(zhí)行。由于CI的實踐鼓勵每次對軟件進行改動時就執(zhí)行構建，而自動化測試又是構建的一部分，所以CI就使得每次對軟件進行修改時，都會對全部代碼執(zhí)行自動化的回歸測試。 ■堅持編碼標準：編碼標準是開發(fā)者在開發(fā)項目時必須遵守的一組規(guī)范。在許多項目中，確保遵守編碼規(guī)范基本上是一個手工過程，通過代碼復查來執(zhí)行。CI可以在每次發(fā)生變更時執(zhí)行一段構建腳本，通過運行一些自動化的靜態(tài)分析工具，根據(jù)已建立的編碼標準審查源代碼，報告標準的遵守情況。 ■重構：根據(jù)Fowler所說的，重構是"這樣一個過程，它在不改變代碼的外部行為的情況下，對軟件系統(tǒng)進行修改，改進它的內部結構。"這使代碼更容易維護，并帶來其他好處。CI可以通過在每次構建時運行審查工具，確定可能的問題，從而實現(xiàn)對重構的支持。 ■小發(fā)行版本：這項實踐讓測試人員和用戶能夠按他們的需要的頻度，得到可以工作的軟件，因為軟件集成每天都會進行許多次，基本上任何時候都可以得到一個發(fā)行版本。當CI系統(tǒng)就位后，得到一個發(fā)行版本是不用花多少力氣的。 ■共同擁有代碼：每個開發(fā)者都可以修改軟件系統(tǒng)的每一個部分。這避免了"知識孤島"，即對于系統(tǒng)的特定部分，只有一個人了解相關的知識。CI實踐通過確保遵守編碼標準，持續(xù)執(zhí)行回歸測試，對共同擁有代碼提供了支持。

編輯推薦

《持續(xù)集成:軟件質量改進和風險降低之道》首先從最基礎的東西開始，討論了CI的概念和實踐，然后進一步討論了CI系統(tǒng)執(zhí)行的其他有效的過程，如數(shù)據(jù)庫集成、測試、審查、部署和反饋。通過超過40個CI相關的實踐和不同語言環(huán)境下的應用示例，讀者可以明白CI將導致更快速的軟件開發(fā)，在開發(fā)生命周期中的每一步都能得到可部署的軟件，而且減少了缺陷引入和發(fā)現(xiàn)之間的時間，節(jié)約了開發(fā)時間，降低了開發(fā)成本。通過成功地實現(xiàn)CI，開發(fā)者可以減少風險和重復的手工操作過程，開發(fā)團隊可以更好地了解項目的狀態(tài)。

圖書封面

圖書標簽Tags

無

評論、評分、閱讀與下載

---

    持續(xù)集成 PDF格式下載

---