爲C＃web應用程序和庫設置持續集成服務器

Question

我一直在測試Jenkins CI，現在是時候構建服務器了。什麼是最好的方式去？有很多選擇，我不知道要選擇什麼。

• 共享機器，與其他服務器與它運行，
• 一個虛擬機，用於其他服務器具有不同的OS
• 獨立機
• 使用多臺機器，在機內每個測試每個平臺？ （我有一些基於硒的網絡用戶界面測試）

另外，我想要使用操作系統的建議。我使用msbuild，可能只有在Windows上纔可用...但也許是一個linux服務器，從單聲道的某種生成器可能是最好的方式去。

我沒有與Jenkins綁在一起，但它似乎是最好的。如果你知道更好的選擇，讓我知道。我需要意見，我需要知道存在哪些可能性，並且如果可能的話，要知道別人在做什麼，以及你有什麼經驗與不同的設置，以便我可以做出堅實的決定。

謝謝！

Answer 1

首先要做的事情。我的CI服務器是運行CruiseControl.NET的虛擬機。我不使用詹金斯，所以我真的不能評論它。從外觀上看，詹金斯比CC.NET更加發達。根據虛擬問題和物理問題：最終，就CI而言，它並不重要。只要它在網絡上可見並且有足夠的資源來執行它的功能，其餘的只是管理。就我個人而言，我發現虛擬化的好處值得付出額外的努力。您可以輕鬆添加資源，移動其物理位置，站起來更多的虛擬機來運行集羣。 是衆所周知的，現在每個人都在這樣做。

我的CI服務器位於VMWare ESX服務器上，它有大量的CPU和內存需求。它運行許多其他虛擬機。我有大約35個站點通過CI運行，大概有20個站點託管在機器上，還有70個站點通過CI儀表板手動觸發來設置。我從來沒有遇到任何相關的性能問題。

您的構建服務器理想情況下應該與您計劃部署代碼的計算機具有相同的設置。對於網站來說，這將與您的生產服務器（可能是Windows 2003或2008）具有相同的操作系統。對於桌面應用程序，我可能會選擇最新和最好的操作系統，您的目標是支持和支持。

使用具有多個操作系統的多臺機器只有在構建您試圖在多個操作系統上支持的桌面應用程序時纔有用。在這種情況下，擁有多臺服務器將是理想的，但我認爲這需要很多工作才能完成。就個人而言，我會從簡單開始，讓所有事情都運行起來，並在他們變得真正必要時開始添加一些東西

正如我所提到的，我使用CruiseControl.NET。到目前爲止，這很棒，我對此感到滿意。由於它是用.NET編寫的，而且您使用的是.NET，所以服務器運行所需的運動部件較少（我看到Jenkins是建立在Java之上的）。編寫插件/擴展在理論上會更容易，因爲您已經擁有.NET人員。我從來沒有寫過CC.NET的擴展，所以我不能肯定地說，儘管我知道這是可能的。缺點是社區很小，主動發展緩慢。

最後，我會補充說，這將是很多工作的開始。我花了6個月的時間纔將CI服務器準備好投入生產，還有一些工作將我們所有的項目遷移到其他項目上，並且還有更多的項目來培訓其他開發人員如何使用或使用它。

因此，在總結，

• 虛擬化是很好的！ （但它並不重要）。
• 如果可能的話，您應該將您的CI環境與您部署的任何環境進行匹配。
• 你最好準備好長期承諾。
• 持續集成很好，你不會後悔建立一個CI服務器。無論你選擇，這將是比「牛仔編碼」是用來去:)

編輯其他答案張貼他們的過程比較好，所以我想我應該這樣做呢！ :)

我的商店建立LAMP和.NET網站，所以我們需要一些可以有效地與兩者兼容的東西。我們將CC.NET作爲核心框架運行，但幾乎所有功能都由自定義Nant腳本執行。我們使用Nant是因爲它基於.NET，並且內置了.NET命令，並且2）易於執行命令行操作，這些操作構成了我們所有構建步驟的核心。

CC.NET監聽SVN服務器，並在更新完成後抓取更新。 CC.NET將它們檢查出來並觸發執行所有實際工作的NANT任務。對於.NET，這意味着要進行單元測試mstest並且要構建和發佈msbuild。 PHP通常只是將文件直接移動到目標環境。然後，如果所有步驟都成功，則Robocopy將將文件複製到目標服務器，該目標服務器在Group Policy startup script（Windows服務器映射爲net use且LAMP服務器映射爲Webdrive）期間映射爲網絡驅動器。

我們有開發服務器，登臺/ QA服務器和生產服務器。由於我們使用.NET和LAMP，因此每個環境都有一個服務器 - 總共有6個服務器，全部都是虛擬的。我們的開發服務器是唯一被設置爲持續集成構建的服務器。分階段和生產只能與其他一些SVN巫術一起構建，以防止意外部署。我們還使用MXMLC構建和單元測試AcrionScript，但這對我們來說很少見。

Answer 2

我認爲最好的做法是：

1. 一個單獨的構建服務器（沒關係，如果它是vertual與否）
2. 構建服務器建立在檢查代碼
3. 有無用於測試的單獨部署服務器（再次虛擬並不重要）
4. 將您的構建部署到測試服務器（您可以爲此構建一個獨立的構建，即CI構建和構建和部署構建以進行測試）
5. 任何單位或集成測試，我會在生成服務器上運行，手動測試是在測試服務器上完成

我希望這會有所幫助。

