我一直在研究，并试图找出最佳的分支和部署策略来完成下面的要求。也许我错过了一些东西，但它似乎比看起来更复杂。理想情况下，我们只有一个永久分支“master”，它可以标记特定的提交以将版本标记为生产。
我们目前的战略是基于Git Flow，并拥有永久分支机构'主人'（只有发布到生产）和'开发'。使用多个永久分支模型复杂化的主要问题是将“相同的构建”从登台环境“提升”到生产的概念。目前，这需要在一个单独的源代码分支中完成（部署到staging来自'develop'，部署到prod来自'master'）。
工具： Git（VSTS），TeamCity，Octopus Deploy
要求（功能和修补程序生命周期）：
在作为单个版本推出生产之前，功能会随着时间的推移而累积。修补程序必须能够完成，而不会陷入下一个常规版本的“全有或全无”。
我喜欢有一个带标记的永久分支的想法（re：master / develop split是冗余的，http://endoflineblog.com/gitflow-considered-harmful），但是拥有额外的永久分支可能更好地促进部署到不同的生命周期/版本（功能和修补程序） ）到八达通。
我一直在努力解决这个问题，并且我可能会让事情变得复杂。任何反馈都表示赞赏。
答案 0 :(得分：1)
看来你有很多问题并且它们相当广泛...我会在你的每个要求中添加一些评论作为对话启动器，但是整个线程可能会被版主阻止，因为它绝对不是问题的风格是为了制作的。
所有代码都通过拉取请求（通过分支政策强制执行）进行审核
我好久没看过VSTS了，但我希望他们已经支持分支政策和拉取请求了，所以不确定除了在你的资源库中配置设置之外，你还需要什么。
如果VSTS不支持此功能，您可以考虑转移到一个工具，例如BitBucket，GitHub等。如果您不能（或不想）使用云托管版本，这两个版本都有本地版本。
所有代码都部署到临时环境以进行测试
您可以通过设置lifecycles in Octopus Deploy来实现这一目标，以确保部署/促销遵循您想要的顺序。
我们可以快速返回之前部署的任何代码快照
您已拥有源代码控制，因此您现在所需要的只是从环境中部署的代码到Octopus Deploy中的部署版本，TeamCity中的构建作业，源代码管理中的分支和确切提交的可跟踪性。
为了实现这一目标，你可以做一些事情：
定义适合您的版本控制方案。我喜欢使用语义版本控制。 “Major”和“Minor”版本由开发人员定义，“Patch”是TeamCity中自动递增的数字（％build.number％）。每个git push构建代码并生成唯一的构建版本（％major％。％minor％。％build.number％）
作为TeamCity中构建步骤的一部分，在编译代码之前，请确保使用每个构建分配的版本号修补源文件，提交哈希来自您的源代码管理，和分支名称。例如如果您使用的是.NET，请确保使用该版本更新所有AssemblyInfo.cs文件，以便将版本嵌入到二进制文件中。这允许任何人查询查看二进制文件属性的版本，还允许您在应用程序本身上显示应用程序版本（例如状态栏，页脚，标题，关于框等）
让TeamCity使用每个版本的版本号标记源代码控制，以便快速查看源代码管理历史记录。您可能只想为主分支执行此操作，尽管这是您关心的内容。
使用部署版本号和环境名称将Octopus标记为源代码控制，以便您可以快速查看（从源代码管理中）部署的内容。
第一步和第二步是最重要的，真的。 3和4是很好的。大多数情况下，您只需在环境中打开应用程序，检查“关于”中的提交哈希，并对该提交哈希执行git checkout ...
如果测试成功，那么相同的构建可以从我们的临时环境“升级”到生产（无需再次构建）
再次，Octopus Deploy lifecycles，并确保在使用environment-specific variables在八达通部署期间更新的应用程序配置文件中定义了每个环境中的任何不同内容。
就分支工作流而言，最后一项要求使得必须在部署生命周期开始之前将更改合并到master（或任何“生产”分支）。