CI/CD流水线Jenkins配置 | 制品管理

▌ 技术引导
我用Jenkins搞过多个项目的CI/CD流水线，最核心的配置逻辑是围绕制品管理展开的，所以直接告诉你：制品管理是Jenkins流水线的灵魂，控制不好整个构建系统就会失控。
我见过别人用Jenkins的默认制品存储机制，结果每次构建都把旧版本的jar包或docker镜像堆在服务器里，最终导致磁盘爆掉，还影响构建速度。
Jenkins的制品管理可以通过配置构建后动作实现，关键点是制品存储路径、版本控制策略、清理规则以及触发条件。
具体来说，我有用`archiveArtifacts`插件来管理制品，配合`publishHTML`和`docker`构建步骤，把不同阶段的输出打包分类，确保每次部署只保留最新版本。
如果你不主动清理旧制品，系统会逐渐变成一个垃圾场，构建速度下降，资源浪费严重。我是用`cleanWs`加上自定义脚本做了保留策略，比如只保留最近3个版本。

▌ 技术参考

一 用Jenkins实现制品管理需要先确定存储策略
在Jenkins中配置制品管理首先要定义好存储路径，比如`/var/jenkins_home/workspace/your-job-name/target/`，然后设置哪些文件需要保留、哪些需要清理。我通常用`archiveArtifacts`来打包制品，这样就能在构建完成后自动归档。配置项包括`artifacts`路径、`allowEmptyArchive`和`fingerprint`这些参数，前者是制品存储位置，后者是是否允许空目录归档。如果你用maven，那么默认构建后会把`target`目录生成一个jar包，这时候需要在Jenkinsfile中添加`archiveArtifacts 'target/.jar'`来确保制品被正确归档。

二 配置Jenkins制品管理需要写入具体步骤
一个典型的Jenkins制品管理流程是：构建完成后自动归档，然后根据版本号清理旧制品。我直接在Jenkinsfile的`post`阶段配置，比如`post { success { archiveArtifacts 'target/.jar' } }`，这样不管构建结果如何，都能保留所需制品。如果你用docker构建，可以在`docker.build`之后添加`archiveArtifacts 'docker/images/.tar'`。不过要注意，归档路径的写法不能有通配符，否则会报错。另外，Jenkins默认会保留所有构建的制品，但你可以用`keepDependencies false`来避免此行为。

三 常见踩坑场景包括制品误删和存储路径混乱
我踩过最大的坑是误用了`cleanWs`和`delete`步骤，导致一些关键制品被删掉，后续部署时才发现版本不对。还有个问题是存储路径写错了，比如`target/your-artifact`实际是`target/your-artifact-1.0.0.jar`，结果归档失败，或者只归档了部分内容。解决方案是用`echo`打印出实际路径，确认是否匹配，同时在`post`阶段使用`sh 'ls -la target/'`来检查制品是否生成。另一个问题是多个项目共用一个制品存储目录，这时候需要在配置中设置`artifactsLocation`为单独的路径，避免相互干扰。

四 制品管理对构建效率和资源消耗有直接影响
Jenkins的制品管理如果不做清理，会导致磁盘空间迅速膨胀，尤其是docker镜像这类大体积文件。我测试过一个项目，如果不清理，存储占用会每天增长500MB，最终导致构建失败。使用`archiveArtifacts`配合`cleanWs`可以控制存储空间，但需要设定合理的保留策略，比如只保留最近3个版本，用`keepBuilds 3`来控制。另外，我见过有人用`docker system prune`来清理docker缓存，这样可以减少存储压力，不过执行时要小心，别把依赖删没了。

五 Jenkins制品管理适合微服务和持续部署场景
这种配置方式特别适合微服务架构，每个服务都有独立的构建和部署流程，制品管理可以确保每次构建部署的版本可控。我见过一个电商系统，用Jenkins做制品管理，把每个模块的jar包和docker镜像分别归档，再通过`publishHTML`生成部署报告。这样运维人员可以直接查看每个模块的版本信息，不会出现混乱。但如果是单体应用，可能不需要这么精细的管理，不过依然建议保留制品路径，方便回滚。

六 使用`docker`插件时配置制品需要特别注意
我之前用Jenkins的docker插件构建镜像，结果发现既没有归档又没有清理，导致镜像堆积，系统卡顿。配置时要记得在`docker.build`步骤后添加`archiveArtifacts`，参数是`docker/images/.tar`。同时，要配置`docker.systemPrune true`，这样每次构建后都会自动清理旧镜像。不过这个参数在某些版本可能不支持，需要手动执行`docker system prune -a`。我还在`post`阶段写了一个shell脚本，比如`sh 'docker system prune -a --volumes'`，这样能彻底清理历史镜像，减少存储负担。

