2、基于 Docker 容器的持续集成

基于 Docker 容器的持续集成

1. 持续集成概述

曾经，软件开发生命周期（SDLC）中的集成阶段是最痛苦的阶段之一。不同团队各自负责不同的应用和服务，花费数周、数月甚至数年时间开发。虽然定期单独验证每个应用和服务并不困难，但当团队领导决定将它们集成时，问题就出现了。我们会发现各种问题，如未满足的依赖、接口通信问题等，经理们也会感到失望、沮丧和紧张，这个阶段可能会持续数周甚至数月。而且，在集成阶段发现的一个 bug 可能意味着要重新做几天或几周的工作。

不过，现在情况有了很大变化。极限编程（XP）等敏捷方法变得熟悉，自动化测试频繁出现，持续集成开始兴起。如今我们知道，以前的软件开发方式是错误的，行业已经取得了很大进步。

持续集成通常指在开发环境中集成、构建和测试代码。它要求开发人员经常将代码集成到共享存储库中，“经常”的频率取决于团队规模、项目大小和编码时间，大多数情况下，开发人员每天至少要将代码推送到共享存储库或与之合并几次。但仅仅将代码推送到共享存储库是不够的，我们还需要一个管道，至少要检出代码并运行与该存储库代码直接或间接相关的所有测试。管道执行的结果可能是失败（红色）或成功（绿色）。如果失败，至少要通知提交代码的人。

持续集成管道应该在每次提交或推送时运行。与持续交付不同，持续集成的管道没有明确的目标。说一个应用与其他应用集成，并不能说明它是否准备好投入生产。我们不知道要使代码达到可交付生产的阶段还需要多少工作。我们所追求的只是确保一个提交不会破坏现有的任何测试。如果操作得当，持续集成是一个巨大的改进。虽然在很多情况下，实现持续集成是一项非常困难的实践，但一旦大家适应了它，结果往往非常令人印象深刻。

1.1 持续集成的要求 <