持续集成CI（Continuous Integration）

观看本文后，你将能够描述持续集成（Continuous Integration）和持续交付（Continuous Delivery），解释在持续集成中使用小批量的原因，并描述持续集成的好处。
人们常把 CI/CD 当作一个概念来使用，但持续集成和持续交付是两种不同的实践方式。持续集成（CI）是指在一组测试通过后，持续地将每位开发者的变更构建、测试并集成到主分支中的过程。其结果是得到具有潜在可部署性的代码。
持续交付（CD）是一系列旨在确保代码能够快速、安全地部署到生产环境中的实践，它通过将每一项变更交付到一个类似生产环境的环境中来实现。注意，我说的是 “类似生产环境”。代码不一定要部署到生产环境中，实际上，很多人用 “持续部署（Continuous Deployment）” 这个术语来指代持续向生产环境进行部署的情况。你只需要将代码部署到类似开发、测试或预发布这样模拟生产环境的地方就行。例如，如果生产环境是在 Kubernetes 上运行的容器，那你就应该将代码部署到 Kubernetes 容器的开发环境中。
我们先来看看传统的开发方式是怎样的。开发者在长期存在的开发分支上工作。通常他们这么做是因为旧版本的版本控制系统在每次创建分支时都会对代码进行完整复制，所以创建分支的成本很高。这种成本使得人们不愿意创建分支，即便创建了，也不经常删除。而对于像 Git 这样的现代版本控制系统来说，情况已不再如此。但一些开发团队仍保留了传统做法。这些开发分支与发布分支是分开的，并且会定期合并到发布分支中，但合并过程往往问题不断。这是因为长时间积累的大量变更，使得分支更容易出现合并冲突。在发布候选分支上会定期进行构建，有时是每天晚上。开发者继续在开发分支上添加内容，这使得开发分支与主发布分支的差异越来越大。在这种情况下，可能需要花费数天时间来合并代码，才能让其恢复正常运行。
相比之下，持续集成是一种开发实践，它要求开发者频繁地将代码集成到共享存储库中，这里说的频繁，如果可能的话，是指每天都进行。这可以通过让开发者在短期存在的功能分支上工作来实现，一旦功能完成，这些分支就会合并到主分支中。这意味着你在每个功能完成后就进行集成，而不是等到一长串功能都完成后才进行集成。每次代码提交都会通过自动化测试和自动化构建进行验证，这样团队就能尽早且频繁地发现问题。一旦合并完成，该分支就会被删除，然后为新功能创建一个新分支。
小批量工作有助于实现持续集成。通过定期提交，每位开发者都可以减少冲突变更的数量，因为两次合并之间的时间间隔更短。时间间隔越长，合并冲突的风险就越大。如果在代码上工作一周后一次性提交所有内容，那么新功能与其他功能冲突的风险就会增加。这些冲突可能很难解决，而且很耗时。使用拉取请求（pull request）可以让团队成员就他们所做的变更进行沟通。每个拉取请求都是一次代码审查的机会，其他开发者可以审查代码。这确保了所有代码都能被不止一个人查看，降低了出现问题的风险。通常认为，每天至少提交一次所有变更，或者每个功能构建提交一次，是持续集成定义的一部分。
说到拉取请求，每个拉取请求都应该进行构建和测试，而且这应该是自动进行的。系统应该构建当前工作版本的变更内容，以验证集成是否正确。一种常见的做法是使用自动化，即由一个 CI 工具监控版本控制系统，然后自动执行构建操作。大多数 CI 工具，如 Travis CI、Circle CI、Jenkins 和 GitHub Actions，都具备监控版本控制系统中的变更以及自动化构建过程的能力。一旦代码构建完成，就应该运行所有测试，以确认代码的运行符合开发者的预期。换句话说，要让构建具备自测试功能。测试结果应该反馈到拉取请求中，并且绝对不要合并测试失败的拉取请求。实践持续集成的好处之一是，你可以对变更做出更快的反应，开发进度也能更快。开发进度能更快是因为测试是自动化的。由于测试是自动化的，你就会知道到目前为止你所做的一切都经过了测试并且是有效的。如果自动运行这些测试，你就不会把时间浪费在测试上，而是把时间花在构建功能上。持续集成降低了集成代码的风险，因为你集成的是较小的变更。变更越少，因变更而导致故障的风险就越低。提交拉取请求让更多人关注代码，从而提高了代码质量。每个人都能对代码质量提出意见。最后，你会知道版本控制中的代码是可用的。记住，主分支应该始终是可部署的。我曾有学生问我：“我可以在构建用户界面之后再编写测试用例吗？” 我告诉他们，到那时就太晚了。你已经将用户界面提交到主分支了，如果我们需要部署主分支，却不知道用户界面是否可用。你应该假定未经测试的代码是不可用的。绝不要将未经测试的代码合并到主分支中。主分支应该始终是可部署的。
在本文中，你了解到持续集成是在测试通过后，将每一项变更构建、测试并集成到主分支中。持续交付确保代码能够通过将每一项变更交付到类似生产环境中，从而快速、安全地部署到生产环境。小批量工作通过减少冲突变更的数量来辅助持续集成。持续集成的好处包括更快的反应速度、更快的开发进度以及降低集成代码的风险。