|
|
喬梁，十多年軟件開發(fā)及項目管理經(jīng)驗，專注于提高軟件企業(yè)提高交付能力，推廣最佳實踐。曾為多個大型電信企業(yè)、互聯(lián)網(wǎng)企業(yè)提供專業(yè)的軟件交付咨詢服務(wù)?，F(xiàn)任百度項目管理部高級架構(gòu)師，負責(zé)百度敏捷過程改進與持續(xù)交付推廣實施。譯有《持續(xù)交付》。曾任Thoughtworks資深咨詢師，對敏捷項目管理及持續(xù)集成有深入的理解與豐富的實踐經(jīng)驗。
下面是整理出來的喬梁分享的“持續(xù)集成”系列文章：
每當(dāng)開發(fā)人員提交代碼時，就是其與其他開發(fā)人員工作成果的一次集成。如果每個人都能夠頻繁提交代碼，那么代碼集成的頻率就會提高，在持續(xù)集成的有力支持下，代碼中潛在的問題就會更早地暴露出來，以便團隊盡早解決之。當(dāng)然，持續(xù)集成所鼓勵的頻繁提交并不是指那種僅將版本控制庫當(dāng)成備份工具，無約束的“隨意”提交，還需要團隊開發(fā)流程約束的。下面我們來一同探討“持續(xù)集成環(huán)境中的團隊開發(fā)流程是什么樣的”。（閱讀全文）
持續(xù)集成之“測試三角形與分段構(gòu)建策略原則”
隨著軟件產(chǎn)品新特性的不斷增加，軟件自動化測試用例的數(shù)量也會成倍增長。對于一些歷史“悠久”的遺留系統(tǒng)來說，甚至?xí)e累數(shù)以萬計的自動化測試用例。如果對這樣的系統(tǒng)進行持續(xù)集成，還要求每個開發(fā)人員都要進行本地驗證的話，困難的確不小。讓我們還是看看Joe的團隊是如何解決類似問題的吧。（閱讀全文）
現(xiàn)代版本控制系統(tǒng)(SCM)的作用已不僅僅是保存歷史版本，它還是各軟件開發(fā)組織利用其分支功能實現(xiàn)多人并行開發(fā)，提高生產(chǎn)效率的一種工具。對于稍有歷史的軟件產(chǎn)品來說，一般都會有代碼分支的出現(xiàn)，也常常見到一些歷史悠久的產(chǎn)品其錯綜復(fù)雜的分支版本樹甚至將產(chǎn)品交付團隊拖入“無盡維護”的泥潭。分支的目的是希望“分而治之”，而持續(xù)集成的目的是“頻繁集成”，這二者之間又有哪些聯(lián)系呢？（閱讀全文）
現(xiàn)在，Joe的團隊中，開發(fā)人員快速增加，已接近30人了。由于首次發(fā)布后的市場壓力，大家一直在趕進度，持續(xù)集成的失敗頻率越來越高，修復(fù)構(gòu)建的時間也越來越長，排隊等待提交的代碼也越積越多。“這種狀況不能再持續(xù)下去了，需要想個辦法解決它。”（閱讀全文）
在前文《分支策略(續(xù))》中，我們討論了多組件應(yīng)用程序的持續(xù)集成策略，即：為相對獨立的組件創(chuàng)建自己專屬的代碼庫，然后通過現(xiàn)代持續(xù)集成工具進行組件間的持續(xù)集成。Joe的團隊在首次發(fā)布之后，開始使用這種方式。然而，沒有多久，他們就遇到了一個問題：一次提交構(gòu)建所花費的時間太長。（閱讀全文）
將部署操作腳本化，并進行部署驗證測試；各類環(huán)境盡可能相似，并使部署腳本通用化；對環(huán)境管理進行版本控制，杜絕對生產(chǎn)環(huán)境的手工直接修改。（閱讀全文）
你是否遇到過這樣的情形，即使手里拿著一個jar文件或dll文件，也無法知道它到底是哪個版本。也許你可能認為，這算不了什么，到某個管理平臺上查一查部署記錄就行了。可是，如果發(fā)現(xiàn)在生產(chǎn)環(huán)境的集群服務(wù)器上，不同機器上部署的同一個程序文件（比如.war文件）的大小卻不相同，哪一個的大小是正確的呢？（集閱讀全文）
隨著互聯(lián)網(wǎng)的飛速發(fā)展，以及基礎(chǔ)設(shè)施的改進，越來越多的業(yè)務(wù)被放在了“云”端。管理數(shù)千臺服務(wù)器和各種應(yīng)用程序的不同版本已經(jīng)是一種常規(guī)事務(wù)了。那么如果管理好這些機器和代碼嗎？本文將介紹一些最佳實踐，來幫助大家更好的完成相關(guān)的事務(wù)。（閱讀全文）
it知識庫：系列文章整理 - “聽”喬梁講述持續(xù)集成的故事，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
