優化編譯時在持續集成

也許這只是一個瘋狂的人的夢想，但..優化編譯時在持續集成

在我的公司，我們有一個大的C＃.NET項目，約25個解決方案（很老）和3.5〜MIO。同上。我面臨的問題是：構建時間太慢，現在需要7分鐘SSD（開發機器），15分鐘+虛擬機與普通硬盤驅動器（將是我希望部署的TeamCity構建系統）。我知道，構建系統應該是最快的，但這是我在短期內無法改變的。

我想通過編譯最後一次提交所涉及的項目，從所有其他程序集中取出所有其他程序集，以縮短開發人員（最好在Teamcity機器上）的commit-build-unittest反饋循環。一個本地nuget服務器（團隊城市服務器本身版本7.0）。

現在，這將極大地砍下反饋迴路（15分鐘，不到一分鐘，給真正單元測試）爲小的提交。我知道這種部分編譯的問題是跳過編譯錯誤（不匹配的接口可能被忽視）的可能性，但是通過運行第二個（Teamcity？）構建服務器實例來運行整個enchilada可以緩解這個問題，在平行下。但立即獲得第一反饋是非常重要的我。

現在我的問題：是否有任何構建系統/持續集成系統可以處理這個任務？或者我是否必須編寫自己的提交感知後臺服務？這會有點令人討厭，因爲我們使用FinalBuilder腳本，而且這個格式似乎不能被任何API讀取（但沒有深入到那個深處）。

P.S .:另外，我想只對最後一次提交發生變化的項目運行單元測試，或者至少優先考慮它們。但這是事後的想法。

來源

2011-12-27 hko

的[很慢編譯在Visual Studio的時間]可能重複（HTTP ：//stackoverflow.com/questions/55517/very-slow-compile-times-on-visual-studio） – Oded 2011-12-27 15:31:57

是的，看到了，但.. 1）這是很老了，2）許多答案都沒有用C＃可用， 3）少數的人，這將有助於（如一個與自定義VS加載項），不支持任何鏈接和被埋沒所以內心深處我無法及時 – hko 2011-12-27 19:50:23

希望對一些有價值的反饋@hko我知道這似乎是一個難以想象的數字很多要浪費的點，但我會考慮在其他問題上給予獎勵和/或按照答案中的每一個環節在另一邊。 – 2012-01-01 22:32:05

MSBuild確實區分構建腳本目標的「構建」和「重建」 - 普通構建只構建它認爲自從先前構建後更改的項目。

也就是說，從源代碼控制中獲取源代碼時，清理TeamCity代理的構建目錄應該就足夠了（這樣做的可能性可能取決於SCM--它似乎可以在Mercurial中正常工作）觸發構建，而不是重建。

關於單元測試，TeamCIty可以先執行失敗的單元測試，但要確定哪些測試解決哪些源代碼部分對我來說似乎是一項艱鉅的任務，而不是TeamCity AFAIK支持的測試。

來源

2011-12-27 15:31:01 Lucero

hrm ..聽起來不錯，但是：我會用它來測試補丁，因爲它們失敗了，它們不會被提交到「穩定」基線（使用hg）..所以我將不得不「復位」構建目錄到最後從gbaseline提交..不是很難做，但我仍然有點驚訝，似乎沒有一個確定的解決方案.. – hko 2011-12-27 19:43:55

大多數可用的CI引擎採用部署管道進程，該進程專門設計用於減少開發循環中的反饋時間。它像這樣工作，如果任何步驟出錯，立即出現FAIL狀態。

即使對於最複雜的項目，建議（by this book）的前4步要少於2-5分鐘，如果超過了，那麼配置和使用CI的方式有問題處理。

 
Code commit 
triggers ---> 

Step 1. Automatic checkout on CI side 
Step 2. Compile code, ideally 1-2 mins 
Step 3. Save binaries to the artifact repository 
Step 4. Unit test, ideally 1-2 mins 
Step 5. Deploy to staging 
Step 6. Automated integration testing 
Step 7. Automated acceptance testing 
------------------------------------ 
Manual testing 
Manual deploy to production

具體步驟2可以：

一個。將大型解決方案拆分爲單獨的層。每一層都有它自己的Visual Studio解決方案，並且只有與該層相關的項目，從某種意義上說，您可以執行初始龐大解決方案的分散化。在第5步中，您將知道如何將層組裝成可用的應用程序。

b。在TeamCity配置中，您可以指定是執行乾淨檢出還是使用已有的源代碼（可以節省第1步的時間）。檢查MSBuild的目標設置爲Build，它將只拾取自上次構建以來已更改的源文件（保存步驟2中的時間）。

從個人的經驗選項A）是最好的，但如果需要的話，你也可以同時使用）和b），然而其帶來的舊文件的一些潛在的錯誤被保存比需要更長的時間。 Teamcity還支持多個代理（最多3個免費版），這將允許您並行運行任務。

來源

2011-12-27 15:38:00 oleksii

有用的知識，但大多數不回答這個問題，作爲我的問題在於step2。 :)「您也可以通過將大型項目拆分爲更小的項目並僅編譯已更改的庫來縮短編譯時間。」 - >完全可以解決我的問題，關心如何在完全自動化的構建系統中實現這一點，就像我打算建立的一樣，只是基於提交？ Teamcity如何知道只有一個certian項目發生了變化？也許它可以，但在裝飾上它不.. – hko 2011-12-27 19:44:55

@ hko我已經更新了答案的底部，請看看它是否有幫助。 – oleksii 2011-12-27 22:16:42

使用的依賴建立的系統。如果您將SVN與每個項目一起使用在自己的文件夾中，則可以爲每個只構建該項目的c＃項目設置一個CI項目，並快速通知您它是成功還是失敗。

設置有一個Build觸發，使他們第二CI項目的基礎，如果你的第一個成功和有第二個項目運行測試用例第二CI項目。我用詹金斯取得了很好的成績。

對於一個完整的構建，你可以有一個手錶的根文件夾的任何更改，並揭開序幕整個解決方案的構建另一個CI項目。

設置它這樣你可以在每個項目生成和代碼中被選中，該項目在測試較慢的回報快速返回結果

來源

2012-04-12 19:33:34

我們使用Mercurial。不確定Teamcity是否能夠自動構建特殊版本（基於回購子文件夾）進行回購更改，或者是否有任何CI系統可以。 – hko 2012-04-12 21:29:56

優化編譯時在持續集成

回答

相關問題