promoted builds 插件通过“打标+手动审批”机制实现单次构建产物跨环境复用，避免重复构建不一致；核心步骤包括安装插件、配置带参数的推广流程（如environment选择）、定义shell/ansible等部署动作，并利用${promoted_build_id}等变量精准引用原始构建，配合权限控制与免密ssh保障安全流转。
用 Jenkins 的 Promoted Builds 插件在 Linux 上实现构建产物跨环境流转，核心是把一次构建结果“打标”后，按需推送到开发、测试、预发、生产等不同环境，避免重复构建带来的不一致风险。关键不在重新打包，而在可控地复用同一份构建产物。
安装与基础配置
登录 Jenkins 管理界面 → “系统管理” → “插件管理” → 在“可选插件”中搜索 Promoted Builds Plugin 并安装（需重启 Jenkins 或按提示热加载）。安装完成后，进入任意 Freestyle 项目配置页，会看到新增的 Promoted Builds 区域。
- 勾选“Enable promotion”开启功能
- 在“Promotion process name”中填写有意义的名称，如
Deploy-to-Env - “Only when manually approved”建议勾选——确保每次环境推进都经过人工确认，尤其对预发和生产环境
- 下方“Parameters”可添加环境选择参数，例如：
ENVIRONMENT类型为Choice Parameter，选项填：dev,test,staging,prod
定义推广行为（Action）
在 Promotion 配置的 Actions 区域，添加构建步骤（和普通 Job 的“构建”步骤操作一致），这些步骤会在你点击“Promote”时执行：
- 使用
Execute shell脚本部署，例如：scp -o StrictHostKeyChecking=no target/app.jar user@${ENVIRONMENT}-server:/opt/app/
注意：这里直接引用了上面定义的${ENVIRONMENT}参数，Jenkins 会自动替换 - 调用 Ansible Playbook：
ansible-playbook -i inventories/${ENVIRONMENT} deploy.yml --extra-vars "build_id=${PROMOTED_BUILD_ID}" - 触发下游 Pipeline Job（推荐用于复杂流程）：
curl -X POST "http://jenkins-url/job/deploy-pipeline/buildWithParameters?token=xxx&ENV=${ENVIRONMENT}&BUILD_NUMBER=${PROMOTED_BUILD_NUMBER}" --user "user:api-token"
所有脚本中可用的关键环境变量包括：${PROMOTED_BUILD_ID}（被推广的原始构建 ID）、${PROMOTED_BUILD_NUMBER}（原始构建编号）、${PROMOTION_NAME}（即上面填的 Deploy-to-Env）。
实际流转操作流程
当一次构建成功后（比如 #123），它不会自动部署任何环境。你需要手动操作：
- 进入该次构建详情页 → 左侧菜单点击 Promote → 选择
Deploy-to-Env流程 - 弹出表单，选择
ENVIRONMENT = dev→ 提交 → 执行 shell 脚本把 jar 推到开发服务器 - 后续若需上测试环境，再对同一构建 #123 执行一次 Promote，选
test→ 脚本自动适配目标主机 - 历史记录可在构建页的 Promotion History 查看，每次推广的时间、操作人、参数、日志都完整保留
安全与权限控制
不同环境应设置不同审批权限：
- 在 Promotion 配置中启用“Restrict promotion to certain users or groups”，绑定 Jenkins 用户组（如
dev-team可推 dev/test，ops-team才能推 staging/prod） - Linux 服务器上建议为各环境部署用户配置免密 SSH（用
ssh-copy-id），但禁止 root 直连；部署目录权限设为750，属主为部署专用用户 - 敏感参数（如 prod 数据库密码）不要写死在脚本里，改用 Jenkins Credentials Binding 插件注入
