我正在寻找有关设置TeamCity / Octopus的最佳方法的建议。
目前我在TFS2015中有多个分支 - dev，main和release（目前我们为每个版本创建一个发布分支）。
我们的程序是在开发中开发并部署到开发环境。当我们准备好测试时，我们从dev合并到main并从main部署到测试。很高兴我们创建一个发布分支并从发布分支部署到live。这是一个手动过程。
修补程序在发布分支上完成并部署为live。然后我们合并回main / dev。
我对此非常陌生，到目前为止在VM游乐场我已经设置了TFS2015，TeamCity和Octopus，可以在TFS上签到，在TeamCity上构建/创建包并从Octopus部署这个包。但...
我不确定如何设置TeamCity和Octopus与多个分支机构合作？每个分支有多个项目并生成不同的工件？
当我真实地执行此操作时，我有一个TFS VM，我计划在此处与构建代理一起安装TeamCity和Octopus。这是一个坏主意吗？我应该为TM和Octopus创建一个新VM吗？
任何建议或最佳实践都将受到赞赏。
答案 0 :(得分：4)
虽然你的问题范围很广，但一个好的答案必须涵盖许多细节才能完成。
让我试着指出您需要进一步调查和配置的主要领域。
可以将VCS root配置为通过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周期中的进展。
我知道这不是一个完整的答案。但这是一个良好的开端，我希望可以帮助您根据更具体的技术细节优化您的问题。
答案 1 :(得分：1)
除了TFS之外，我们有一些类似的CI设置要求。在我们的案例中，大多数项目的工作流程是：GitHub - ＆gt; TeamCity - ＆gt;八达通部署。
在Octopus中，我们使用频道功能来分割来自不同分支的版本的工作流程。这意味着我们对项目有分支通道约定，因此TeamCity将特定分支（在我们的例子中是开发和掌握）的打包版本推送到它在Octopus中的相应渠道（参见Channels in Octopus）。
答案 2 :(得分：1)
当然我不知道你的代码等，但我认为你应该从开发合并到测试然后从测试创建一个版本。这样你基本上构建了一个与你在dev上的应用程序相比的应用程序。从测试合并到生产并从那里构建应用程序后，您将发布一个尚未测试的构建。
您应该努力构建一次并多次部署的流程。因此，构建一个从开发人员推广到测试到生产的软件包。
当然，您可以拥有一个可以修复错误的生产分支。八达通中的频道功能非常适用于这样的场景。
答案 3 :(得分：0)
在版本控制设置中 - ＆gt; vcs - ＆gt;分支规格：＆＃34; *＆＃34; （＆＃34;这将完成所有分支，根据需要进行过滤＆＃34;例如+：refs / heads / master +：refs / heads / develop）
Octopus不处理分支，它只是部署，但是你可以使用它们的rest api，例如，如果测试传入develop，那么调用章鱼rest api来创建一个新版本并进行部署。
答案 4 :(得分：0)
回答我自己的问题（对不起），我最终采取的方法是简化我的分支机构并配置TeamCity / Octopus ......
分支策略
我已离开
- dev的
- 主
- 释放
---- release1
---- release2
到
- 主
- 释放
---- release1
---- release2
Master是大多数开发人员的工作，当我们准备好发布时，我们有一个截止点并将master合并到一个新的发布分支。
部署发布分支进行测试，并在发布分支上进行任何测试修复。
测试完成后，我们将从此分支部署到live / production。
这意味着我们测试的二进制文件与我们部署的二进制文件完全相同。
<强> TeamCity的
在TeamCity中，每次签入时都会自动构建master。然后将包裹推到八达通。在这种情况下，八达通充当存储库。 TeamCity还在Octopus上创建了该版本。所以它应该是checkin-＆gt; build-＆gt; create release-＆gt; deploy。
为此，我有一个VCS Root并具有一个名为Build-Master的构建配置。这使用了结帐规则以确保我只使用主分支。我使用Ocotpus包来构建包，然后使用TeamCity中的OctopusDeploy运行器自动创建发布并部署到开发服务器。
发布不同。我想手动部署到测试服务器，而不是每次签入时。当快乐将此推广到现场制作服务器时。
测试中的任何修复都将发布到发布分支并部署进行测试。
测试完成后，我们会提升生存，并在发布分支上创建任何修补程序。显然，所有修复程序/修补程序都合并为master。
因此，在TeamCity中实现这一点，我有一个名为Build-Release的构建配置。同样，我使用结帐规则来确保我正在处理正确的发布分支。
构建使用OctoPack创建一个包，但是这次它没有被推到Octopus。
<强>章鱼
Octopus有一个专门用于将master部署到我们的开发服务器的项目，例如projectnamehere-dev。
在Octopus，我有一个单独的Test / Prod项目。我已经设置了一个指向TeamCity的外部源，因此我可以获取在TeamCity中创建的包。这是在Library-＆gt; External Feeds中设置的。
所以，要部署进行测试。我在TFS中创建了发布分支并为其提供了版本号1,2,3等。然后我将Build-Release构建配置更改为指向此新分支。更改版本号。
然后在Octopus中，我创建了一个版本，选择这个包并部署进行测试。测试的任何修复都在此发布分支上进行。我只是再次构建包并创建一个新版本并选择新包。
测试完成后，在Octopus中，我只是将最后一个版本推广到实时制作服务器。
Octopus中的频道用于两个项目，因为它们具有不同的生命周期。我还创建了两个新的生命周期，默认是dev / test / prod。我创建了一个dev，然后测试/ prod。
希望这有帮助。
