适应预生产环境的git-flow模型

Question

由于特定的情况,我正在考虑为当前的工作场所扩展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分支的合并.每个后来的分支只是前一个分支的一个较慢移动的版本.

我错过了什么吗？

Answer 1

没有理由我可以看到根据您的模型调整流量.你说你按顺序工作SIT - > UAT - > Pre-Prod.完善.一旦开发稳定(即所有要发布的功能都是功能完成[ed]),然后release start将其移至您的SIT平台以进行QA.一旦发布开始,开发可以继续在develop分支上.master在发布完成之前保持静态.

一旦QA满足,则发布分支将移至UAT.UAT通过,代码滚动到现场,你执行release finish合并回master/develop.

master应始终反映当前在实时平台上的内容,同时develop反映正在积极开发的代码.release分支包含开发针对这些应用的bug修复的静态切(没有新功能不断被推入到这个分支,或者您没有使用git-flow).

根据你的描述,我倾向于说你误解了git-flow模型,因为从我所看到的它完全适合你描述的场景,在SIT期间你需要关心的所有 - > UAT - > Pre -Prod是发布分支,"忘记"掌握/开发甚至存在于此阶段.

对评论的回应

自从我第一次发布这个答案以来,已经有一些评论提出了关于模型如何在许多不同场景中起作用的问题.

1. 客户已要求改进现有功能

回答:

请勿(我不能强调这一点)允许将新功能/增强功能添加到发布分支.这是范围蔓延.新功能是新工作.它们需要单独计算,必须单独处理.无论您的客户是您自己的公司还是第三方,他们理解的一件事就是成本.向他们指出,如果他们中断释放,它将[无限期]延迟它或现有的测试将受到影响.像对待那样对待发布分支master.这是神圣的.只允许修复错误.

2. 科长寿

如果您的发布分支持续数月,则您的发布周期太长.我已经在发布周期的地方工作,平均每3周一次,以及我们每隔几天发布的其他地方.3周应该是QA和UAT发布分支的充足时间.如果你看一个更长的周期,那么我会说公司不灵活

1. git-flow是错误的分支策略(可疑,只要经过精心管理,它几乎适用于任何场景)

2. 你真的需要挑战公司为什么他们有这么长的周期

3. (最有可能) - 你不懂Git-Flow

   3. CI

我在CI中非常成功地使用了Git-Flow.虽然这主要是詹金斯和竹子,但它也适用于特拉维斯CI.

基于提交的Git Hook正是任何分支构建的工作原理.一旦提交(或一系列提交)被推送到远程,我使用的最佳示例会自动构建,然后钩子启动并调用CI平台.然后,CI平台找到相关作业(使用内置模板或使用第三方模块)来触发构建.

我自己的个人设置是在以下情况下触发本地Jenkins实例:

• 我创建了一个分支(在当地分支的jenkins本地安装中创建新工作)
• 我提交(触发当前分支的本地实例构建)
• 本地构建通行证,可以自动推送到远程
• 我推新分支(在远程CI中创建目标构建
• 我推送提交(触发远程CI目标实例)
• 我删除本地分支(删除本地工作)
• 我删除远程分支(删除远程作业)
• 我提出合并请求(软合并功能/ A进入开发和测试 - 测试失败,自动合并拒绝)

这需要一些配置,但任何现代CI平台都可以实现.

与其他任何事情一样,使用Git-Flow的规则只是指导原则.没有严格的规则.如果你想要一个长期存在的发布分支,那么这是你的选择但是除非你注意它们,否则你最终会得到一个不同的代码库,这将很难合并回来.

Git-Flow就像*nix工具中诞生的任何其他产品一样,只是一种工作方式,并且有很多选择.该工具和工作流程只不过是GIT的包装器.您如何选择实施它完全取决于您.