jenkins - 截至 2015 年初，持续集成与功能分支的最新技术水平如何？

Question

关闭。这个问题需要多问 focused 。目前不接受答案。

---

想要改进此问题吗？更新问题，使其仅关注一个问题 editing this post .

已关闭 8 年前。

Improve this question

我是持续集成世界的新手。

因为我想正确地练习 CI/CD，所以我尝试阅读最佳实践，但这对我来说是一个难题。

请问有经验的人可以告诉我，截至今天，以下问题的实践情况如何:

“功能分支/按功能分支”和 CI。

我的意思是，我发现人们最挣扎的部分实际上是:

The practice of CI that requires frequent integration (in mainline) and the development practice that encourage feature driven development.

据我所知，即使尚未完成，陷入功能隔离和集成功能之间也存在紧张关系。

因此我想知道，这件事今天的情况如何。

我看到了诸如按抽象分支和功能切换之类的东西，但也看到了其他我还不清楚的解决方案，但他们似乎依赖于工具来管理一些自动合并，首先合并并测试分支，然后将其合并回来在主线上。

听起来像 Teamcity 和 Bomboo 这样的工具都支持这一点。 Jenkins 的理由不太清楚。

因此，如果有人可以帮助制定该特定问题的最新技术，我将不胜感激

Answer 1

强制披露:我是 Bitrise 的 CTO 和联合创始人，主要针对移动应用开发者的 CI/CD 服务。

我们通常建议(以及我们用于内部应用程序开发的实践)是测试每一个代码推送，无论哪个分支。始终尝试推送有效/通过单元测试的代码，当然还要编写单元测试。

在大多数 CI/CD 服务中，您可以定义一个通用测试构建，该测试构建将为每次代码推送执行，并定义一个单独的构建配置/部署过程。您应该有一个基本的测试构建配置，它将测试每个代码推送，并且无论您在哪个分支上工作，您都应该尝试实现绿色构建。

一些 CI/CD 服务提供拉取请求测试，而无需实际合并拉取请求，这样当您检查拉取请求时，您可以确定合并后测试仍然会通过。不过，它相当复杂(即使您正在阅读拉取请求，主分支的状态也可能会发生变化)，为此我们的团队不依赖这些测试，而是简单地进行合并，如果失败，我们会立即修复它。

对于这样的开发设置，您至少需要两个主要分支，并且您始终在功能分支上工作。两个主要分支是:

• 开发主分支:这是开发人员用来创建新功能分支的分支。在 gitflow 中，它通常称为“开发”。
• 稳定/生产分支:此分支仅包含稳定、经过测试的代码，仅从开发主分支合并，并且仅当它是绿色/通过所有测试时。在 gitflow 中，该分支称为 master。

此分支策略适用于大多数 CI/CD 服务，对于您可以并且希望频繁发布的移动应用程序和 SaaS 服务来说是一个不错的选择(至少对于您的测试人员/登台服务器而言)。