Jenkins中的Poll SCM和Build periodically的区别

最新推荐文章于 2025-03-10 11:54:31 发布

酥心糖小可爱

最新推荐文章于 2025-03-10 11:54:31 发布

阅读量747

点赞数 11

文章标签： jenkins 运维

本文链接：https://blog.youkuaiyun.com/ZXY_ZXR/article/details/144939103

版权

触发机制
- Poll SCM：
  - 这是一种基于代码仓库状态变化的触发机制。它会按照用户设定的时间间隔，周期性地去检查源代码管理（SCM）系统（如Git、Subversion等），看是否有新的代码提交、修改或其他变化。只有当检测到代码仓库发生了变化，并且当前时间符合轮询时间间隔要求时，才会触发构建。例如，若轮询间隔设置为每10分钟一次，它会每隔10分钟检查一次代码仓库，若在第12分钟发现了代码更新，会在第20分钟（下一个轮询时间）触发构建。
- Build periodically：
  - 它是一种基于固定时间计划的触发机制，完全不考虑代码仓库是否有变化。只要时间一到，就会触发构建。例如，若设置为每天下午2点（14:00）构建，那么无论代码仓库在当天是否有新的提交或修改，Jenkins都会在14:00启动构建任务。
及时性
- Poll SCM：
  - 及时性取决于轮询间隔。轮询间隔越短，发现代码变化并触发构建就越及时。但是由于它是周期性检查，所以无法做到实时触发构建。如果在两次轮询之间发生了代码更新，那么直到下一次轮询时才会发现变化并触发构建，这中间可能会有延迟。例如，轮询间隔为30分钟，代码在10:15更新，那么要到10:30才会触发构建。
- Build periodically：
  - 与代码更新的及时性没有直接关联。它按照预定的时间执行构建，可能在代码更新后很久才进行构建，也可能在没有代码更新的情况下频繁构建。例如，设置为每小时构建一次，可能在代码更新后等待长达一个小时才构建，也可能在没有任何新代码的情况下依然每小时构建一次。
资源利用
- Poll SCM：
  - 轮询操作会对Jenkins服务器和代码仓库服务器造成一定的资源消耗。每次轮询都需要向代码仓库服务器发送请求来检查状态，频繁的轮询可能会增加服务器的负载。不过，如果合理设置轮询间隔，可以在保证及时发现代码变化的同时，将资源消耗控制在一定范围内。例如，对于更新不频繁的项目，将轮询间隔设置为较长时间（如每小时一次），可以减少不必要的资源消耗。
- Build periodically：
  - 资源消耗相对比较稳定，因为构建时间是固定的。但如果构建任务本身比较复杂，占用大量资源，且构建频率过高（如每分钟构建一次），可能会导致系统资源紧张。不过，这种资源消耗模式是可预测的，只要根据服务器资源和构建任务的情况合理设置构建频率即可。
适用场景
- Poll SCM：
  - 适用于代码更新频率不确定，但希望在代码更新后尽快触发构建的场景。例如，在开发过程中，开发人员随时可能提交代码，通过Poll SCM可以在合理的时间内发现这些更新并构建。对于持续集成环境，开发团队频繁提交代码进行功能开发和测试时，它可以较好地平衡构建及时性和资源消耗。
- Build periodically：
  - 适用于对构建时间有严格计划要求，不依赖于代码更新的场景。例如，在一些定时任务较多的项目中，需要在每天固定时间进行系统备份、数据同步后的构建，或者在特定时间进行性能测试、生成报告等操作，而不关心代码是否刚刚更新。
案例背景

假设我们有一个电商网站的后端API项目，开发团队需要构建和测试代码，以确保新功能的正确实现和旧功能不受影响。

Poll SCM（轮询源代码管理）
- 触发原理：
  - Jenkins按照设定的时间间隔去检查代码仓库是否有变化。例如，开发团队使用Git来管理代码，将代码存储在一个远程仓库中。在Jenkins中配置了Poll SCM后，Jenkins会定期向Git仓库发送请求，检查是否有新的提交（例如新功能开发、代码修复等）。
- 配置示例：
  - 假设将Poll SCM的轮询时间间隔设置为“*/15 * * * *”，这意味着Jenkins每隔15分钟会检查一次Git仓库。如果在10:00有开发人员提交了新的代码，Jenkins在10:00不会立即发现，而是要等到下一个轮询时间点，也就是10:15去检查时，才会发现代码有更新，进而触发构建任务。
- 适用场景案例：
  - 对于这个电商API项目，如果开发团队的工作节奏相对稳定，代码更新不是特别频繁，比如一天可能会有几次更新，那么Poll SCM就比较合适。例如，在开发新功能阶段，开发人员可能会在上午和下午各提交几次代码。通过设置15 - 30分钟的轮询间隔，Jenkins能够及时发现大部分代码更新并进行构建，同时不会因为过于频繁的检查而给系统带来过大的负担。而且这种方式可以适应开发过程中的不确定性，即使开发人员在非预期时间提交代码，也能在合理的延迟后进行构建。
Build periodically（定时构建）
- 触发原理：
  - 不管代码仓库是否有变化，只要到达设定的时间，Jenkins就会触发构建任务。它是基于一个固定的时间表来执行构建的。
- 配置示例：
  - 对于电商API项目，如果我们将Build periodically配置为“0 0 * * *”（每天午夜零点），那么无论当天代码有没有更新，Jenkins都会在午夜零点启动构建。
- 适用场景案例：
  - 假设电商平台在每天晚上会有一个数据同步的过程，这个过程完成后，API项目的运行环境相对稳定，并且业务对构建及时性要求不是特别高。此时，我们可以设置定时构建在每天数据同步完成后的凌晨1点（“0 1 * * *”）进行。这样可以利用夜间系统资源相对空闲的时间，对整个项目进行构建和测试，生成测试报告用于第二天开发团队查看。这种方式有助于在固定的时间点进行系统的整体检查，确保项目的稳定性，同时不受到代码更新频率的影响。
总结对比
- 对于电商API项目来说，Poll SCM更侧重于及时捕捉代码更新后的构建需求，它的灵活性在于能够根据代码更新的实际频率来调整轮询间隔，以达到平衡构建及时性和系统资源消耗的目的。而Build periodically则更适合用于按照固定计划进行构建的场景，例如在特定时间进行系统的全面检查、测试和部署，不依赖于代码的实时更新情况，更关注于按照预设的时间计划来执行构建任务。