項目/代碼發佈策略

Question

背景：我在一家傳統上從事研究型工作並且沒有太多商業空間經驗的小型軟件公司工作。我們現在正試圖進入商業世界。由於我們研究的起源，我們習慣於非常快速的開發週期以及在維護適當版本的項目方面很少的結構。

問題：由於每個開發人員對代碼庫的看法略有不同，所以缺乏結構現在被證明是有點阻礙的。一個開發人員發現的問題不能被另一個開發人員重現，並且在一個構建中發現的問題可能在下一個消失（或者更糟糕的是，可能出現新問題）。這對於負責整合所有項目並確保質量和性能標準得到滿足的人來說是非常令人沮喪的體驗 - 即我自己。

可能的解決方案：我個人認爲，我們需要通過固定版本號和常規版本實施更好的結構。不言而喻，正確的版本控制如何能夠解決我們許多問題，但這當然不是沒有問題 - 開發人員需要做額外的工作來執行和測試版本，並且不再能夠使用最新版本的一切。

問題：爲了說明問題 - 您推薦哪種策略來確保發佈所需的流程和工作儘可能流暢地進行？我們使用git進行版本控制，maven用於構建系統，並且我們運行了錯誤跟蹤和持續集成系統，所以我相信這些工具就在那裏。我只是不確定正確的發佈過程應該是什麼樣子。

Answer 1

您擁有三大版本：版本控制，通過Maven一鍵構建，持續構建服務器以及錯誤跟蹤。這聽起來像你們正在傾向於敏捷方法論，所以你應該努力保持產品的主幹版本始終處於可交付狀態。

當您決定製作第一個版本時，請爲該版本的幹線版本創建一個分支。決定一個標籤方案，並確保標籤的分支版本。例如，您的第一個版本可能是1.0.4530，其中1表示第一版本，0表示它是第一版本候選版本，4530是版本控制更改編號。您測試此版本分支並修復它的重要錯誤。過了一段時間，你發佈另一個候選版本，比如1.1.4807。這個過程重複多次（比如說），你的版本變得足夠好，並且你發佈了1.3.5167版本。

同時，您的新開發僅發生在中繼版本中，您不時需要將1.x版本分支中的錯誤修復合併回中繼。稍後，您將從中繼分出一個2.x分支，以重複第二次發佈的過程。你通常會有幾個活躍的分支（加上幹線），發展局限於幹線，每個分支保持原始狀態，獨立於開發。

你們會得到一些東西，你們的開發者協調問題會變得不那麼頻繁。但是這些問題幾乎都只限於主幹，而不是發佈分支。

Answer 2

一個問題一個開發商發現是 沒有其他開發人員可重複的，在一個構建中發現，在未來可能 消失 和問題（或者更糟，可能會出現新的問題 ）。這使得 非常令人沮喪的經驗 誰負責 整合所有項目和 確保質量和性能 標準符合 - 即我自己。

潛在的解決方案：我個人認爲我們需要通過固定版本號 和常規版本來執行更好的 結構 。

我不認爲你需要有非常頻繁的發佈來協調內部。你可以通過版本控制來做到這一點。在報告問題時，只需讓人們討論特定的git修訂版。另外請注意，您也必須協調任何外部依賴項/庫。某種vendor branches可以幫助解決這個問題。

Answer 3

有一些關於一般話題的書籍;亞馬遜搜索甚至返回三個標題專門用於「使用git進行版本控制」。

我想你會受益於定義代碼庫的規範視圖。稱它爲測試。如果它出現在測試中，則問題是一個問題。如果某個開發人員認爲某個問題沒有出現，那麼由開發人員來確定哪些是重要區別;同樣對於出現在開發者視圖中的問題，而不是在測試中。

一個約定是測試每晚從源重新構建。更嚴格的慣例是在每次更新時重新構建Test。如果您的團隊規模較小（五個或更少），並且不會分散在很遠的距離或多個時區，合理的第一個近似方法是在安裝了工具鏈的服務器上測試git工作區以及一些cron作業，以便該工作區每晚更新和重建（通常）。

Answer 4

這聽起來像開發人員需要使用「測試分支」，並更多地尊重「穩定/生產分支」。

出售的概念是「在這個分支做你的狂野西部的東西」，當你對結果感到滿意的時候，你將它合併到這個「無聊的穩定生產分支」中......或者類似的東西）