刚接手自动化部署的时候，到处找人问jenkins怎么用，当时脑子一团乱，以为是个点开就能自动打包上线的神器，上手才发现好多地方都要一点点填配置，不是光点几下就能完事。最开始是在服务器上直接装的war包版本，没有用docker，启动命令敲错一次，页面就一直打不开，蹲在服务器终端反复试，来回折腾快一下午。
装好之后先进后台，新建一个自由风格的项目，这个类型对新手友好很多，不用一开始就写流水线脚本。源码管理那里填仓库地址，配好凭证，就是仓库的账号密钥，不然拉代码的时候一直报权限失败。当时凭证这块卡了很久，复制私钥的时候多带了换行空格，jenkins识别不到，反复删了重贴，才把代码拉取这一步跑通。
构建环节是自己一点点加的，项目是java后端，就选调用顶层maven目标，clean之后再package。命令不能写得太随意，本地能跑的mvn指令，放到jenkins里面环境不一样，有时候本地有依赖包，服务器环境缺，打包直接中断。那时候没想着先统一环境，每次报错就临时在服务器装包，断断续续跑成一次构建，心里还挺得意。这只是我的个人感受，不是标准答案。
触发方式后面慢慢摸索出来两种，一种是定时轮询代码仓库，隔一段时间去检查有没有新提交；另一种是webhook，代码提交之后仓库主动推消息过来触发构建。定时的好上手，不用去仓库后台额外配置，适合不想改动仓库设置的时候用，就是会有一点延迟。webhook响应更快，但是要保证jenkins的外网地址能被访问，内网环境的话这个方式就很难跑起来，我试过一次内网环境配置webhook，怎么都调不通，最后干脆换回轮询。
构建完成之后，加了后置操作。
把打好的jar包传到目标服务器，再执行脚本停旧服务、启动新包。脚本写得简单粗糙，没有做备份，有一次上线出问题，想回滚，找不到上一个版本的包，只能重新拉旧分支打包，浪费不少时间。后来才反应过来，可以在jenkins里面配置保留构建产物，设置保存最近几次的包，回滚的时候会省心不少。
慢慢用久了，开始接触pipeline流水线，把所有步骤写在Jenkinsfile里面，跟着代码一起提交到仓库。好处是配置跟着项目走，换一台jenkins节点，直接拉文件就能跑，不用再在页面上重新点一遍所有选项。但流水线语法容错很低，少一个引号或者括号，整个任务直接失败，报错信息有时候看得云里雾里，要去日志一行行翻。自由风格适合快速测试，流水线适合长期维护的项目，我现在是小改动用自由风格，正式项目统一走流水线。
还有节点的事情，一开始全部任务都跑在master主节点，后面项目多了，一到构建高峰期页面卡顿，任务排队很久。新增从节点之后，分配不同项目到不同机器，压力分开，体验顺很多。从节点的连接方式选的agent，配置好密钥，授权好工作目录，权限要放开，不然进程没法读写文件。
插件这块别一股脑全装上，最开始看到推荐插件就勾选，装完jenkins启动变得很慢，还出现插件版本冲突，部分页面功能直接失效。后面只装刚需的，git、maven、ssh这些够用就行，多余的插件不去碰，稳定度会高不少。
日常维护也不能忽略，定时备份jenkins的工作目录，配置、凭证、任务定义全都存在这里，服务器一旦出状况，有备份才能快速恢复。版本更新的时候也不会急着更，先找个测试环境跑一遍新版本，确认现有任务不受影响，再动线上的实例。
很多人上手会追求一步到位，直接上复杂流水线、多环境自动发布，我走的路子是一点点叠加能力，先做到能拉代码、能打包，再加上传部署，最后再去优化触发和回滚逻辑，步子放小一点，不容易被一堆报错压得不想继续调。