我们目前已将我们的代码发布到生产环境，因此已剪切并进行了分支，以确保我们能够支持我们当前的版本，同时仍支持热修复而不破坏当前版本- 正在开发中。
这是我们目前的结构：
Project-
/Development
/RC1
直到最近使用八达通我们有以下过程：
Dev->Staging/Dev Test->UAT
这很好用，因为我们没有实际发布。
我的问题是八达通如何支持我们的新工作方式？
我们是否在 Octopus 中创建一个名为 RC1 的新/克隆项目，并将我们的 RC1 分支中的 CI 导入其中？然后在不再需要此 RC 时酌情添加/删除？
或者还有其他我们明显错过的方法吗？
【问题讨论】：
标签： release release-management octopus-deploy
不幸的是，Octopus 没有直接提供 - true 支持分支（目前）。它在他们的roadmap 上，用于better branching support 下的 3.1。他们已经talking about this problem 有一段时间了。
您提到的一个想法是为每个分支克隆您的项目。您可以在要克隆的项目中的“设置”选项卡（右侧）下执行此操作。这将允许您复制您的项目并将其简单地重命名为您的一个分支 - 因此一个 PreRelease 或 Release Candidate 项目和另一个是您的主线 Dev（我将保留该项目的相同名称）。我假设您将所有内容都放在同一个项目组中。
或者，您可以在不同分支的项目中更改 NuSpec 文件，这样您就可以清楚地看到项目概览页面或仪表板上正在部署的内容。因此，对于您的 RC 分支，您可以在您的 RC 分支的 NuSpec 中添加后缀 -release，这是合法的（rules on Semantic Versioning 在规则 #9 中讨论预发布）。这样，您可以使用相同的项目，但部署不同的包。如果您的目标服务器相同，那么与克隆相比，这可能是“更轻松”或更简单的方法。
【讨论】：
似乎大多数致力于持续某事的组织最终都会使用 CI 服务器和持续部署到一些手动签核环境，然后需要持续交付到生产环境。这通常会导致分支策略，以隔离候选版本以允许热修复。
我认为这样的问题会引起更多讨论，然后再尝试提供一个万能的答案，恕我直言。
想到的事情有：
在过去我遇到过这种情况时，我会考虑一种代码提升分支策略，它为您提供一个在生产环境中维护的分支 - 这在无法持续部署到生产环境的情况下效果很好。您可以在 ALM Rangers page on CodePlex
上找到更多讨论的分支策略开发人员/测试人员可以通过 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 源获取包以进行发布，那么您始终可以使用 Octopus 中 NuGet 字段上的自定义绑定，并根据您要部署到的环境通过范围变量驱动它。
第 1 步 - 设置两个 Feed
第 2 步 - 为这些提要确定一些变量的范围
第 3 步 - 使用自定义表达式使用 Feed
希望对你有帮助
【讨论】：
我在这里写了一篇关于我们如何做到这一点的博客： http://www.alexjamesbrown.com/blog/development/working-branch-deployments-tfs-octopus/
这有点小技巧，但总而言之：
【讨论】：