【发布时间】：2018-06-05 07:31:24
【问题描述】：
我已经参考了这篇文章：https://docs.microsoft.com/en-us/vsts/git/concepts/git-branching-guidance?view=vsts，以了解有关分支概念的更多信息。如果我的理解是正确的，应该有一个 master 分支，然后是一个 release 分支，然后是一个 support 分支和一个 feature 分支。
分支之间的合并定义如下：
- 创建主分支（添加代码）。
- 然后从主分支（也称为主题分支）创建发布分支。
- 然后创建一个支持分支来修复发布分支中的错误，然后在拉取请求中将它们合并回发布分支。
- 从主分支创建一个新功能分支以移植更改。 Cherry-pick 从发布分支到新功能分支的更改。然后在第二个拉取请求中将功能分支合并回主分支。
来到这个问题，假设我有 4 个环境，例如 - 开发、测试、预生产和生产。这里我需要有一个分支和合并机制，需要在VSTS中设置cicd管道。
【问题讨论】：
-
这取决于您要为环境（开发、测试、预生产和生产）设置 CI/CD 的代码是什么。四个环境是在同一个分支上部署相同的代码还是不同的？
-
我正在寻找一些标准方法。因为当我搜索分支概念和管道时，我得到了不同的方法和部分实现参考，并且混淆了哪个是正确的以及整个过程应该如何运行，从代码签入到部署，对于 4 个环境。
-
标准分支模型可以参考nvie.com/posts/a-successful-git-branching-model。它是一种广泛使用的分支结构，也适用于 gitflow。并且基于分支模型，您可以 CI/CD 到开发环境（通过开发分支）和生产环境（通过主分支）。如果设计分别部署四个环境，可以相应调整分支模型。
-
我遇到的另一个疑问是，CI/CD 是否意味着应该有一个发布管道而不是从主分支运行 -> 开发-> 测试-> 预生产->产品。或者每个环境之间的单独管道和这些环境的单独版本也是可以接受的？。
-
每个环境仅适用于一个分支。例如对于 Dev 环境，CI/CD 旨在检查开发分支的代码。只有当develop分支的代码合格后，才可以合并到master或者创建一个release分支，为生产下一个release做准备。
标签： continuous-integration azure-devops devops continuous-deployment