我是一个进入持续整合世界的新人。
因为我想要正确地练习CI / CD，所以我试着阅读最佳实践，但这对我来说是一个难题。
我想知道有经验的人是否可以告诉我今天关于以下事项的做法状况：
＆＃34;功能分支/分支＆＃34;和CI。
我的意思是，我发现人们最挣扎的部分实际上是：
需要经常集成的CI实践（在主线中） 以及鼓励功能驱动的开发实践 发展。
从红色开始，即使没有完成，在功能隔离和集成功能之间存在张力。
因此我想知道，今天的问题是什么状态。
我看到像抽象和功能切换这样的东西，但也有其他解决方案，我还不清楚，但似乎依赖工具来管理一些自动合并，首先合并和测试分支，并将其合并回来在主线。
听起来像Teamcity和Bomboo这样的工具都支持它。 jenkins理由不太明确。
因此，如果有人可以帮助制定针对该特定问题的最新技术，我将不胜感激
答案 0 :(得分：2)
强制披露：我是Bitrise的CTO和联合创始人，这是一个针对移动应用开发者的CI / CD服务（主要）。
我们通常建议（以及我们在内部应用程序开发中使用的实践）是测试每个代码推送，无论哪个分支。总是尝试推送工作/通过单元测试的代码，当然还有编写单元测试。
在大多数CI / CD服务中，您可以定义一般测试构建，该构建将针对每个代码推送和单独的构建配置/流程进行部署。您应该有一个基本测试构建配置，它将测试每个代码推送，无论您使用哪个分支，都应该尝试实现绿色构建。
一些CI / CD服务提供了拉取请求测试而没有实际合并拉取请求，因此当您检查拉取请求时，您可以确定在合并之后测试仍将通过。虽然它很复杂（即使你正在阅读拉动请求，主分支机构的状态也会发生变化）为此我们的团队并不依赖于这些测试，而只是简单地做合并，如果失败，我们立即修复。
对于像这样的开发设置，您至少需要两个主要分支，并且您始终在功能分支上工作。两个主要分支是：
此分支策略适用于大多数CI / CD服务，对于您可以并且希望经常发布的移动应用程序和SaaS服务（至少对于您的测试人员/临时服务器而言）是一个不错的选择。