代码版本管理与软件部署环境——从Git Flow到DTAP

缺失的拼图

软件开发过程中，代码的版本管理(Version Control)、构建部署(Build & Deployment) 是大部分研发团队必须面对的工作。

讲这两个概念的文章非常多，但很少有人专门把这两件事放在一起讲。我相信不是没有需要，而是不存在标准的流程，各个公司，甚至同一公司的每个团队都不一样。

在这里，我分享一些我能找到的比较权威的资料，通过分析这些信息，帮助大家了解代码版本管理与部署环境完美结合的方案。

 

版本管理

首先来看一下版本管理，现在Git比较流行，个人、小团队的项目，可以使用免费的Github管理，如果想防止隐私数据泄露，可以自建服务使用Gogs。公司内部可以使用GitLab、或Bitbucket。

Github提供了一个简化的工作流程，称为GitHub flow，小型项目可以凑合用着，但对于大型、多版本、多人协作、高发布频次的项目来说，完全不够用。

https://guides.github.com/introduction/flow/

 

Git Flow最初是由 Vincent Driessen 提出的，请参考 https://nvie.com/posts/a-successful-git-branching-model/

这是一套强大的工作流程，被很多公司所推崇，可以搞定大部分复杂需求的项目。

 

构建与部署

构建部署的工作，按阶段来划分，可分为持续集成(Continuous Integration)，持续交付(Continuous Delivery)和持续部署(Continuous Deployment)。

下图来自 https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment

 

 

可以发现，Integration阶段，需要部署到Test环境，Delivery阶段，部署到Staging环境，Deployment阶段部署到线上生产环境。

代码编写阶段，是先于部署的，一般情况下，开发者是在自己电脑上(本机Local)进行代码编写、编译、运行、自测试的，也会在“开发”环境(Development)中部署，与其他协作的开发者共同验证功能。

到底有多少种环境（阶段）？比较流行的说法是：

DTAP: development, testing, acceptance and production

可以在Wikipedia中看到详细解释：https://en.wikipedia.org/wiki/Development,_testing,_acceptance_and_production

这里说的Acceptance，即验收环境，就是对应着大家所熟悉的Staging（演示环境）。所以，可以按自己团队的风格，将这个缩写改为DTSP。

Git Flow & DTAP 强大的组合

Jachim Coudenys 在他的Blog中写了一篇文章，不仅讲到了Git Flow和DTAP，而且还把Semver结合在一起。

https://blog.jachim.be/2017/07/git-flow-dtap-semver/

大家从文章中可以找到一些解答，但Coudenys并没有画一个简单直观的图，为了便于理解，我在这里梳理一下这些概念的关系，以及推荐的做法。

上图是一个简化的流程，没有包含所有情况、所有细节，我相信这个推荐的做法，可以适用于大部分团队的工作流程。

实际上，每个团队可以根据自己的情况选用或更改。

在开发/联调、持续集成、持续交付的阶段，依据上面图中的方式，我们会使用不同的分支管理代码。
我们团队用 release/* 分支发布到 Acceptance/Staging 环境 和 Production 环境。在成功发布后，再将代码合并到master环境，最后再创建tag，以保留稳定代码。

我们还开发了一些自动化脚本，检查当前分支潜在的问题，如是否与特定分支同步最新代码。并且在feature开发时自动创建指向develop分支的Pull Request，在提测阶段，从develop分支自动创建release/*分支。

如果你有更好的实践方法，请留言探讨。