全面分析持續集成優缺點(4)

我們發現很多開發者都經常看看這個頁面，因爲它讓他們看到項目發展的方向，看到隨着人們不斷歸還代碼而發生的變化。有時我們也會在這個頁面上放一些其他的項目新聞，但是需要把握好尺度。

　　要讓開發者能在自己的本地機器上模擬主創建過程，這是很重要的。這樣，如果集成錯誤出現了，開發者可以在自己的機器上研究、調試，而不必真的執行主創建過程。而且，開發者也可以在歸還代碼之前先在本地執行創建，從而降低了主創建失敗的可能性。

　　這裏有一個比較重要的問題：主創建應該是乾淨的創建（完全從源代碼開始）還是增量創建？增量創建會快得多，但是也增大了引入錯誤的風險，因爲有些部分是沒有編譯的。而且我們還有無法重新創建的風險。我們的創建速度相當快（20萬行代碼約15分鐘），所以我們樂於每次都做乾淨的創建。但是，有些團隊喜歡在大多數時候做增量創建，但是當那些奇怪的問題突然出現時，也經常性地做乾淨的創建（至少每天一次）。





圖1：運行在投石車上的servlet

代碼歸還（Check in）

　　使用自動化創建就意味着開發者應該遵循某種節奏來開發軟件，最重要的就是他們應該經常集成。我們曾經見過一些組織，他們也做日創建，但是其中的開發者卻不經常歸還代碼。如果開發者幾周才歸還一次代碼，那麼日創建又有什麼意義呢？我們遵循的原則是：每個開發者至少每天要歸還一次代碼。

　　在開始新的任務之前，開發者應該首先與配置管理系統同步。也就是說，他們應該首先更新本地機器上的源代碼。在舊的代碼基礎上編寫代碼，這隻會帶來麻煩和混亂。

　　然後，開發者要隨時保持文件的更新。開發者可以在一段任務完成之後將代碼集成到整個系統中，也可以在任務的中途集成，但是在集成的時候必須保證所有的測試都能通過。 [Page]

　　集成的第一步是要再次使開發者的本地文件與代碼倉庫同步。代碼倉庫中所有新近有改動的文件都要拷貝到開發者的工作目錄中來，當文件發生衝突時，配置管理系統會向開發者提出警告。然後，開發者需要對同步後的工作集進行創建，對這些文件運行BVT，並得到正確的結果。

　　現在，開發者可以把新的文件提交到代碼倉庫中。提交完成之後，開發者就需要等待主創建。如果主創建成功，那麼這次歸還也是成功的。如果主創建失敗了，開發者可以在本地修改。如果修改很簡單，就可以直接提交；如果修改比較複雜，開發者就需要放棄這次修改，重新同步自己的工作目錄，然後繼續在本地開發、調試，然後再次提交。

　　某些系統強制要求歸還進程逐個進行。在這種情況下，系統中會有一個創建令牌，同一時間只有一個開發者能拿到令牌。開發者獲取創建令牌，再次同步文件，提交修改，然後釋放令牌。這就確保創建過程中，最多只能有一個開發者在更新代碼倉庫。不過我們發現，即使沒有創建令牌，我們也很少遇到麻煩，所以我們也不用這種方法。經常會有多個人同時向同一個主創建提交代碼的情況，但是這很少造成創建失敗，而且這樣的錯誤也很容易修復。

　　同時，我們還讓開發者自己來決定歸還過程中的小心程度。這反映出開發者對集成錯誤出現機率的評估。如果她覺得很有可能出現集成錯誤，那麼她就會在歸還之前先做一次本地創建；如果她覺得根本不可能出現集成錯誤，那麼她可以直接歸還。如果犯了錯誤，在主創建運行時她立刻就會發現，然後她就必須放棄自己的修改，找到出錯的地方。如果錯誤很容易發現、很容易修補，那麼這種錯誤也是可以接受的。

總結

　　發展一個制度嚴密的自動化創建過程對於項目的控制是很重要的。許多軟件先賢都這樣說，但是我們發現，這樣的過程在軟件開發領域中仍然罕見。

　　關鍵是要讓所有的事情都完全自動化，並且要經常進行集成，這樣才能儘快發現錯誤。然後，人們可以隨時修改需要修改的東西，因爲他們知道：如果他們做的修改引起了集成錯誤，那也是很容易發現和修補的。一旦獲得了這些利益，你會發現自己再也無法放下它們。