具有選擇性功能部署和持續集成的Mercurial工作流程

由12位開發人員組成的團隊，您能幫我確定使用mercurial進行源代碼管理和團隊城市構建服務器的產品構建和部署產品的流程和工作流程嗎？具有選擇性功能部署和持續集成的Mercurial工作流程

我們有一個跟蹤問題和改進請求的系統。其中大部分都是一些開發人員在一兩天至一週的時間內完成的小bug和增強功能。我想要完成的是讓業務人員和IT管理人員就開發人員工作的票證優先協商。完成後，這些更改將被提交併推送到中央存儲庫並在票務系統中標記爲開發完成。那麼qa和業務團隊應該能夠從被標記爲開發完整的票據中進行選擇，並且根據優先級，qa的必要數量和qa資源可用性，在我們的產品中包含下一個版本的票據。

我原本以爲我可以通過讓開發人員對每個票據的新命名分支提交更改來實現此目的。有了這個，每個選定票證的分支可以合併到默認值，並且可以執行構建和部署到qa（並最終生產）。

與此相關的問題是持續集成。在我看來，我只能靜態配置teamcity來構建我們中央存儲庫中的特定分支。也許這是我們所在團隊城市版本的限制。目前使用5.0.3，但升級是一個選項（和我們可能會做的任何事情）。也許有一些棘手的方法使它建立在提示之上，因此觸發構建的提交的分支的頭部發生了？如果開發人員正在爲所有事情提交併推動不同的分支機構，並且這些分支機構在一段時間後纔會合併到默認分支機構中 - 足夠晚了，qa現在正在等待這些更改以進行構建，並且如果構建體損壞，則成本會更高 - 我們沒有一個特定的分支來進行持續集成構建。或許我會讓這個過於複雜和/或忽略一些簡單的東西。幫助表示讚賞。有沒有一種方法可以實現這種版本的選擇性集成，並且在開發人員推動時仍然可以持續集成？

來源

2011-03-02 Dave Rael

命名分支並不適合短期努力，如錯誤和功能。他們更好地保留永久的概念，如「穩定」和「實驗」，標籤用於發佈。閱讀http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ – 2011-03-02 06:20:51

我得出結論說，我試圖採取的方向只是不會工作。將不得不以不同的方式做到這一點。

來源

2011-03-14 23:17:16

使用Jenkins（以前稱爲Hudson），開發人員很容易複製現有的作業（例如：在'默認'分支中構建最新頭部的作業）並進行小改動（例如：構建最新頭部的作業在'jim'分支）。（雖然閱讀我的評論上面爲什麼命名分支可能不是你正在做的正確選擇）。推測團隊城市有類似的東西。

另一條路線就是像你說的那樣做，只是讓建造者總是建立'小費'，不管分支。您可以通過將「小費」作爲分支名稱來實現。這不是一個分支說明符，但是teamcity可能只是'hg update -C -r BRANCHNAME'和'tip'在那裏工作得很好。

來源

2011-03-02 06:24:35

這是有效的，但只要注意兩個開發人員的同時推送將使TeamCity跳過第一個時間很短。 – 2011-03-02 08:38:42

我也看到了Jenkins。單獨的工作避免了這種情況，但總是易於提示。 – 2011-03-02 15:02:08

感謝您的信息。我將在構建配置中的小技巧中嘗試一點。從來沒有想到過那麼簡單的事情。我看到關於命名分支的觀點。會考慮這個，並與我的團隊交談。將回到這裏報告結果並接受答案。 – 2011-03-02 16:16:23

具有選擇性功能部署和持續集成的Mercurial工作流程

回答

相關問題