release - Octopus 部署和多个分支/发布候选

Question

我们目前已经将我们的代码发布到生产环境，因此我们进行了剪切和分支以确保我们能够支持我们当前的版本，同时仍然支持热修复而不破坏当前版本-持续发展。

这是我们当前的结构:

Project-
/Development
/RC1

直到最近使用八达通，我们有以下过程:

Dev->Staging/Dev Test->UAT

这很好用，因为我们没有实际发布。

我的问题是八达通如何支持我们的新工作方式？

我们是否在 Octopus 中创建一个名为 RC1 的新/克隆项目，并将 RC1 分支中的 CI 放入其中？然后在不再需要此 RC 时酌情添加/删除？

或者是否还有另一种我们显然错过的方法？

Answer 1

似乎大多数致力于持续某事的组织最终都拥有 CI 服务器和持续部署到某个手动签核环境，然后需要持续交付到生产环境。这通常会导致分支策略，以便隔离发布候选以允许热修复。

我认为在尝试提供一个适合所有人的答案恕我直言之前，像这样的问题会引发更多讨论点。

我想到的是:

1. 您是否有任何共享组件的“源代码”依赖项或二进制依赖项。
2. 您的集成/自动回归测试水平如何。
3. 您的部署是由 TFS 编排的，还是由 Octopus 中的用户驱动的。
4. 是否有数据库作为需要考虑的应用程序的一部分。
5. 如何控制您的应用程序版本编号。
6. 您的发布周期是多少。

在过去我遇到过这种情况时，我会寻找一种代码提升分支策略，它为您提供一个分支以在生产中维护 - 这在无法持续部署到生产的情况下效果很好。您可以在 ALM Rangers page on CodePlex 上找到更多讨论的分支策略。

开发人员/测试人员可以通过暂存/uat 持续推送代码/功能/错误修复。在发布时，Dev 分支合并到 Release 分支，这会导致发布构建并创建 nuget 包。这仍然应该以完全相同的方式发布到 Octopus，只是它是一个全新的版本，而不是对以前版本的升级。这将需要确保版本编号没有冲突，因此一种策略可能是在主版本号上有所不同——这取决于您当前的设置。然而，这确实采取了一种固执己见的观点，即部署是由构建服务器而不是 Octopus Deploy 编排的。主要是 TeamCity/TFS 调用 Ocotpus API，而不是用户在 Octopus 中选择内部版本号(众所周知我们会犯错误)

ocoto.exe create-release --version GENERATED_BY_BUILD_SERVER

对我来说，我问客户的最大问题是“什么限制意味着您不能持续部署到生产环境”。解决该约束(参见约束理论)，您就无需解决一开始就不需要存在的问题(我知道并不总是那么直截了当)

我强烈建议您不要在 Octopus 中为不同的环境克隆项目，因为这违反直觉。在一天结束时，您只是告诉 Octopus 去获取这个应用程序的这个 nuget 包版本，并将它部署到这个环境中。如果您想从不同的 NuGet 提要获取包以进行发布，那么您始终可以在 Octopus 中的 NuGet 字段上使用自定义绑定(bind)，并根据您要部署到的环境通过范围变量驱动它。

第 1 步 - 设置两个 Feed

第 2 步 - 为这些提要确定一些变量的范围

第 3 步 - 使用自定义表达式使用提要

希望对你有帮助