多年來,我創建並調整了一組NAnt腳本來執行完整的項目構建。主腳本採用單個應用程序端點(例如Web應用程序項目),並從源代碼控制,構建完成。這些腳本預先配置了有關構建輸出位置,源代碼控制地址等的必要信息。主要的一點是,您可以提供非常少的信息並從頭開始構建特定的項目。這符合我的問題的「任意」部分。集中/控制.NET項目和解決方案的任意構建
在過去,我曾爲生產一些軟件產品(主要是網絡應用程序)的公司工作。這種環境非常適合於每個產品都有集成器的典型持續集成設置。我已經建立了集成商,既可以作爲CI構建,也可以作爲集成商來處理完整的候選版本構建和QA部署。這些集成商使用主構建腳本,因此集成商本身不僅僅是源控制監視和對主NAnt腳本的調用。
我現在爲創建許多應用程序的開發組工作。通常,開發人員需要支持最初由其他人創建的應用程序。當我開始時,沒有建立管理層。作爲一個業務部門產品套件的四人團隊(大約六個完整系統)的首席開發人員,我在團隊中處於特別獨特的位置。我使用主構建腳本實現了CruiseControl.Net,以執行CI構建以及RC構建。這項工作適用於企業產品套件中的固定項目集。
我一直在使用CCNet多年,所以我完全意識到它可以做什麼。我非常尊重其對持續集成領域的貢獻,因爲我將其用於我的產品套件中的所有項目。我已經向我的團隊強調,使用官方的RC構建集成商作爲任何其他任何位置的開發主要構建者。這爲CCNet控制下的固定項目提供了很好的控制。
但是,還有其他開發人員構建其他應用程序。其中一些是一個開發人員項目,在進入項目生命週期之前,這些開發人員項目通常甚至不能進行源代碼管理(我試圖改變的其他項目)。這些項目中有許多是一次性的,在部署後沒有太多的發展。儘管如此,他們仍然需要得到支持。對這些項目進行整合是因爲,如果沒有對這些項目進行集中式構建管理,發佈候選版本將進入質量保證階段,最終產品將留在個人開發者機器上完成。當然,這提供了零保證,即開發人員機器構建的其他因素中的所有內容都是源代碼控制。
我一直試圖解決的問題是:我可以使用什麼樣的系統來提供對這些任意構建的集中控制?這絕對不是一個獨特的問題。然而,在我關於集中構建,構建自動化和持續集成的大部分閱讀中,重點關注的是固定項目/產品以及支持持續開發的任務。不斷開發新項目的企業正在使用哪些類型的流程?他們沒有使用這些類型的流程嗎?
儘管主構建腳本確實存在於構建服務器上,但它們使用起來笨拙。此外,我寧願限制控制檯訪問構建服務器。因此,一些管理系統需要提供更容易的訪問權限來解除中央系統上的任意構建。
我意識到我正在尋找的東西可能在MS Team Build的封面下。不幸的是,每當我開始閱讀時,當我開始進入MS營銷材料並迅速迷失方向時,我都會感受到流沙的感覺,從不真正瞭解我是否可以用它來完成我想要做的事情。此外,許可成本已被解決,因爲在過去的一些關於Team Foundation Server和Team System的主題的一般性討論中可能會顯示阻止。
我很想聽到任何解決了這個問題的人可能提供的建議。我已經在基於我的主「build-any-project」構建腳本的集中式構建系統上做了一些工作。然而,我所擁有的還處於初級階段,主要是爲了支持我所從事的項目類型。目前缺乏處理許多應用程序類型所需的支持類型,或者Visual Studio中可能存在的大量項目/解決方案配置。
絕對!每個產品一個構建服務器,一個源代碼庫,一個簽出(pull),所有代碼都必須編譯和運行。我在一家擁有集中式構建系統的大型公司工作,因此開發環境受到推向開發人員的所有自定義工具的污染,而不是在自定義構建服務器上需要什麼。嘗試打擊這些工具並讓本地構建工作失去了很多生產力 – 2015-12-15 19:40:17