最佳做法，建設樹幹反對樹幹？

Question

我們有許多使用共享組件（dll）的公共基礎的項目。 目前，每個項目的開發版本都與從組件主幹構建的dll鏈接。 （即主幹構建使用其他主幹構建的dll）

當我們進行發佈構建時，我們有一個腳本遍歷項目文件，並將主幹引用替換爲特定編號的組件版本（構建自一個標記的分支）

我認爲這會削弱我們在開發過程中所做的測試，因爲我實際上正在使用的項目正在使用不同的dll來發布版本將使用的內容。我希望始終針對組件的編號版本進行開發，只有在有特定需求時才更新它們。

然而，團隊中的其他人認爲，除非我們針對主幹進行開發（並且每次發佈更新到組件的較新版本），否則我們的問題是（a）我們的產品幾乎無法更新到新版本（b）當我們確實需要更新它時，這將是一項艱鉅的任務，因爲組件的源/接口會發生很大的變化。

你遵循什麼做法，爲什麼？

編輯：對不起，我剛剛意識到我有些困惑，提到有幾個主要產品共享組件 - 儘管它們共享組件，但它們不在同一臺PC上運行。我關心的是這樣一個事實，因爲每次發佈產品時組件可能會發生變化（即使沒有更新組件的特定要求），測試將會錯過組件中所做的一些微妙變化，而與產品上正在進行的具體工作。

Answer 1

嗯，我可能在這裏是少數，但這歸結爲釋放管理。

根據定義，根據trunk開發一組共享組件意味着組件是一個「移動目標」 - 使用這些共享組件的開發人員不一定知道新發現的缺陷或故障是否到期到項目代碼或共享組件，導致生產力下降，IMNSHO。

「共享組件」的發佈週期各不相同。讓您的其他開發人員休息並修復項目將要使用的共享組件的版本，並使用tags,labels或branches來標識共享組件版本。在下一個項目迭代中，碰到共享組件的最新「穩定」或「生產」版本。

還有另一種「嗅覺」在這裏，請原諒我的表達。在項目發佈之間有「共享組件」的「源代碼/接口將發生很大變化」聽起來像組件不那麼穩固或不一定是共享的。

又見這個問題的答案Shared components throughout all projects, is there a better alternative than svn:externals?

Answer 2

你應該有很強的接口，很少改變，所以改變版本不應該那麼難。

分離版本並針對特定版本工作會增加需要更改的開銷，但它也應該鼓勵更少的整體接口更改，這對長期有幫助。

Answer 3

我們同時針對多個分支機構和主幹進行開發，我們選擇用我們將推出的代碼構建和測試每個分支。我不認爲這是安全的任何其他方式。

基本上，如果一個開發人員正在開發主幹，他們所要做的就是擔心從主幹構建並將代碼提交到主幹。

任何在分支上工作的開發人員都需要構建和測試該分支（有多個項目全部分支/標記了相同的構建/發佈）。當他們向該分支提交更改時，他們還必須將這些單獨的更改合併到主幹中。

我們希望所有開發人員都熟悉SCM（SVN）並能夠維護多個代碼分支。作爲一個團隊，我們處理重大框架變化或巨大的代碼更改，以最大限度地減少麻煩的合併。

Answer 4

這裏有兩件事。首先，我認爲你是對的;您想要針對最新的開發版本進行構建，而不是針對舊版本。如果你還沒有，將看到一個情況，在這種情況下發布版本爆炸，你必須做一個全能的清理差異。

無論如何，我個人很喜歡「致力於幹線，從分支發佈」模型。所有提交到主幹，隔夜構建或CI構建都是針對主幹，人們自由創建分支。當您的中繼線符合接受標準時，標記候選發佈者，但請保留對該中繼線的更新。如果您的發佈週期較長，那麼您的可能已將發佈n + 1的更改添加到主幹中，但理想情況下，您應該縮短髮布週期。如果有是更改樹幹不應該在發佈的版本，並且您有需要改變的問題，創建針對標記版本的一個分支---並確保您合併任何更改回主幹一旦你有一個實際發佈。

Answer 5

我們使用scons的建築體系，有我們自己的根目錄中指定我們要構建的應用程序時使用何種版本的每個庫的文件。

這減少了需要像你提到的改變在幾個地點版本名稱。

Answer 6

（b）是否是一個有效的參數取決於你的共享組件的更新頻率和多少。如果他們經常在工作場所變化，那麼您可能會被迫「發展」最新版本。這本身是否是一個問題是一個有效的問題。

不過，從身邊的事情，我看不出你如何能推動代碼投入生產而不會被反對在生產中使用的共享組件進行測試。你對發佈版本做了第二個測試周期嗎？你只是祈禱什麼都不休息？坦率地說，在這些情況下可以顛倒（b）以支持您的觀點：如果中繼線與最近標記的分支不同，那麼必須努力確保您的應用程序正常運行。

如果您的共享組件經常被標記，那麼您的同事可能是正確的，並且管理從最新標記到幹線的增量更改比管理從任意版本X（在最後的版本）到任意版本Y（當您選擇升級時確定）。