多个分支机构的 TeamCity 最佳实践设置
TeamCity best practice setup for multiple branches
我正在寻找有关最佳设置方法的建议 TeamCity/Octopus。
目前我在 TFS2015 中有多个分支 - dev、main 和 release（目前我们为每个版本创建一个 release 分支）。
我们的流程是在dev中开发，部署到dev环境。当我们准备好进行测试时，我们从 dev 合并到 main 并从 main 部署到测试。高兴时，我们创建一个发布分支并部署到发布分支。这是一个手动过程。
修补程序在发布分支上完成并部署到实时。然后我们合并回 main/dev.
我对此完全陌生，到目前为止，我在 VM 操场上设置了 TFS2015、TeamCity 和 Octopus，并且可以签入 TFS，TeamCity 上的 build/create 包并从 Octopus 部署这个包.但是...
我不确定应该如何设置 TeamCity 和 Octopus 以使用多个分支？每个分支的多个项目并生成不同的工件？
当我真正执行此操作时，我有一个 TFS VM，我计划在其上安装 TeamCity 和 Octopus 以及构建代理。这是一个坏主意吗？我应该为 TM 和八达通创建一个新的虚拟机吗？
如有任何建议或最佳做法，我们将不胜感激。
在版本控制设置 -> vcs -> Branch Specifications: "*" ("This will do all branch, filter as needs be" e.g. +:refs/heads/master +:refs/heads/develop)
enter image description here
Octopus 不处理分支，它只部署，但是你可以使用它们的 rest api，例如，如果测试通过开发然后调用章鱼 rest api 来创建一个新的发布和部署。
除 TFS 外，我们的设置要求有些相似 CI。在我们的案例中，大多数项目的工作流程是：GitHub -> TeamCity -> Octopus Deploy。
- 所以我不确定 multi-branch 使用 TFS 设置，但如果使用 GitHub 存储库，则在 TeamCity 中配置起来非常容易。您只需在 VCS 根目录中指定 branch-related 设置（参见 Branch configuration）。配置完成后，TeamCity 将让您 运行 分别为每个指定的分支构建，并将很好地显示每个分支的构建状态。
在 Octopus 中，我们使用 Channels 功能来拆分来自不同分支的发布工作流程。这意味着我们有项目的 channel-per-branch 约定，因此 TeamCity 正在将特定分支（在我们的例子中是开发和主分支）的打包版本推送到 Octopus 中的相应频道（参见 Channels in Octopus）。
- 也许您可以在一台机器上设置所有服务，但恕我直言，这不是 performance-wise 和 scalability-wise.
的最佳做法
虽然你的问题范围很广，但一个好的答案必须涵盖许多细节才能完整。
让我试着指出您需要进一步调查和配置的主要领域。
团队城市
VCS root 可以配置为通过 branch specification
监听多个分支
一个 VCS 根目录可以包含多个 projects/solutions，这些可以在 TeamCity 中分多个步骤构建。
鉴于 Team City 不支持有条件的构建步骤，您将需要一个不同的策略来允许您根据发布渠道/环境改变构建步骤（和参数）。
我推荐的方法是将构建拆分为每个发布渠道（目标环境）的构建定义。
Dev 和 Feature 分支可以共享一个构建定义。Master 和 Hotfix 分支可以共享一个构建定义，因为它们都发布到 staging/production 环境。Release 分支将需要单独的构建定义并发布到 QA/Testing 环境。
这使您可以对每个发布通道的参数和配置进行细粒度控制。从 Dev 分支构建应用程序的调试版本，例如主要版本 3，同时从 Master 分支构建发布版本，主要版本 2.
每个构建定义都会有一个步骤将其 artefacts/packages 发布到 Octopus Deploy，并指定工件所属的通道。
章鱼部署
在 Octopus Deploy 中，define the channels 反映发布渠道，这也反映了您的分支模型。
Develop、Test、Release 是我的标准转到频道
每个通道都可以实施不同的生命周期，以限制通道可以部署到的环境以及应用程序在整个 ALM 周期中的进展方式。
I know this is not a complete answer. but it is a good start that I hope can help you refine your question to more specific technical details.
当然我不知道你在编码等，但我认为你应该远离从开发到测试的合并，然后从测试创建一个版本。这样一来，与开发人员的应用程序相比，您实际上是在构建一个不同的应用程序。从测试合并到生产并从那里构建应用程序后，您将发布一个尚未测试的构建。
您应该争取构建一次并部署多次的流程。因此，构建一个从开发到测试再到生产的包。
当然你可以有一个生产分支，你可以在上面修复错误等。Octopus 中的 Channels 功能非常适合这样的场景。
所以回答我自己的问题（抱歉），我最终采取的方法是简化我的分支并像这样配置 TeamCity/Octopus...
分支策略
我已经从
--开发
--主要
--发布
----发布1
----release2
到
--大师
--发布
----发布1
----release2
Master 是大多数开发人员工作的地方，当我们准备好发布时，我们有一个 cut-off 点并将 master 合并到一个新的发布分支中。
发布分支已部署到测试中，测试中的任何修复都在发布分支上进行。
测试完成后，我们从该分支部署到 live/production。
这意味着我们测试的二进制文件与我们部署到 live/production 的二进制文件完全相同。
Teamcity
在 TeamCity 中，master 会在每次 check-in 发生时自动构建。然后将包裹推送到八达通。在这种情况下，Octopus 充当存储库。 TeamCity 还在 Octopus 上创建发布。所以应该是checkin->build->create release->deploy。
为此，我有一个 VCS Root 和一个名为 Build-Master 的构建配置。这使用结帐规则来确保我只使用 master 分支。我使用 Ocotpus 打包构建包，然后使用 TeamCity 中的 OctopusDeploy runner 自动创建发布并部署到开发服务器。
版本不同。我想手动部署到测试服务器，而不是每次出现 check-in 时。高兴时将其推广到实时生产服务器。
来自测试的任何修复都将对发布分支进行并部署到测试。
测试完成后，我们将上线并在发布分支上进行任何修补程序。显然所有 fixes/hotfixes 都合并到 master.
因此，在 TeamCity 中，为了实现这一点，我有一个名为 Build-Release 的构建配置。同样，我使用结帐规则来确保我处理的是正确的发布分支。
构建使用 OctoPack 创建了一个包，但是这次它没有推送到 Octopus。
章鱼
Octopus 有一个项目专门用于将 master 部署到我们的开发服务器，例如 projectnamehere-dev。
在 Octopus 中，我有一个单独的项目 Test/Prod。我已经设置了指向 TeamCity 的外部提要，因此我可以获取在 TeamCity 中创建的包。这是在 Library->External Feeds 中设置的。
所以，部署测试。我在 TFS 中创建发布分支并为其指定版本号 1、2、3 等。然后我更改 Build-Release 构建配置以指向这个新分支。更改版本号。
然后在 Octopus 中，我创建了一个版本，select 这个包并部署进行测试。测试中的任何修复都在此发布分支上进行。我只是再次构建包并创建一个新版本并选择新包。
测试完成后，我在 Octopus 中将最后一个版本提升到实时生产服务器。
Octopus 中的频道用于两个项目，因为它们具有不同的生命周期。我还新建了两个生命周期，默认是dev/test/prod。我只创建了一个 dev 然后 test/prod.
希望这对您有所帮助。
我正在寻找有关最佳设置方法的建议 TeamCity/Octopus。
目前我在 TFS2015 中有多个分支 - dev、main 和 release（目前我们为每个版本创建一个 release 分支）。
我们的流程是在dev中开发，部署到dev环境。当我们准备好进行测试时，我们从 dev 合并到 main 并从 main 部署到测试。高兴时，我们创建一个发布分支并部署到发布分支。这是一个手动过程。
修补程序在发布分支上完成并部署到实时。然后我们合并回 main/dev.
我对此完全陌生，到目前为止，我在 VM 操场上设置了 TFS2015、TeamCity 和 Octopus，并且可以签入 TFS，TeamCity 上的 build/create 包并从 Octopus 部署这个包.但是...
我不确定应该如何设置 TeamCity 和 Octopus 以使用多个分支？每个分支的多个项目并生成不同的工件？
当我真正执行此操作时，我有一个 TFS VM，我计划在其上安装 TeamCity 和 Octopus 以及构建代理。这是一个坏主意吗？我应该为 TM 和八达通创建一个新的虚拟机吗？
如有任何建议或最佳做法，我们将不胜感激。
在版本控制设置 -> vcs -> Branch Specifications: "*" ("This will do all branch, filter as needs be" e.g. +:refs/heads/master +:refs/heads/develop)
enter image description here
Octopus 不处理分支，它只部署，但是你可以使用它们的 rest api，例如，如果测试通过开发然后调用章鱼 rest api 来创建一个新的发布和部署。
除 TFS 外，我们的设置要求有些相似 CI。在我们的案例中，大多数项目的工作流程是：GitHub -> TeamCity -> Octopus Deploy。
- 所以我不确定 multi-branch 使用 TFS 设置，但如果使用 GitHub 存储库，则在 TeamCity 中配置起来非常容易。您只需在 VCS 根目录中指定 branch-related 设置（参见 Branch configuration）。配置完成后，TeamCity 将让您 运行 分别为每个指定的分支构建，并将很好地显示每个分支的构建状态。
在 Octopus 中，我们使用 Channels 功能来拆分来自不同分支的发布工作流程。这意味着我们有项目的 channel-per-branch 约定，因此 TeamCity 正在将特定分支（在我们的例子中是开发和主分支）的打包版本推送到 Octopus 中的相应频道（参见 Channels in Octopus）。
- 也许您可以在一台机器上设置所有服务，但恕我直言，这不是 performance-wise 和 scalability-wise. 的最佳做法
虽然你的问题范围很广，但一个好的答案必须涵盖许多细节才能完整。
让我试着指出您需要进一步调查和配置的主要领域。
团队城市
VCS root 可以配置为通过 branch specification
监听多个分支一个 VCS 根目录可以包含多个 projects/solutions，这些可以在 TeamCity 中分多个步骤构建。
鉴于 Team City 不支持有条件的构建步骤，您将需要一个不同的策略来允许您根据发布渠道/环境改变构建步骤（和参数）。
我推荐的方法是将构建拆分为每个发布渠道（目标环境）的构建定义。
Dev和Feature分支可以共享一个构建定义。Master和Hotfix分支可以共享一个构建定义，因为它们都发布到 staging/production 环境。Release分支将需要单独的构建定义并发布到 QA/Testing 环境。
这使您可以对每个发布通道的参数和配置进行细粒度控制。从 Dev 分支构建应用程序的调试版本，例如主要版本 3，同时从 Master 分支构建发布版本，主要版本 2.
每个构建定义都会有一个步骤将其 artefacts/packages 发布到 Octopus Deploy，并指定工件所属的通道。
章鱼部署
在 Octopus Deploy 中，define the channels 反映发布渠道，这也反映了您的分支模型。
Develop、Test、Release 是我的标准转到频道
每个通道都可以实施不同的生命周期，以限制通道可以部署到的环境以及应用程序在整个 ALM 周期中的进展方式。
I know this is not a complete answer. but it is a good start that I hope can help you refine your question to more specific technical details.
当然我不知道你在编码等，但我认为你应该远离从开发到测试的合并，然后从测试创建一个版本。这样一来，与开发人员的应用程序相比，您实际上是在构建一个不同的应用程序。从测试合并到生产并从那里构建应用程序后，您将发布一个尚未测试的构建。
您应该争取构建一次并部署多次的流程。因此，构建一个从开发到测试再到生产的包。
当然你可以有一个生产分支，你可以在上面修复错误等。Octopus 中的 Channels 功能非常适合这样的场景。
所以回答我自己的问题（抱歉），我最终采取的方法是简化我的分支并像这样配置 TeamCity/Octopus...
分支策略
我已经从
--开发
--主要
--发布
----发布1
----release2
到
--大师
--发布
----发布1
----release2
Master 是大多数开发人员工作的地方，当我们准备好发布时，我们有一个 cut-off 点并将 master 合并到一个新的发布分支中。
发布分支已部署到测试中，测试中的任何修复都在发布分支上进行。
测试完成后，我们从该分支部署到 live/production。
这意味着我们测试的二进制文件与我们部署到 live/production 的二进制文件完全相同。
Teamcity
在 TeamCity 中，master 会在每次 check-in 发生时自动构建。然后将包裹推送到八达通。在这种情况下，Octopus 充当存储库。 TeamCity 还在 Octopus 上创建发布。所以应该是checkin->build->create release->deploy。
为此，我有一个 VCS Root 和一个名为 Build-Master 的构建配置。这使用结帐规则来确保我只使用 master 分支。我使用 Ocotpus 打包构建包，然后使用 TeamCity 中的 OctopusDeploy runner 自动创建发布并部署到开发服务器。
版本不同。我想手动部署到测试服务器，而不是每次出现 check-in 时。高兴时将其推广到实时生产服务器。
来自测试的任何修复都将对发布分支进行并部署到测试。
测试完成后，我们将上线并在发布分支上进行任何修补程序。显然所有 fixes/hotfixes 都合并到 master.
因此，在 TeamCity 中，为了实现这一点，我有一个名为 Build-Release 的构建配置。同样，我使用结帐规则来确保我处理的是正确的发布分支。
构建使用 OctoPack 创建了一个包，但是这次它没有推送到 Octopus。
章鱼
Octopus 有一个项目专门用于将 master 部署到我们的开发服务器，例如 projectnamehere-dev。
在 Octopus 中，我有一个单独的项目 Test/Prod。我已经设置了指向 TeamCity 的外部提要，因此我可以获取在 TeamCity 中创建的包。这是在 Library->External Feeds 中设置的。
所以，部署测试。我在 TFS 中创建发布分支并为其指定版本号 1、2、3 等。然后我更改 Build-Release 构建配置以指向这个新分支。更改版本号。
然后在 Octopus 中，我创建了一个版本，select 这个包并部署进行测试。测试中的任何修复都在此发布分支上进行。我只是再次构建包并创建一个新版本并选择新包。
测试完成后，我在 Octopus 中将最后一个版本提升到实时生产服务器。
Octopus 中的频道用于两个项目，因为它们具有不同的生命周期。我还新建了两个生命周期，默认是dev/test/prod。我只创建了一个 dev 然后 test/prod.
希望这对您有所帮助。