如何快速捕獲.NET代碼中隱藏的BUG

　　團隊開發的一個方面就是在將所有的改動合并到中心資料庫之前，允許單獨的開發人員在本地編寫並構建(build)有特色的代碼。開發人員可以在本地測試與調試最新的版本，並且可以保證他們所有的工作代碼可以與其他同事的協同工作，他們可以手動測試這些代碼，但是更好的辦法就是將這一過程自動化並且提供即時反饋，其中一個非常優秀的解決方案就是持續整合。

　　持續整合

　　對於應用軟體Team Dev而言，有很多提高產品品質和效率的思想，其中的一種思想就是被稱作持續整合的方法，持續整合的一個前提就是即時反饋。持續整合的一種最簡單的形式就是由一個開發人員完成所有的工作，因為所有的改變都是立即可見的，因此，單個開發人員在他們出現問題的時候就能知道這個問題的存在，當同樣的方法應用到團隊環境中，即時方式就會成為一個問題。

　　持續整合最大的特色在於當開發人員提交他們工作的時候 ,可以減少其他開發人員用於檢測bug的時間，而往往非常難以追蹤到由這些bug所導致的問題的根源，因為問題通常是由於整合了新的代碼所致，因整合而出現的bug可能在出現問題之前已經被嵌入到代碼中很久了，與其花費時間去追蹤這些bug還不如花在別的項目上，關鍵是要儘早地發現問題。

　　在持續整合方法的協助下，絕大部分bug可以在引入代碼的時候被發現，因為這些“嫌疑犯”(開發人員的代碼)是在他們提交新代碼之後才出現了錯誤，所以更加明顯。因此，少花些時間在追蹤這些錯誤上，開發人員就能有更多的時間解決他們自己的問題，最終的結果是生產效率的提高，但這種方法也依賴於構建新版本的頻率，從而向開發人員提供有價值的反饋。

　　何時進行構建(build)?

　　我還記得多年前曾工作過的項目，進行一次構建需要大量的時間和精力，要提醒開發人員遞交他們的代碼，而且手動的構建過程非常緊張，很自然的，當對Team Dev的代碼進行構建的時候，錯誤就搖頭擺尾地出現了，追蹤這些問題是需要時間的，並且希望能沿著正確的方向去解決問題，這樣才能獲得成功，而這一過程所需的時間往往導致了構建次數的減少，但是，多次構建更易於從持續整合中受益。

　　如果您想知道一個成功構建的條件是什麼，答案視乎您的項目和環境而決定，但是我經常將它定義為所有的源檔案都成功編譯、部署並且一系列測試都在系統中獲得成功，您需要一系列工具來實現這些工作，雖然自動化的測試(automated testing)並不是必需的，但是我強烈推薦這種方法。

　　工具

　　以下是在.NET環境中建立與運行持續整合方法所必需的幾本工具列表：

　　·原始碼控制：這允許多個程式員通過提交、調出和添加新檔案對應用軟體代碼的協同工作，Visual SourceSafe是一種流行的選擇，但還有很多更好的選擇，比如Subversion，IBM's Rational ClearCase，CVS和SourceGear Vault。

　　·編譯器：您可以使用.NET架構的命令列編譯器、Visual Studio .NET或其他的整合式開發環境。

　　·持續整合伺服器：這是構建過程的主要控制器，它負責監控為程式員提交代碼使用的原始碼資產庫，當加入新的代碼時，最新的版本將被取回，構建過程也就取消了，持續整合過程的最後一步是通過電子郵件、網頁等形式向整個團隊通報構建的狀態。有很多工具都可以實現這一步驟，我比較喜歡CruiseControl.NET，另一個選擇是免費的Draco.NET，您需要一個專門的伺服器來實現這一步驟。

　　·自動構建工具：用於原始碼的自動構建的工具是必不可少的，免費的NAnt是一個很棒的選擇，或者您可以使用一個程式產生工具，如果您使用的是CruiseControl.NET的最新版本，則可以和Visual SourceSafe直接對話，這樣就不需要像NAnt這樣的自動構建工具了。

　　·選擇性單元測試：在整合階段應用單元測試可以協助驗證正常工作的代碼，一個非常出色的工具是NUnit，它是免費的而且在網上有大量的相關資訊。

　　注意：安裝與設定這些工具的內容已經超出了這篇文章的範圍，但是每個產品的網路社區所提供的文檔中包含了您使用這些產品所需的資訊。

　　您準備好使用持續整合了麼?

　　持續整合並不是針對缺陷代碼的靈丹妙藥，但它絕對可以釋放出您寶貴的時間去應付更緊張的問題，開發人員依然需要編寫強壯的代碼並進行良好的單元測試，另外，代碼應該按照規則進行提交(我建議每日提交)，然而，使用持續整合可以協助您驗證代碼、測試、設計等的品質，持續整合能協助您節省出原本用於構建的時間，但您需要一些時間去設定和管理專門用於持續整合的伺服器。