簡體 English 中英

並行開發/測試環境中的發布管理-死鎖

[英]Release management in parallel development/testing environment -Deadlock

原文 2012-05-11 09:52:21 3 1 version-control

我陷入僵局。 我們是一家與醫療保健相關的產品開發公司。我們正在使用SVN版本控制系統。我們有多個客戶，每個客戶都有專門的開發分支。 客戶分支總是從主干分支出來的。我們使用主干作為我們一個高級客戶（例如PC1）的開發分支。

現在，我們向PC1發布了一個名為PDT_5.0的產品版本。 發行發生在Release分支PDT_5.0上，該分支最初是從主干分支出來的。

與PDT_5.0版本有關的錯誤修復程序已經開始出現。與此同時，客戶要求我們提供一些次要功能，我們承諾在幾個月后提供這些功能。 新功能已在后備箱中開發。 但是，在投入使用之前，新功能必須經過質量檢查測試，並且必須獲得客戶方的批准。

現在，死鎖了：PDT_5.0已經生效。 在PDT_5.0的Release分支中進行了錯誤修復。 功能開發已完成。必須進行質量檢查。 但是，我們不能等待質量檢查完成測試再發布，因為必須盡快發布實時的緊急錯誤修復。 我在這里完全迷路了。

問題是由於功能太小，我不想從干線分支出去。

1 個解決方案

有了一個已描述的過程，我看不到其他任何方法，除了對所需的功能和修補程序進行選擇性合並（又稱櫻桃挑選）之外，還沒有其他方法可以從您的主干中將分支發布到客戶的分支中。

展望未來，如果您有基於特定於客戶的功能和分支機構的業務模型，則需要更改交付更改的方式。

第一種選擇是您要求銷售人員不要承諾在正式發布之前提供功能。 說真的 只需說“伙計們，謝謝您出售我們還沒有的功能，但是請不要做出任何其他的部署承諾”。 這樣，您將使發布保持簡單明了：主干->發布分支->客戶分支。 之后，您的開發團隊將特定更改從一個舊分支遷移到一個新分支。

否則，當您必須來回整合錯誤修正之前，您應該調整流程以適應這個新現實，直到您將自己埋沒在大量的三角洲中等待其整合為止。

希望對您有幫助...