持续集成、持续交付和持续部署 的真正区别

有很多介绍什么是持续集成、持续交付和持续部署的内容。但是这些流程首先要做什么？

了解 CI 和 CD 解决的问题以正确使用它们至关重要。这将使你的团队可以改善流程。并避免花力气追求那些不会给你的过程带来任何价值的幻想指标。
持续集成是一个团队问题
如果你和同一团队的多个开发者在一个存储库中工作，其中载有最新版本的代码位于存储库的主分支。开发人员在不同分支上从事不同的工作。 一旦某人完成变更后，他会将其推送或合并到主分支。最终，整个团队将拉取到这一变更。

我们要避免的情况是错误的提交进入主分支。错误意味着代码无法编译，或者应用无法启动或无法使用。为什么？并不是因为应用程序损坏了或者因为所有测试必须始终为绿色。那不是问题，你可能永远不会部署该版本并等待修复。

问题是你的整个团队都陷入了困境。所有拉渠道错误提交的开发人员都会花 5 分钟的时间来排查为什么程序无法运行。有些人可能会尝试查找错误的提交。有些人会尝试与有问题的代码作者并行解决问题。

这对你的团队来说是浪费时间。最糟糕的是，重复发生的事件加剧了对主分支的不信任，并鼓励开发人员分开工作。

持续集成就是为了防止主分支被破坏，从而使你的团队不会陷入困境。也就是说，这并不是要让所有测试始终保持绿色并且主分支在每次提交时都可以部署到生产中。

持续集成的过程独立于任何工具。你可以手动验证分支和主分支的合并在本地是否有效，然后将合并推送到存储库，但是这种方式是非常低效的。这就是使用自动检查实施持续集成的原因。

检查应确保最低限度：
该应用程序应能够构建并启动
最关键的功能应始终处于工作状态（用户注册/登录过程以及关键的业务功能）
所有开发人员都依赖的应用程序的通用层应该是稳定的。这意味着需要对这些通用代码进行单元测试。

实际上，这意味着你需要拉取适用于你的任何单元测试框架并保护应用程序的公共层。有时，代码不是很多，可以很快完成。另外，你还需要添加“冒烟测试”以验证代码是否已编译以及应用程序是否启动。这对于带有疯狂依赖注入的技术（例如 Java Spring 或 .NET Core）尤其重要。在大型项目中，很容易错误修改依赖项，因此必须确认该应用程序至少总是始终启动。

如果你有成百上千的测试，则无需为每个合并运行所有测试。这将花费大量时间，并且大多数测试可能会验证“非团队阻止者”功能。

我们将在接下来的部分中看到持续交付的流程将如何充分利用这许多测试。
与工具无关
工具和自动检查都可以。但是，如果你的开发人员仅合并他们工作了几个星期的巨型分支机构，那么他们将无济于事。团队将花费大量时间合并分支并修复最终将出现的代码不兼容问题。与错误的提交阻塞在一起一样浪费时间。

持续集成与工具无关。这是关于小块工作并将新代码集成到主分支并频繁提取的问题。

通常至少每天一次，将你正在处理的任务拆分为较小的任务，经常合并你的代码，并经常拉取。这样一来，没有人能分开工作超过一两天，问题就没有时间滚雪球了。

一项大型任务不必全部都在一个分支中，应该永远不会。将进行中的工作合并到主分支的技术称为“抽象分支”和“功能切换”。有关更多详细信息，请参见博客文章《如何开始进行持续集成》。
良好的 CI 关键点
这非常简单，保持简短，最多 3-7 分钟。这与CPU和资源无关，这与开发人员的生产力有关。生产力的首要规则是专注。做一件事，完成它，然后移到下一件事。

上下文切换成本很高。研究表明，当你被打扰时，大约需要 23 分钟才能重新专注于某件事。想象一下，你推动分支进行合并，然后开始另一个任务，你花了15到20分钟才能解决。在进入区域后的一分钟，你会从前一个任务的20分钟的 CI 构建中收到“构建失败”通知。你再次推送它，你来回切换很容易超过20分钟。

每天一次或两次将 20 分钟乘以你的团队中的开发人员的数量……这浪费了很多宝贵的时间。

现在想象一下反馈在 3 分钟之内到来。而且你知道会的。你可能根本不会启动新任务。你将有时间再次阅读你的代码，或者在等待时检查 PR，失败的通知将会到来。你将修复它，然后继续下一个任务。这就是你的流程应启用的焦点。

原文转自：https://fire.ci/blog/the-difference-between-ci-and-cd/