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

时间 2019-12-04

标签代码版本管理软件部署环境 git flow dtap 栏目 Git 繁體版

原文原文链接

缺失的拼图

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

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

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

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

Github提供了一个简化的工做流程，称为GitHub flow，小型项目能够凑合用着，但对于大型、多版本、多人协做、高发布频次的项目来讲，彻底不够用。测试

Git Flow最初是由 Vincent Driessen 提出的，请参考 nvie.com/posts/a-suc…cdn

这是一套强大的工做流程，被不少公司所推崇，能够搞定大部分复杂需求的项目。blog

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

能够发现，Integration阶段，须要部署到Test环境，Delivery阶段，部署到Staging环境，Deployment阶段部署到线上生产环境。

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

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

DTAP: development, testing, acceptance and production

能够在Wikipedia中看到详细解释：en.wikipedia.org/wiki/Develo…

这里说的Acceptance，即验收环境，就是对应着你们所熟悉的Staging（演示环境）。因此，能够按本身团队的风格，将这个缩写改成DTSP。

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

你们从文章中能够找到一些解答，但Coudenys并无画一个简单直观的图，为了便于理解，我在这里梳理一下这些概念的关系，以及推荐的作法。

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

实际上，每一个团队能够根据本身的状况选用或更改。

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

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

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