設置集成測試服務器的最佳方式是什麼？

Question

建立一個集成服務器，我對使用多個任務來完成構建的最佳方法表示懷疑。將所有工作都放在一個大工作或者從事小工作的最佳方式是？

Answer 1

你一定要分手任務。這是CruiseControl.NET配置的一個很好的例子，每個步驟都有不同的目標（任務）。它還使用了一個common.build文件，可以在少量定製的項目之間共享。

http://code.google.com/p/dot-net-reference-app/source/browse/#svn/trunk

Answer 2

我使用TeamCity和nant構建腳本。 TeamCity可以很容易地設置CI服務器部分，而且nant構建腳本使得就報告生成而言，可以輕鬆完成許多任務。

這裏是一個文章，我寫了關於使用CI與CruiseControl.NET，它在評論南特構建腳本跨項目，可重複使用：

Continuous Integration with CruiseControl

Answer 3

我肯定會打破工作。很可能你會在構建中進行更改，如果你有更小的任務，而不是通過單一構建進行搜索，那麼跟蹤問題會更容易。

無論如何，您應該可以從小塊創建一個大工作。

Answer 4

天兒真好，

當你在談論集成測試我的大（明顯）的小費是使測試服務器構建和配置，儘可能接近到部署環境可能。

</thebloodyobvious> (-: 

歡呼聲， 羅布

Answer 5

的做法我贊成如下設置（實際上假設你是一個.NET項目）：

• CruiseControl.NET。
• 每個單獨步驟的NANT任務。 Nant.Contrib替代CC模板。
• NUnit運行單元測試。
• NCover執行代碼覆蓋。
• FXCop用於靜態分析報告。
• Subversion for source control。
• CCTray或類似的所有dev的箱子得到的通知建立和失敗等

在你發現有不同程度的測試和活動需要，當有人不簽入的地方很多項目。有時候，這些可能會增加到一定程度，以至於在開發之前可能需要很長時間才能看到他們是否用簽入破壞了構建。

我在這些情況下，做的是創建三個建立（或者兩個）：

• 一個CI構建被簽入觸發和不乾淨的SVN獲取，構建和運行輕量級測試。理想情況下，您可以將其降低到幾分鐘或更少。
• 一個更全面的構建，可以每小時（如果更改）與CI完全相同，但運行更全面和更耗時的測試。
• 過夜的構建，其做的一切，並運行的代碼覆蓋率和組件的靜態分析和運行任何部署步驟來建立日常MSI軟件包等

任何CI系統中最關鍵的是，它需要有機並不斷調整。 CruiseControl.NET有一些非常好的擴展功能，可以爲步驟記錄日誌和圖表構建時間等，並讓您進行歷史分析，並讓您不斷調整構建以保持活躍。這是管理人員很難接受的一種情況，即構建箱可能會讓你忙於工作時間的五分之一，以阻止它停滯不前。

Answer 6

我們使用buildbot，構建分解爲不連續的步驟。在將構建步驟細分爲足夠的粒度和完整的單元之間有一個平衡點。例如，在我現在的位置，我們在各自的平臺上爲我們的每個平臺（Mac，Linux，Windows）構建子部分。然後，我們只需一個步驟（有幾個子步驟）將它們編譯成最終版本，最終版本將以最終版本爲準。

如果在這些步驟中有任何問題出現，那麼診斷非常容易。

我的建議是儘可能以模糊的術語在白板上寫出步驟，然後根據這些步驟制定步驟。在我而言，這將是：

1. 生成插件飲片
   1. 編譯爲Mac
   2. 編譯PC
   3. 編譯的Linux
2. 做最後的插件
3. 運行插件測試
4. 構建中間IDE（我們要引導建築）
5. 構建最終IDE
6. 運行IDE測試

Answer 7

向上突破你的任務分解成離散的目標/行動，然後用更高級別的腳本一起適當配合他們。

這使得您的構建過程更易於其他人理解（您正在記錄，因此您的團隊中的任何人都可以拿起它，對嗎？），以及增加重複使用的可能性。很可能你不會重用高級腳本（儘管如果你有類似的項目，這可能是可能的），但你可以很容易地重用（即使是複製/粘貼）離散操作。

考慮從存儲庫獲取最新源代碼的示例。您需要將用於檢索代碼的任務/操作與一些日誌記錄語句進行分組，並引用相應的帳戶信息。這是從一個項目到下一個項目非常容易重用的事物。

對於我的團隊環境，我們使用NAnt，因爲它在開發機器（我們編寫/調試腳本的地方）和CI服務器（因爲我們只是在乾淨的環境中執行相同的腳本）之間提供了一個通用的腳本環境。我們使用Jenkins來管理我們的構建，但是在他們的核心中，每個項目只是調用相同的NAnt腳本，然後我們操縱結果（即存檔構建輸出，標記失敗的測試等）。