Answer 3

這是我們的設置。我們有兩臺虛擬服務器（一臺構建服務器和一臺測試服務器），然後有兩臺生產服務器。

構建服務器正在運行的TeamCity（對於CI）和的FinalBuilder（對於一些涉及編輯XML文件的更復雜的構建工作，改變配置設置，安裝和註冊的Windows服務）。

我們的大多數應用程序都是ASP，ASP.NET MVC或Web應用程序。 TeamCity會自動檢查代碼中的代碼（通過簽入觸發），編譯需要編譯的任何內容，將最新頁面和DLL部署到構建框上運行的IIS Web服務器。

我們所有的網站都在IIS中設置，以便在同一網站是聽爲www.mysite.com.build，www.mysite.com.test，www.mysite.com多個主機頭。我們在域控制器上設置了DNS通配符別名，以便* .build指向構建服務器，* .test指向測試服務器，等等。

這意味着只要代碼也已經提交併通過TeamCity的建設，公司的每個人可以看到它www.whatever.com.build。

有那麼使用msdeploy.exe推個人網站的另一個TeamCity的工作 - 包括他們的虛擬應用程序和子文件夾 - 從構建服務器到測試服務器。

在每個階段，TeamCity都運行作爲項目一部分的任何單元測試，並且還運行一個單獨的項目，它對我們網站上的各個關鍵URL執行HTTP請求，並確保一切正常，運行並響應。

最後，還有從測試住msdeploys整個服務器「上線」的任務;這意味着完整的服務器配置完全由TeamCity控制，它不鼓勵在實時服務器上進行配置更改，因爲在下次部署期間您的更改將被覆蓋。我們現在已經授權了它，因爲我們需要> 20個項目（和LDAP認證），但免費版本爲我們提供了好幾年的服務，而且它是一款非常棒的軟件。 FinalBuilder價格昂貴，但使用起來非常簡單 - 如果您現金豐富而且時間很短，那就去做吧;如果你有更多的時間比金錢，堅持南特或msbuild和編寫自己的步驟來編輯web.config文件等。

編輯：我錯過了另一個細節 - 我們有一個測試和一個活的數據庫服務器。編碼器的工作站和.build服務器都設置爲使用測試數據庫; * .test和實時服務器與實時數據交談。我們使用SQL Compare（手動）將測試SQL服務器的模式更改推送到實時SQL服務器，但通常TeamCity只是在構建和測試之間調整配置文件以切換數據庫連接字符串。

Answer 4

我的當前設置和最佳實踐：

發展項目和環境：

• C++和C＃應用程序，包括一些基於Web的C＃應用​​程序。
• Windows應用程序。
• Subversion。
• 〜30位開發人員遍佈世界各地訪問集中式構建服務器。
• 開發人員致力於存儲庫的主幹。

構建腳本：

1. 我們採用視覺構建專業，VBP，www.kinook.com，作爲企業構建工具。
2. 構建腳本分層次地設計爲構建腳本層，它執行不同的功能並可以重用。

構建腳本設計：

1. 構建機器層 - 檢查表所需的構建工具，從SVN主幹簽出源代碼。
2. SVN圖層 - 執行分支，版本控制，提交併切換回主幹。
3. 構建產品層 - 構建腳本，構建N個子構建腳本，其中1個子構建腳本= 1個項目（不是VS項目）。 （開發人員友好）
4. 子構建腳本層 - 定義要構建的C＃/ C++解決方案的集合。還定義了構建順序依賴關係。使用MSBuild/t：重建生成解決方案。使用devenv構建特殊項目。 （開發者友好的）

日報構建：

• 構建在構建腳本設計1〜4。

持續集成（CI）建立：

• 在構建腳本的設計則是3和4。

基本編譯環境：（我們的更復雜的項目是建立在這些原則）的持續集成構建服務器進行測試

1. 分居每日構建服務器，還單獨的測試服務器，每個成功的持續集成構建後。 （1個每日構建服務器，1個ci構建服務器，N個測試服務器）
2. 虛擬機與Windows作爲構建機器的多個CPU的服務器。 （用於MSBuild/m）
3. 其他Windows操作系統作爲測試機器。
4. Cruise Control.NET，CCNet，安裝在所有構建/測試機器上。
5. 由CCNet控制的每日構建日常運行時間表。
6. 提交時由CCNet觸發的持續集成構建。

生成行爲：

1. 每日構建始於午夜，出版建立輸出到網絡共享的驅動器，如：\共享\ daily_build。 （是的，我們仍然使用共享驅動器。）:)
2. 成功的每日構建後，將自動觸發ci構建來清理工作副本，檢查源代碼並從頭開始構建。 （MSBuild/t：Build）
3. CI構建然後將構建的二進制輸出複製到網絡共享驅動器，例如：\ share \ ci_build。 （注意，2個不同的文件夾，1每日構建，1 CI構建）

開發環境：

1. 開發商執行批處理文件起牀最新CI生成輸出自己的發展機。
2. 開發人員和項目經理依賴ci構建狀態，安裝CCNet托盤以立即獲得構建結果。
3. 開發商有時會持有彩票看看是誰破壞了這個版本，並在星期五給他/她的底部加一杯啤酒來懲罰他們。 ：D

希望這有助於。

Answer 5

我會建議一個單獨的物理構建服務器的一個簡單的理由......它得到了管理層的認同。

一旦他們真的不得不掏錢，他們會對持續集成的方式變得更加感興趣。