意外發布的代碼生活。如何防止再次發生？

Question

我們最近發生了一些事件，有些代碼已經發布到現在還沒有計劃發佈。

它顯然已經檢查到後備箱。這很好，我猜你想'檢查早，經常檢查'。

但是在這種情況下，它不應該在下一個版本中發佈。

可以採取什麼樣的檢查/策略/過程來避免代碼被過早過濾。

在我看來，即使持續集成和單元測試，這是一個人工程序問題？

- Lee

Answer 1

修改您的集成過程。

如果「上線」意味着有人正在執行某些批處理腳本 - 如果再次發生此問題，請不要感到驚訝。

另外，考慮分支。一個常見的例子可能是使用trunk進行開發，一個單獨的分支用於測試（比如說，每週合併一次），以及RTC的最後一個分支（來自上述測試分支）。

這個分支在部署到生產之前應該進行徹底的測試。

Answer 2

這個問題顯然不是檢查代碼庫到代碼庫。你有兩個問題在這裏：

1）任何代碼應該生活必須有一個特殊的版本標籤或分支或任何取決於您使用的源代碼管理。因此，代碼在開發中永遠不會與代碼混淆。

2）誰是未經測試的代碼仍然活着的白癡？如果開展活動的人認爲您的開發代碼是可以投入使用的，那麼缺乏溝通是很重要的。

Answer 3

你應該有不同的分支，如果你的源代碼控制軟件允許這樣的事情。

在這種情況下，您將有一個人負責將已經達到主分支質量欄的代碼合併到生產分支中。

---

UPDATE： 雖然具體的產品，在TFS 2008 Branching Guide 2.0提供的指南有很多，可以適用於具有創建新的分支的能力，其他源代碼控制軟件的指導方針。

Answer 4

不要從樹幹生產到生產環境 - 手動將測試的樹幹代碼合併到生產分支中並由此生存。或者如其他答案所述，在測試過程中使用適合您需要的任何分支和步驟。另外，花費超過一天左右時間的代碼更改一般應在單獨的功能分支中進行，直到完成爲止。

Answer 5

可以放什麼樣的檢查/策略/ 進程的地方，避免 代碼被釋放住 過早。

我會說任何沒有檢查到主幹作爲習慣性發展儀式的進程，這意味着除了牛仔編碼以外的任何開發模式。

讓開發人員儘早登記並經常進入他們的功能分支，並在時間到了時將其合併到主幹中。

Answer 6

要繼續討論分支，這是保持版本處理結構的方法。

我們使用trunk作爲主分支，當我們到達開發週期中的一個特定點時，我們不允許再提供一些特性（只有bug修復），我們爲該版本分支一個NEW分支（而不是經歷容易出錯的合併），並且在我們構建發行版之前，該分支已經過很好的測試。當然，要實現這個功能，每個程序員都需要在功能凍結日期臨近時保持提交清潔。

Answer 7

我們構建了一個可與Subversion一起使用的發佈管理器。 www.ReleaseManager.com 因此，我們可以控制問題編號（或錯誤編號）發佈的內容，並且我們擁有控制權，以便我們可以在需要時從版本中抽取出來。尋找測試站點現在:)

Answer 8

在我看來，即使連續 集成和單元測試，這是一個 人的程序問題？

確實！但是，您應該能夠從您的基礎架構獲得一些支持，以支持您的流程的人員方面。當你要發佈一個版本時，你應該能夠很容易地看到所有的提交以及所有相關的問題。這是持續集成的報告方面。 （我想說有four elements（pdf）：構建，部署，測試和報告。）