《持续交付：发布可靠软件的系统方法》这本书里是不提倡feature branch这种方式的，比方说要不要而对这个分支配置CI/CD，如果长时间不能合并到主干，合并的时候还有很多问题。还有很多其他理由


实际操作中，我们是小地迭代都在主干做（哪怕有新feature），非常大的版本升级，会新拉一个主干，以后都基于新主干，CI/CD和QA的工作主要基于主干来做，感觉效果还是可以的

我们主要是desktop应用程序，不是web程序，也许不同类型可能有区别

【 在 eGust 的大作中提到: 】
: feature branch 并入主 branch 之后，再让 qa 把 feature 重新测一遍吗？如果发现问题，之后的 fix 是直接进主 branch 还是有其它的流程？我其实挺好奇其他公司都是怎么做的，毕竟网上能找到的文章大都忽略了 QA 的角色，而在实际中真的 CI/CD 后敢直接拿用户当小白鼠的还是极少数。所以不管有没有自动测试，不至于一个小错误就浪费许多人的时间，应该是每个项目都会遇到的问题。
: 这么来看，我们 rails app 还算是很容易搞了，如果能用上 container 的话。我们最主要的问题是数据库，我本地电脑上的测试，启动 oracle container 大概要30秒左右能用，然后大概3分钟建好空的数据库。一旦数据库准备好，启动应用本身不会超过1分钟。按照我的估计，技术上不超过10分钟就能从0跑起来，跟10个小时比起来几乎就没有时间成本。上个厕所，倒杯水，再读一下 jira，差不多也就能用了。
:
--
FROM 124.126.202.*