在我的公司,我们有一个CI/Build服务器,我们用它来测试和构建版本(以及功能和开发分支).在git flow分支模型中,当它是时候释放你分支开发并命名它(例如)release-1.4.然后,CI/Build服务器将自动构建分支,我们将其部署到临时服务器以进行手动集成测试.一旦我们对构建感到满意,我们就想部署它.但是在git flow分支模型中,我们需要首先合并到master和tag.问题是,在合并之后我们还需要运行另一个构建和测试周期吗？
合并和标记结尾似乎很奇怪,标记指向不同(技术上)提交,而不是发布版本.在我们进入主人之后重建似乎也很糟糕,因为我们会感到有必要测试该构建以确保它也可以.
我提出的选项是:
问题是,在合并之后我们还需要运行另一个构建和测试周期吗？
该合并不应该破坏任何东西,因为它应该是一个快进合并,master上的所有提交都在发布分支上.因此,您无法在主合并后创建不在发布分支上的错误.
从技术上讲,这不是你构建的精确提交,但理念是主分支上的所有内容都在生产中.在任何时候,如果有人拉动主分支,他应该获得当前的生产代码.这就是为什么你不合并然后构建,测试,等待,以及修复master上的东西以进行发布.
现在事情并不总是顺利进行.当发布已经过验证并准备发布时,您可能遇到需要修补程序的主要生产错误,在这种情况下,某些提交已被推送到掌握和开发但不是发布分支.如果发生这种情况,我会重新定义(在团队工作时要小心,合并更安全)发布分支(以便赶上修补程序)并重新重建.总而言之,如果创建发布分支的时间与验证时间之间没有修补程序,则无需重建.