八达通部署和多个分支/候选发布者

Question

我们目前已将我们的代码发布到Production,因此已经削减和分支以确保我们可以支持我们当前的版本,同时仍然支持热修复而不会破坏当前版本的任何正在进行的开发.

这是我们目前的结构:

Project-
/Development
/RC1

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

Dev->Staging/Dev Test->UAT

哪个工作正常,因为我们没有实际版本.

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

我们是否在Octopus中创建了一个名为RC1的新/克隆项目,并将RC1分支中的CI添加到其中？然后添加/删除适当的RC不再需要？

还是有另一种我们明显错过的方法吗？

Answer 1

看来,这是争取连续大多数企业的东西最终有一个CI服务器和持续部署了一些手动搁笔环境,然后需要不间断地投放生产.这通常导致分支策略以分离释放候选物以允许热固定.

在尝试提供一个适合所有答案的恕我直言之前,我认为像这样的问题提出了更多的讨论要点.

想到的东西是:

1. 对于任何共享组件,您是否具有"源代码"依赖项或二进制代码.
2. 您拥有什么级别的集成/自动回归测试.
3. 您的部署是由TFS编排的,还是由Octopus中的用户驱动的.
4. 是否有数据库作为需要考虑的应用程序的一部分.
5. 您的应用程序版本编号是如何控制的.
6. 你的发布周期是什么？

在我遇到这种情况的过去,我会考虑一个代码促销分支策略,它为您提供一个分支以维持生产 - 这在不能选择继续部署到生产的情况下运行良好.您可以在CodePlex上的ALM Rangers页面上找到更多分支策略

开发人员/测试人员可以通过staging/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 feed中获取软件包以便发布,那么你总是可以在Octopus的NuGet字段上使用自定义绑定,并根据你要部署的环境通过一个范围变量来驱动它.

第1步 - 设置两个Feed

第2步 - 为这些Feed定义一些变量

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

我希望这有帮助