看起来你有很多问题而且它们相当广泛...我会在你的每个要求中添加一些评论作为对话启动者，但这整个帖子可能会被版主阻止，因为它绝对不是问题的风格SO是为了 .
所有代码都通过拉取请求进行审核(通过分支政策强制执行)
我没有看过很多年的VSTS，但我希望他们已经支持分支策略和拉取请求，所以不确定除了配置存储库中的设置之外，还有什么需要 .
如果VSTS不支持，您可以考虑转移到一个工具，例如， BitBucket，_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
所有代码都部署到临时环境进行测试
您可以通过设置lifecycles in Octopus Deploy来实现这一目标，以确保部署/促销遵循您想要的顺序 .
我们可以快速返回之前部署的任何代码快照
您已经拥有源代码控制，因此您现在所需要的只是从环境中部署的代码到Octopus Deploy中的部署版本，TeamCity中的构建作业，源代码管理中的分支和精确提交的可跟踪性 .
为了达到这个目的，你可以做一些事情：
定义适合您的版本控制方案 . 我喜欢使用语义版本控制 . "Major"和"Minor"版本由开发人员定义，"Patch"是TeamCity中自动递增的数字(％build.number％) . 每个 git push 构建代码并生成一个唯一的构建版本(％major％ . ％minor％ . ％build.number％)
作为TeamCity中构建步骤的一部分，在编译代码之前，请确保使用每个构建分配的 the version number (来自源代码管理的 commit hash ， and the branch name )修补源文件 . 例如如果您使用的是.NET，请确保使用该版本更新所有AssemblyInfo.cs文件，以便将版本嵌入到二进制文件中 . 这允许任何人查询查看二进制文件属性的版本，还允许您在应用程序本身上显示应用程序版本(例如状态栏，页脚， Headers ，关于框等)
让TeamCity使用每个构建的版本号标记源代码控制，以便快速查看源代码管理历史记录 . 您可能只想为主分支执行此操作，尽管这是您关心的内容 .
使用部署版本号和环境名称将Octopus标记为源代码管理，以便快速完成看(从您的源代码管理中)部署在哪里 .
第一步和第二步是最重要的，真的 . 3和4是很好的 . 大多数情况下，您只需在环境中打开应用程序，检查"About"中的提交哈希值，并对该提交哈希值执行 git checkout ...
如果测试成功，那么可以从我们的暂存环境“升级”到 生产环境 (不需要再次构建)
同样，Octopus Deploy lifecycles，并确保在应用程序的配置文件中定义了每个环境中的任何不同内容，该文件在Octopus部署期间使用environment-specific variables进行更新 .
在分支工作流方面，最后一个要求使得必须在部署生命周期开始之前将更改合并到 master (或任何"production"分支) .
