多个分支机构的 TeamCity 最佳实践设置

Question

我正在寻找有关设置 TeamCity/Octopus 的最佳方法的建议。

目前我在 TFS2015 中有多个分支 - 开发、主和发布（目前我们为每个发布创建一个发布分支）。

我们的程序是在 dev 中开发并部署到 dev 环境。当我们准备好进行测试时，我们从 dev 合并到 main 并从 main 部署到 test。高兴时，我们创建一个发布分支并部署到发布分支。这是一个手动过程。

修补程序在发布分支上完成并部署到现场。然后我们合并回 main/dev。

我对此完全陌生，到目前为止，我在虚拟机游乐场中设置了 TFS2015、TeamCity 和 Octopus，并且可以签入 TFS、在 TeamCity 上构建/创建包并从 Octopus 部署这个包。但是……

1. 我不确定应该如何设置 TeamCity 和 Octopus 以与多个分支机构一起工作？每个分支有多个项目并生成不同的工件？

2. 当我真正做到这一点时，我有一个 TFS 虚拟机，我计划在其上安装 TeamCity 和 Octopus 以及构建代理。这是一个坏主意吗？我应该为 TM 和 Octopus 创建一个新的虚拟机吗？

我们将不胜感激任何建议或最佳实践。

Answer 1

在版本控制设置 -> vcs -> 分支规范：“*”（“这将执行所有分支，根据需要进行过滤”例如 +:refs/heads/master +:refs/heads/develop）

enter image description here

Octopus 不处理分支，它只部署，但是您可以使用它们的 rest api，例如，如果在开发中测试通过，则调用 octopus 的 rest api 来创建新的发布和部署。

Answer 2

除了 TFS 之外，我们的 CI 设置要求有些相似。在我们的案例中，大多数项目的工作流程是：GitHub -> TeamCity -> Octopus Deploy。

1. 所以我不确定使用 TFS 进行多分支设置，但如果使用 GitHub 存储库，在 TeamCity 中配置非常容易。您只需在 VCS 根目录中指定与分支相关的设置（请参阅Branch configuration）。配置完成后，TeamCity 将允许您分别为每个指定的分支运行构建，并很好地显示每个分支的构建状态。

在 Octopus 中，我们使用 Channels 功能来拆分来自不同分支的发布工作流。这意味着我们为项目设置了每个分支的通道约定，因此 TeamCity 将来自特定分支（在我们的例子中是开发和主分支）的打包版本推送到 Octopus 中的相应通道（请参阅Channels in Octopus）。

1. 也许您可以在单台机器上设置所有服务，但恕我直言，从性能和可扩展性角度考虑并不是最佳做法。

Answer 3

虽然你的问题范围很广，但一个好的答案必须涵盖很多细节才能完整。

让我试着指出您需要进一步调查和配置的主要领域。

团队城市

可以将 VCS 根配置为通过 branch specification 侦听多个分支

一个 VCS 根目录可以包含多个项目/解决方案，这些可以在 TeamCity 中通过多个步骤构建。

鉴于 Team City 不支持有条件的构建步骤，您将需要不同的策略来允许您根据发布渠道/环境改变构建步骤（和参数）。

我推荐的方法是将构建拆分为每个发布通道（目标环境）的构建定义。

• Dev 和 Feature 分支可以共享一个构建定义。
• Master 和 Hotfix 分支可以共享一个构建定义，因为它们都发布到暂存/生产环境。
• Release 分支需要单独的构建定义并发布到 QA/测试环境。

这使您可以细粒度地控制每个发布通道的参数和配置。从 Dev 分支构建您的应用的调试版本，例如在主要版本 3 中，同时从主要版本 2 的 Master 分支构建发布版本。

每个构建定义都会有一个步骤将其工件/包发布到 Octopus Deploy，并指定工件所属的通道。

八达通部署

在 Octopus Deploy 中，define the channels 反映发布渠道，这也反映了您的分支模型。

Develop、Test、Release 是我的标准转到频道

每个通道都可以强制执行不同的生命周期，以限制通道可以部署到的环境以及应用程序在整个 ALM 周期中的进展方式。

我知道这不是一个完整的答案。但这是一个好的开始，我希望可以帮助您将问题细化为更具体的技术细节。

Answer 4

当然，我不知道你的代码等，但我认为你应该远离从开发合并到测试，然后从测试创建一个版本。这样一来，与您在开发中拥有的应用程序相比，您实际上是在构建一个不同的应用程序。一旦您从测试合并到生产并从那里构建您的应用程序，您将发布一个您尚未测试的构建。

您应该努力实现一次构建并多次部署的流程。因此，构建一个从开发到测试再到生产的软件包。

当然，您可以拥有一个生产分支，您可以在其上修复错误等。Octopus 中的频道功能非常适合此类场景。

Answer 5

所以回答我自己的问题（对不起），我最终采取的方法是简化我的分支并像这样配置 TeamCity/Octopus...

分支策略

我已经搬家了

--开发

--主要

--发布

----发布1

----发布2

到

--大师

--发布

----发布1

----发布2

Master 是大多数开发人员工作的地方，当我们准备好发布时，我们有一个截止点并将 master 合并到一个新的发布分支中。

发布分支被部署以进行测试，并且测试中的任何修复都在发布分支上进行。

测试完成后，我们会从该分支部署到实时/生产环境。

这意味着我们测试的二进制文件与我们部署到实时/生产环境的二进制文件完全相同。

团队城市

在 TeamCity 中，每次签到时都会自动构建 master。然后将包推送到八达通。在这种情况下，八达通充当存储库。 TeamCity 还在 Octopus 上创建版本。所以应该是checkin->build->create release->deploy。

为此，我有一个 VCS Root 并有一个名为 Build-Master 的构建配置。这使用结帐规则来确保我只使用主分支。我使用 Ocotpus 打包来构建包，然后使用 TeamCity 中的 OctopusDeploy 运行器自动创建发布并部署到开发服务器。

版本不同。我想手动部署到测试服务器，而不是每次签入时。高兴时将其推广到实时生产服务器。

测试中的任何修复都将在发布分支中进行并部署到测试。

测试完成后，我们会升级为 live 并在发布分支上进行任何修补程序。显然，所有的修复程序/热修复程序都被合并到 master 中。

因此，在 TeamCity 中，为了实现这一点，我有一个名为 Build-Release 的构建配置。同样，我使用结帐规则来确保我正在处理正确的发布分支。

构建使用 OctoPack 创建一个包，但是这次它没有推送到 Octopus。

八达通

Octopus 有一个专门用于将 master 部署到我们的开发服务器的项目，例如 projectnamehere-dev。

在 Octopus 中，我有一个单独的测试/生产项目。我已经设置了一个指向 TeamCity 的外部提要，因此我可以获取在 TeamCity 中创建的包。这是在 Library->External Feeds 中设置的。

所以，部署到测试。我在 TFS 中创建发布分支并给它一个版本号，1,2,3 等。然后我将 Build-Release 构建配置更改为指向这个新分支。更改版本号。

然后在 Octopus 中，我创建一个版本，选择这个包并部署进行测试。测试中的任何修复都在此发布分支上进行。我只是再次构建包并创建一个新版本并选择新包。

测试完成后，在 Octopus 中，我只是将最后一个版本推广到实时生产服务器。

Octopus 中的频道用于这两个项目，因为它们具有不同的生命周期。我还创建了两个新的生命周期，默认是 dev/test/prod。我只创建了一个开发人员，然后进行了测试/生产。

希望这会有所帮助。