实际项目中使用 jenkins 的多吗？

Question

最近部门有需求打算把jenkins持续集成应用起来。

所以查阅了一些资料，把jenkins环境搭建起来，跑了一下简单的小流程：源码拉取、maven编译打包、（后续可能会制作为docker镜像 -> 选择性将镜像推到docker私服 -> 搭建模拟运行环境）

但其实我有一些困惑，主要是感觉 jenkins 是一个可有可无的存在。

jenkins主要是为了解决“谁的”、“什么问题”呢？
有多少项目是实际在用的？

欢迎分享下经验，谢谢

Answer 1

• 自动化构建和部署,开发者本身只需要关注项目功能是否实现就可以，但实际上还需要关注项目部署问题，它本身就是一个比较繁琐和重复的过程。
  同时部署也会出现很多问题，包括环境配置、部署失败、部署失败的错误如何上报、部署环境如何隔离、部署失败后如何通知到相关开发者、项目代码更新后单元测试如何触发运行等，这些问题在 jekins 上都有比较规范的解决方案，这样做目的就是 CI,CD，CI 保证代码的稳定性，CD 保证项目的下游人员 （测试运营）可以及时获取到项目最新的部署版本。
• 可视化和监控，jekins 跟 action 都有对开发友好的视图去展示部署状态，没有这些工具，开发人员只能通过终端，以及 linux 命令去获取服务状态。

Answer 2

持续集成，持续部署。在发布前配置好发布脚本，避免一些人为部署可能出现的操作失误

Answer 3

Jenkins 主要给开发团队、测试团队、运维团队等技术团队用，用来自动化构建、自动化测试、持续交付/部署、监控，主要是大的公司和团队在用，小公司可能会过剩，有很多用不上。

Answer 4

如果你感觉jenkins是一个可有可无的存在，那么确实代表你的团队很小，不是嘲讽哈。

团队规模大了以后，或者走敏捷开发的路子（一周至少一版），或者团队要求高质量。都需要Jenkins等类似的CI持续集成、CD持续部署的工具配合，用来替代的重复的操作。

就拿最简单的发版来说：

1. 发布版本检查清单
2. 版本号变更
3. 数据迁移
4. 集群部署
5. 部署结果确认，失败进行回退操作。

每一步都是人来操作的话，人是会失误的，例如遗漏掉第3步，导致线上数据库与代码不一致直接服务崩溃，例如遗漏掉第5步没有确认部署结果导致集群多个版本并存而发生请求异常。每一次部署都要胆颤心惊的，需要自动化协助处理，只需要在第一步确认好清单就行。

还有例如代码提交的预审核（敏感信息、单元测试）、代码圈复杂度量检测、Docker编译、集成测试等。

完善的CI\CD工具是保障技术团队健康发展的重中之重。