对于我们的Web开发,我们每天进行每周部署.有些情况下我们会将某些内容部署到QA,但是他们几天都没有对其进行测试,然后我们会有一个生产修复或需要更新的增强功能.两个问题:
(1)这对于什么是好的工作流程？
(2)有一个连续的,长寿命的分支称为生产或发布,与每个版本的新发布分支相反,或者只是做主要的所有内容并相应地标记它有什么优点和缺点？同样,这适用于具有可以备份的频繁发布的Web开发.
Ale*_*xis 12
我不太确定我是否理解你的问题,但我的情况与你的情况类似,我使用(修改)以下方法:http://nvie.com/posts/a-successful-git-branching-model/
简而言之,它涉及2个主要分支(主要和开发)和几种类型的支持分支(功能,发布和修补程序).说到你的情况,你可能会将你的发布分支部署到QA ,然后当你有一个生产修复时,你可以在一个修补程序分支中执行它,然后将它合并到主分支和发布分支.
至于你的第二个问题......嗯,你知道,关于分支策略有很多不同意见(例如 ......)我会说,连续生产分支很有效(并不意味着你不能有发布分支来支持你的工作流程).
在我之前的工作中,我们使用了类似于@Alexis提到的方法,主要区别在于.请记住,我们正在研究一些非常重要的遗留软件的新版本(我们的代码库是几百万行代码,介于Java,flex和COBOL之间),并为我们进行了客户合作伙伴beta测试.发布是双/周,包括对客户(虽然它们通常是最新的一个版本,因为那个将首先通过QA),并且在那一周我们不得不做一个'削减',测试,基本QA我们的代码的客户,这是该公司的另一个开发人员,然后发布到真正的QA.
从本质上讲,master是我们的dev分支.如果开发项目需要花费一天或两天的时间,它就会在功能分支上完成,然后在准备就绪时合并到dev中.还有另一个"未来"开发分支,专门用于相当严肃的新功能工作(任何以显着方式改变程序的东西)或重大重构.在某些时候,当我们决定有时间正确测试并消除错误,或者是时候介绍新功能并应对不可避免的痛苦时,这将成为主要的"开发者":)
当发布时,创建了一个名为'release_x'的新分支,然后来自QA的所有修复都在那里实现并合并'up'.我的意思是我们可以在任何时候都有两个或三个版本,所以客户显然会拥有最老的,如果他们找到了一个showstopper,我们可能会修复它们.这将在相关版本的修补程序分支上完成,该分支将在某个时刻合并到该版本并删除(因此您可以轻松地在分支列表中看到未完成的修补程序)并完成另一个构建并发送给客户.存在"修补程序"分支,以便我们可以选择进入特定构建的内容,该内容适用于客户发布以及开发人员发布,以避免针对小型问题的潜在风险修复,从而破坏了针对showstopper的修复程序的发布.
然后将合并到QA人员发布的版本,然后将合并到其他开发人员使用的版本(由于他们依赖我们的插件和j2ee基础设施来完成他们的工作,总是最新版本),然后回到开发,只是为了保持一切在水平上.
目前正在发布的所有版本在Jenkins以及dev分支中都有自己的自动构建循环,其中一些自动化功能测试运行在更重要的(主要是dev和QA)上.每个构建都在用作HEAD的提交的报告中添加了一个标记,并且程序中提供了构建号,以便我们可以确切地看到bug报告者使用的版本.
基本上,两个开发分支,其中一个主要工作将在稍后作为新的主要版本发布.为每个版本发布分支,其中包含修补程序分支.找到最新版本是一件容易的事,寻找具有最大数量的发布分支.
唯一的缺点是,如果你在发布的几个版本上做了很多修复,那么合并的图表......很有意思:)