七 某些情况下需要手动指定制品路径和版本
如果你的项目结构比较复杂，或者制品生成路径不固定，直接用`archiveArtifacts`可能会失效。比如，有些项目会把制品放在`build/`目录下，而不是默认的`target/`，这时候需要在配置中手动指定`artifacts`路径。我遇到过一个Spring Boot项目，每次构建后生成的jar包位置都不统一，是用`sh 'find build/ -name .jar'`来确定路径，然后在Jenkinsfile中动态写入。这样虽然麻烦，但能确保制品被正确归档。

八 Jenkins的制品管理可以与版本控制系统联动
我用过git的tag来控制制品版本，每次构建完成后，如果没有tag就自动打上版本号，或者用构建编号代替。这样做的好处是能快速定位到哪个构建对应哪个制品。配置时可以结合`script`块，比如`script { sh "git tag -a v${params.VERSION} -m 'Build ${env.BUILD_ID}'" }`。同时，如果有多个分支，比如`dev`和`prod`，需要分别配置不同的制品路径，避免冲突。

九 有些场景需要结合`Jenkinsfile`和`Pipeline`来管理制品
我的项目中用`Jenkinsfile`来定义整个构建流程，每次构建都会生成制品，然后根据版本号归档。比如在`stage('Build')`中生成jar包，再在`stage('Archive')`里调用`archiveArtifacts`。这样做的好处是逻辑清晰，但需要注意`Jenkinsfile`的语法错误，否则会导致归档失败。我还用过`Jenkins Pipeline`的`post`阶段，配合`sh 'ls target/'`去检查制品是否存在，避免因为路径错误导致构建失败。

十 Jenkins的制品管理可以与`SonarQube`和`Jira`结合使用
我在构建后会用`SonarQube`做质量检测，这时候需要把制品和检测结果关联起来。配置方式是在`Jenkins`中添加`publishSonar`插件，然后设置`sonar.login`和`sonar.projectKey`这些参数。同时，我还会把构建日志和制品信息上传到`Jira`，用`Jenkins`的`Jira`插件来做问题追踪。这样做的好处是能快速定位到某个构建对应的问题和制品，但对于不是用这些工具的项目，可能需要额外的配置。

十一 制品管理需要注意权限和安全性问题
我见过有些项目因为权限问题导致制品无法归档，特别是用`SSH`连接远程服务器时，需要确保`Jenkins`有写权限。配置时要检查`workspace`目录的权限，或者用`sh 'chmod -R 755 /var/jenkins_home/workspace/your-job-name/'`来修改。另外，如果制品包含敏感信息，比如数据库密码，要避免直接保存在制品中，而是用环境变量或者配置文件的方式处理。我之前用`Jenkins`构建时误把数据库配置文件归档，后来发现每次部署都会暴露密码，最后改用加密参数来解决。

十二 使用`Jenkins`的制品管理可以提升版本追溯能力
我的项目中，每次构建后都会在`Jenkins`历史中记录制品位置和版本号。这样在后续部署出问题时，能快速回滚到某个版本的制品。配置时可以使用`fingerprint`来标记关键制品，比如`fingerprint 'target/.jar'`。这样不仅能关联制品，还能在部署报告中显示使用的是哪个版本的jar包。不过要注意的是，`fingerprint`功能需要在`Jenkins`中启用，否则会报错，或者无法记录版本。

十三 制品清理策略要根据项目复杂度动态调整
对于简单的项目，我用`keepBuilds 1`来只保留最新版本，但如果是复杂的微服务项目，可能需要保留多个版本以便测试。我一般用`sh 'ls -t target/ | head -n 3'`来保留最新的3个版本，然后执行`sh 'rm -rf target/'`来清理旧版本。不过脚本要小心写，避免误删。另外，有些项目会在构建时生成多个制品，这时候需要分别设置清理规则，比如docker镜像和jar包分开处理。

十四 Jenkins的制品管理可以结合`agent`和`publish`插件优化
我之前在构建时遇到过网络不稳定的问题，导致制品上传失败。后来用`publish`插件配合`Jenkins`的`slave`节点，把制品先发布到本地，再由`master`节点统一归档。这样做的好处是减少网络延迟，提高稳定性。配置时，可以在`Jenkinsfile`中指定`agent any`，然后在`post`阶段使用`publish`插件上传。不过要注意`publish`插件的版本兼容性，否则可能无法使用。

十五 有些项目需要定制化制品管理逻辑
我用过一个项目，制品包含多个不同环境的配置文件，比如`dev`, `test`, `prod`，这时候需要在构建时根据环境变量决定归档哪些文件。例如`if (env.BRANCH_NAME == 'prod') { archiveArtifacts 'target/prod/.jar' }`。这样能确保生产环境只保留最终版本，测试环境保留多个版本。同时，我还在`Jenkins`中用`script`写了一个函数，统一切换路径，比如`def archiveByEnv() { ... }`，这样能减少重复代码。不过要注意函数的命名和返回值，避免出错。