詹金斯有哪些核心功能？ DevOps工程师必看！

说起詹金斯这玩意儿，我可太有发言权了。最早的时候，我们团队发东西，那叫一个原始。代码打包全靠手动，然后用FTP或者SCP啥的，一个个往服务器上扔。配置文件？手动改！服务重启？手动敲命令！每次上线前，那都得提前半小时开始准备，还得祈祷别出岔子，不然就得加班加点地回滚、排查，简直是噩梦。

最初的尝试与阵痛

后来有一次，听别的团队说有个叫詹金斯的东西，能自动化这些破事儿。我当时就心动了，想着这玩意儿要是真能解决问题，那可真是解放生产力。于是我就开始折腾起来了。

第一步，安装。 我记得当时是在一台闲置的Linux虚拟机上搞的。去官网找了个最新的war包，然后装了个Tomcat，把war包往webapps目录下一扔，启动Tomcat，詹金斯就跑起来了。访问那个IP加端口，看到詹金斯的界面，心里还有点小激动。

第二步，初始化配置。 刚进去的时候，它会让你输个初始密码，那密码藏在一个贼隐蔽的文件里，我找了半天。然后就是装推荐插件，当时也没多想，就点了那个推荐安装，哗装了一堆。后来才发现，有些根本用不上，还占资源。

第三步，创建第一个任务。 这才是重头戏。我先试着搞了个最简单的，就是从我们的Git仓库拉代码。在新建任务里，选了个“自由风格软件项目”。然后在“源码管理”那块，选了Git，填上我们项目的仓库地址，还有访问凭证（我一开始用的是用户名密码，后来才改成SSH密钥，安全点）。点一下“立即构建”，看着控制台输出刷刷地过，提示成功，代码确实拉下来了。成了！

一步步走向自动化

拉代码只是第一步，我寻思着得把编译、打包也加上。我们当时用的是Maven，所以在“构建”那一步，我加了个“执行shell”的步骤，里面就写了条命令：mvn clean package *=true。再构建一次，果然，target目录下打出来一个jar包或者war包。

接下来就是部署了。 这块儿我研究了好久。最开始我想的还是用shell脚本，通过scp把包传到目标服务器，然后再ssh上去执行启动脚本。后来发现詹金斯有个叫“Publish Over SSH”的插件，这玩意儿简直是神器！装上之后，在系统管理里配置好目标服务器的SSH信息，比如IP、用户名、密码或者私钥路径。

然后在我的任务配置里，“构建后操作”加一个“Send build artifacts over SSH”。这里面就能选之前配好的服务器，指定要传输的文件（比如target/.jar），指定远程服务器的目录，还能在传输完成后执行命令，比如停掉老服务，启动新服务。这一套配下来，再点构建，眼睁睁看着它自动拉代码、打包、传包、重启服务，整个过程行云流水，我当时就觉得，这玩意儿太香了！

后来我们又做了些优化：

• 参数化构建： 比如要部署到不同的环境（开发、测试、生产），或者要部署不同的分支，总不能为每个都建个任务？于是就用了参数化构建，在启动构建前可以选择分支、选择环境。
• 定时构建： 有些任务，比如每天凌晨打包个开发版，就用了定时构建，跟Crontab表达式差不多。
• 代码提交触发构建： 这个更高级了，配个Webhook，开发人员一提交代码到特定分支，詹金斯就自动开始构建部署，实现了真正的持续集成。

从自由风格到Pipeline

项目多了，任务也多了，自由风格那种点点点的配置方式，管理起来就有点麻烦了，而且不好追溯变更。这时候，我又接触到了Pipeline，也就是流水线。这玩意儿是用代码（一种叫Groovy的脚本，写在Jenkinsfile里）来定义整个构建部署流程的。

刚开始学写Jenkinsfile，那叫一个头大。 语法不熟，各种DSL方法也记不住，经常写错。不过詹金斯界面上有个“Pipeline Syntax”的功能，能帮你生成一些常用操作的代码片段，对着抄抄改改，慢慢也就上手了。

把之前的自由风格任务改成Pipeline之后，感觉整个流程更清晰了。一个Jenkinsfile文件跟着代码仓库走，谁改了什么，一看就知道。而且Pipeline支持更复杂的逻辑，比如并行执行、条件判断、人工确认步骤啥的，可玩性高多了。

比如我们一个典型的Pipeline大概是这样的：

1. 拉取代码（Checkout）
2. 编译打包（Build）
3. 单元测试（Test，如果不过就中断）
4. 构建Docker镜像（Build Image）
5. 推送镜像到仓库（Push Image）



6. 部署到测试环境（Deploy to Test）
7. （可选）人工确认是否部署到生产（Input Step）
8. 部署到生产环境（Deploy to Prod）

这些阶段都清清楚楚地写在Jenkinsfile里，哪个阶段出错了，在詹金斯的界面上也能一目了然地看到，排查起来方便多了。

踩过的一些坑和感悟

用詹金斯也不是一帆风顺的。也踩了不少坑：

• 插件管理： 插件装多了，有时候会有冲突，或者升级詹金斯版本后，老插件不兼容了，导致构建失败。所以插件不是越多越够用就行。
• 资源消耗： 詹金斯本身，尤其是跑多个任务的时候，还是挺吃内存和CPU的。服务器配置不能太差。
• 构建历史： 默认构建历史会一直保存，时间长了磁盘空间就不够了。后来我们都配置了丢弃旧的构建记录，比如只保留最近10次或者最近7天的。
• 权限管理： 刚开始图省事，没怎么配权限，谁都能操作所有任务。后来团队大了，就必须得用基于角色的权限管理插件，不同的人给不同的权限，防止误操作。



• 日志： 有时候构建失败，看控制台输出的日志，那叫一个长。得耐心点，从下往上找错误信息。

詹金斯这玩意儿，虽然初上手有点学习曲线，配置起来也需要点耐心，但一旦用顺了，带来的效率提升和流程规范化，那是实实在在的。 它把我们从繁琐、重复、易错的手动部署中解放出来，让我们能更专注于写代码和做更有价值的事情。现在我们团队要是没了詹金斯，估计大家都要抓狂了。如果你还在手动部署，真心建议试试詹金斯，绝对物有所值！