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