根據版本標籤限制部署到某些環境

Question

我正在使用TFS完成我的CI設置，我還有最後一部分需要克服。目前，每個CI版本都被推送到章魚，nuget軟件包版本爲major.minor.patch.buildid，這些版本在版本爲major.minor.patch-beta {buildid}的八達通版本中使用。因此，每個CI構建都將被標記爲給定版本的測試版本，例如， 1.3.0.194/1.3.0-beta194。在選擇去測試團隊之前，無疑會有一些迭代開發版本 - 讓我們假設在這種情況下選擇的版本是194。在這一點上，我設想創建一個新的版本，1.3.0-rc1，它使用構建194二進制文件。然後將其推送到測試環境並開始測試。可能會有很多測試周期，所以我們假設測試人員簽署1.3.0-rc4版本。然後可以根據1.3.0-rc4二進制文件（即該產品的黃金版本）制定1.3.0新版本。

首先，這是一個好主意嗎？一些反饋將不勝感激。

另外，是否可以根據版本中的標籤將部署限制到某些環境？在我的示例中，我永遠不會希望將標記爲-beta的發行版部署到測試環境 - 只有-rc版本應該是。同樣，只有無標籤構建應該部署到生產環境。

Answer 1

這就是你絕對不應該這樣做的原因。

當您創建1.3.0.194版本時，Octopus將保證爲工件，進程和變量提供快照，這意味着部署將在每個環境中以相同的方式執行。

您可以儘可能多地編輯這些內容，但由於這些更改會導致1.3.0.194不會因爲這些更改而變得更具風險，因爲它們會忽略它們。

如果您創建了版本1.3.0.194，然後對部署過程或變量進行了更改，則這些更改將泄漏到版本1.3.0.194-beta中，並且它將不再是您測試過的相同部署。當您更改爲版本1.3.0.194-rc時會發生同樣的情況 - 更多更改會因您尚未進行實際測試而泄漏。

您的部署過程就像您的代碼一樣，應該進行版本控制和測試 - 這就是您在整個部署生命週期中使用相同版本所獲得的結果。

Answer 2

標記部署與beta/rc包是一個壞主意，因爲這會在您的交付過程中引入一個額外的步驟。你將會有許多內置的版本，一些會進入上層環境，有些則不會。沒關係。你試圖把這些看作是用於依賴版本管理的常規Nuget包。這不一樣。只需增加您的內部版本號而無需使用標籤，並促進獲得簽名的版本。

您不應該將部署限制爲基於標籤的環境。