此促銷模式有什么問題？

Question

我正在與一個客戶見面，他們描述了他們如何使用SVN將代碼從開發人員推廣到測試到生產。 我所聽到的一切確實困擾着我，從那以后我一直在思考。

我無法簡要解釋為什么我認為這是錯誤的-也許您可以提供幫助？

我的目標是提出一些客觀的事實或措施，以說服客戶改變為更正常的東西。 如果我錯了，這是個好方法，那么我也想知道。

過程如下：

1. 會針對單個任務進行更改，並且提交會在提交消息中包含任務ID。
2. 為了將代碼從一個級別提升到另一個級別，他們通過任務ID查詢SVN，並為該任務更改了每個單獨文件的特定版本。
3. 它們生成一個腳本，該腳本簽出目標服務器上步驟2中的每個文件。
4. 有時他們想部署多個任務。 他們的腳本通過並協調了要升級的所有任務中所需的各種文件修訂。

該客戶不使用CI / CD工具。 他們僅使用此增量方法進行部署。

Answer 1

促銷模型的問題在於它們會增加復雜性，但是復雜性不會給流程增加任何東西。 分支的目的是允許多個開發流。 在升級模型中，只有一個開發流，但是現在涉及三個分支。 有人必須從一種蒸汽融合到另一種蒸汽。 質量檢查和生產都必須等待某人進行升級。

更糟糕的是，不能100％地確定開發的內容是QA正在測試的東西，而QA經過測試和批准的東西是投入生產的東西。 畢竟，質量檢查和生產都使用兩個單獨的版本。

讓我們簡化一下：兩個分支，一個dev分支和一個test分支：

• 質量檢查正在等待測試的新版本。
• 最終，開發圍繞着推動修訂版90進行測試 。 如果一切順利，你對測試相同的測試版本90。
• QA測試版本90那是上測試 。 他們發現錯誤並將其報告給開發。
• 質量檢查現在正在等待其他升遷。
• 開發人員修復了修訂版100中的錯誤。他們升級了該版本進行測試 。 同樣，修訂版100中的內容應與測試中的內容相同。
• 質量檢查人員現在可以測試位於測試分支上的修訂版100。

如果我們沒有多個分支會怎樣？

• QA測試修改90。這是相同的版本上測試的上方。
• 質量檢查發現錯誤並將其報告給開發。
• 開發人員修復了修訂版100中的錯誤。
• 質量檢查現在測試修訂版100。

除沒有所有分支伏都教進行之外，其他過程相同。 沒有人必須記住將一個分支從一個分支提升到另一個分支。 無需驗證一個分支與另一個分支是否相同。

更重要的是，開發人員在90版中構建的軟件與QA正在測試的軟件相同。 無需重建軟件，並希望它是相同的。 當QA決定可以進行特定版本的生產時，將推廣經過QA測試的相同軟件。 無需進行特殊構建，並希望它與QA測試過的相同。

以這種方式來考慮，只有一個開發流。 開發正處於該開發流程的頂端。 質量檢查落后於時間，無法測試較早的版本。 使用更老的版本，生產的時間可以追溯到更遠。

最后，所有促銷分支所做的只是在不增加任何收益的情況下增加了開發的復雜性。 生活和發展就已經足夠復雜了。 沒有理由使任何一個更加困難。