由于特定的情况,我正在考虑为当前的工作场所扩展git-flow模型.但是我的场景非常普遍,我很惊讶没有人在使用git-flow模型之前做过这件事,这让我觉得我错过了一个明显的问题.我的问题是:我提出的延期是否有缺陷？
场景:我有许多开发团队从一个公共代码库开发,我们通过几个(永久)环境推出版本:首先是系统集成环境(SIT),然后是UAT环境,然后是预生产,最后到生产.这是严格顺序的,尽管任何候选版本可能在任何环境中都会失败,因此不再进一步.因此,每个后来的环境只是先前环境的较慢移动版本.
我们正在为源代码控制引入git,我们需要一个工作流,git-flow看起来是一个好的开始.
我们问自己如何在任何时候捕获(即如何知道)每个环境中的内容.git-flow模型似乎基本上有两个核心状态:master和develop.他们有"无限的寿命".其他分支只是"支持分支","有限的生命时间".它们的存在只是为了允许开发并从开发到生产(通过临时发布状态).git-flow模型基于从开发到发布.
但是,这并没有逻辑映射到我们的场景,其多阶段发布顺序.develop当然,我对分公司很好.而master分支显然不映射到我们的生产环境.在原来的git-流程描述说,这大概master:
因此,每次将更改合并回master时,根据定义,这是一个新的生产版本.我们对此非常严格,因此从理论上讲,我们可以使用Git钩子脚本在每次有master提交时自动构建和推出我们的软件到我们的生产服务器.
由于master是连续的生产记录,我们应该扩展git-flow模型以便为SIT,UAT和pre-prod提供相应的分支.毕竟,它们是永久性环境,具有严格的释放程序.它们只比生产更快一点.
这些额外的,永久性的,部门之间坐develop和master,就像他们相应的环境做.
现在,这意味着可以轻松跟踪每个环境的发布以及每个环境的状态.并且每个的合并也更容易:SIT分支需要合并develop,UAT分支需要来自SIT分支的合并,pre-prod分支需要来自UAT分支的合并,最后master分支(用于生产)需要来自pre-prod分支的合并.每个后来的分支只是前一个分支的一个较慢移动的版本.
我错过了什么吗？