关键要点
本文最初发表在 TestProject——测试自动化博客上
下文将详细介绍持续集成 (CI)，这是软件开发中一项必不可少的实践，以及 Jenkins，业界标准的开源持续集成工具。通过实施持续集成和 Jenkins CI 服务器，您将了解 Jenkins 部署如何帮助您的开发团队发布更高质量的软件并节省宝贵的时间。
想要了解更多关于 Jenkins 和持续集成的信息？请查看以下链接：
现代软件开发实践要求尽快或经常在生产环境中部署功能完善的软件。例如，敏捷方法直接强制执行此行为，方法是让团队以少量增量工作，并在每次冲刺后部署到生产环境（阅读：敏捷项目的测试自动化策略）。
开发团队花费数月时间开发软件，然后将其传递给 QA、UAT 和所有生产线的情况已经不复存在了。如今，重点是拥有功能完善的软件，并且永远不允许危及软件质量的情况发生，例如在发布周期结束时引入重要的软件更改。这就是持续集成发挥作用的地方。
CI 是一种实践，它强制执行将经过测试的代码频繁集成到项目稳定分支的策略。我尤其要强调“经过测试的代码”，因为这意味着在单独分支上开发的功能也经过测试，因此被集成到稳定分支。
通常，DevOps 工程师通常负责设置 CI 管道。如今，DevOps 工程师的角色与测试工程师非常相似，因为两者都确保流程和软件质量。我通常说 QA 和生产是与客户最接近的交汇点。从这个意义上说，CI 为测试工程师提供了非常强大的工具，可以通过积极参与以下领域来提高整体流程和软件质量：
开发团队拥有自己的源代码版本控制存储库，其中包含项目（如今通常是 GitHub）。稳定分支（主分支）通常被认为是工作分支，很少直接在主分支上开发新功能。相反，开发人员创建他们自己的分支来开发新功能（功能 A 的分支 A）。当更改被推送到该特定分支上的存储库并且开发人员发出拉取请求时，应该针对该分支执行一些基本的测试集（冒烟测试）。从 CI 的角度来看，这通常意味着以下几点：
当 CI 流程完成后，从测试工程师和开发人员的角度来看，有以下一些要求：
冒烟测试为将进行代码审查的开发人员以及需要在拉取请求分支上重新测试功能 A 的测试工程师节省了大量时间。如果拉取请求上的冒烟测试失败，那么负责功能 A 的开发人员现在有责任修复冒烟测试功能并发出新的拉取请求（直到修复问题，有问题的代码都不会合并到主分支）。
如果通过此操作，并且功能 A 的新代码从 CI 的角度合并到主分支，则会发生以下情况：
这表明合并成功，冒烟测试功能仍然有效，现在测试工程师有责任再次在主分支上重新测试功能 A（以确保合并不会对功能 A 产生任何副作用）。当然，随着时间的推移，增强测试自动化套件是一个好习惯，以便涵盖大部分功能。
这在项目的后期迭代中变得越来越重要，因为测试工程师有更多任务（测试当前功能以及所有以前的功能）。这就是回归测试派上用场的地方：从 CI 的角度来看，回归测试的执行通常发生在测试工程师明确运行回归测试时或使用调度程序时（例如：每晚执行回归测试）。这是一个好习惯，可以自定义此作业，以便我们可以指定将针对哪个分支执行此作业（在这里您可以阅读更多关于为什么以及何时执行回归测试自动化的信息）。该过程如下所示：
作业：Jenkins 术语中最重要的“单元”是作业。作业是 Jenkins CI 服务器中的单个执行单元，必须有一定的结果（通过/失败）。例如：作业可以是部署作业、冒烟测试作业、回归测试作业等。作业由按顺序执行的多个区域组成，这将在下一段中解释：Jenkins 作业的结构。
插件：Jenkins 测试自动化的主要功能之一是能够通过使用现有插件或创建自己的插件来对其进行自定义。Jenkins 工具中的所有内容，从作业配置部分到 Jenkins 配置部分，实际上都是插件。由于 Jenkins 的社区规模庞大，因此已经存在各种 Jenkins 插件来满足最苛刻的 CI 工作流任务的需求。这意味着，您很可能会遇到一个有用的插件，而不是创建自定义解决方案。
节点：在最简单的设置中，Jenkins 实例将在一台机器上运行，所有作业都将在那里执行。对于小型测试和少量作业，这是有意义的。但是，在实践中，经常有多个团队使用相同的 Jenkins 实例的情况。由于它们有大量的作业，因此在一台实例上执行被认为是不好的做法，原因如下：安全、灾难恢复、性能、可扩展性等。
在 Jenkins 中输入主/从节点：Jenkins 主节点仅用于调度将在 Jenkins 从属机器上执行的作业。这样，Jenkins 主机就不会被大量使用，并且团队拥有自己的从属机器，其大小最适合他们的测试自动化项目。此外，从属节点随后被配置为处理要执行的若干个并行作业（每个节点的执行程序数量）。还可以从 AWS 配置按需节点。这意味着节点仅在需要在其上执行作业时才存在。这非常有用，因为我们想要更大的机器，这些机器只有在运行回归测试时才会被充分利用。对于这种情况，将在 AWS 上启动更大的 EC2 实例，作业将在该实例上执行，完成后（基于配置的空闲时间），该实例将在一段时间内保持活动状态。之后，它将确定在使用按小时付费的服务（例如 AWS 服务）时哪种方式更有优势。
在 Jenkins CI 服务器中，每个 Jenkins 作业都包含多个部分：
常规：在这里，我们指定项目/作业名称/说明，根据需要添加作业参数，定义作业日志轮换策略等。接下来的屏幕显示如何配置日志轮换（您可以指定保留构建日志的天数或要保留的最后构建日志的数量），如何参数化作业（通过添加具有默认值 0.0.1 的字符串 BUILD_ID，但是，此值可以在启动作业时指定）以及如何配置此作业将在哪里执行（从属节点名称）：
Jenkins 源代码管理：顾名思义，这是我们在 Jenkins CI 服务器中定义源代码存储库（如 GitHub 或 Subversion）的地方：
Jenkins 构建触发器：安排作业执行的时间（定期、在其他作业之后、当 GitHub 拉取请求发生时、当更改被推送到 GitHub 时等）。
Jenkins 构建环境：在这里，我们定义与构建将执行的环境相关的选项（每次执行作业时都删除工作区，如果挂起一段时间则中止作业……等）。
Jenkins 构建：在 Jenkins CI 服务器中，这是每个作业最重要的步骤。此步骤的结果会影响作业在执行结束时的状态。根据已安装的插件，许多选项可用，最常用的插件是：执行 shell、执行 Groovy 脚本、调用 Ant/Maven/Gradle 脚本、执行 Windows 批处理命令等。
这是一个经常使用的“执行 shell”插件的示例，它能够内联编写您自己的 shell 脚本或执行现有的 shell 脚本。
Jenkins 构建后操作：作业的这一部分用于报告作业的结果或在 Jenkins 管道中调用其他作业。一般来说，我们可以发送包含作业执行状态的电子邮件，可以发布 HTML 报告、JUnit 结果，可以将构建阶段构建的工件发布到 S3 等。
请注意电子邮件主题行中如何指定 $BUILD_ID。由于此作业已参数化，因此此值在启动此作业时指定。此参数可以在作业的 Jenkins 构建和构建后操作部分中使用。
到目前为止，您已经了解了 Jenkins CI 服务器的主要优势以及 CI 本身如何添加到软件开发流程以及测试工程师中。与其他任何技术一样，需要时间来掌握基础知识并体验优势。我强烈建议您投入时间到 CI 中，从长远来看，这绝对是值得的。特别是，一旦应用 Jenkins CI 服务器，许多痛苦且重复的流程将被自动化，您将突然有更多时间专注于产品改进。
您的团队是否也实施了持续集成和 Jenkins CI 服务器？请随时在评论中分享您团队的经验并提出问题！
本文最初发表在 TestProject——测试自动化博客上
Jenkins 和 Travis CI 都是流行的持续集成工具，但它们有一些关键区别。Jenkins 是一个自托管解决方案，需要您管理和维护自己的服务器。它高度可定制，可以配置为适应几乎任何 CI/CD 工作流。另一方面，Travis CI 是一种基于云的服务，易于设置和使用。它与 GitHub 集成良好，并开箱即用地支持许多语言。但是，对于复杂的工作流，它可能不如 Jenkins 灵活。
Jenkins 和 GitLab CI/CD 都提供强大的持续集成解决方案。Jenkins 以其灵活性和大型插件生态系统而闻名，而 GitLab CI/CD 则以其与 GitLab 生态系统的无缝集成而受到好评。GitLab CI/CD 还提供内置的 Docker 支持，这对于使用 Docker 的团队来说可能是一个很大的优势。
Jenkins 提供了优于其他 CI 服务器的几个优势。它是开源的，并且拥有一个庞大而活跃的社区，这意味着它正在不断改进和更新。它还拥有庞大的插件生态系统，允许您扩展其功能以满足您的特定需求。此外，Jenkins 支持各种语言和工具，使其成为许多不同项目的通用选择。
Jenkins 是一款通用的工具，可以处理 Python 项目的持续集成。它可以自动化 Python 应用程序的构建、测试和部署，并且支持许多流行的 Python 测试框架。Jenkins 还与 Git 等版本控制系统集成良好，使其易于集成到您现有的工作流中。
在 Jenkins 和 Travis CI 之间进行选择时，您应该考虑诸如团队的技术专业知识、CI/CD 工作流的复杂性以及预算等因素。Jenkins 需要更多设置和维护，但提供更大的灵活性和控制性。Travis CI 更易于设置和使用，但对于复杂的工作流而言可能不够灵活。它也是一项付费服务，而 Jenkins 是免费且开源的。
Jenkins 通过自动化代码交付的各个阶段来支持 CI/CD 管道，从集成和测试到部署。它允许持续反馈，因为开发人员可以快速识别和修复代码中的问题。Jenkins 还与 CI/CD 生态系统中的各种工具集成，使其成为实施 CI/CD 管道的通用选择。
是的，Jenkins 可以用于不在 GitHub 上托管的项目。它支持各种版本控制系统，包括 Subversion、Mercurial 和 Perforce。这使得 Jenkins 成为使用不同版本控制系统的团队的通用选择。
Jenkins 通过在多台机器或执行程序之间分配任务来处理并行构建。这允许更快的构建时间和更有效的资源利用。您可以配置 Jenkins 自动管理您的构建基础设施，也可以手动指定哪些任务应该在哪些机器上运行。
设置 Jenkins 时的一些常见挑战包括管理依赖项、配置构建触发器和设置安全访问。但是，Jenkins 拥有一个庞大而活跃的社区，因此有很多资源可以帮助您克服这些挑战。
您可以通过安装插件来扩展 Jenkins 的功能。Jenkins 拥有庞大的插件生态系统，其中包含用于从与不同版本控制系统集成到改进用户界面的各种功能的插件。如果您需要现有插件未提供的功能，您还可以编写自己的插件。
以上是连续集成和Jenkins CI服务器的关键指南的详细内容。更多信息请关注PHP中文网其他相关文章！
