Jenkins如何配置实现同一份代码部署到可指定的不同服务器

核心逻辑就是把原来绑死分支的部署规则改成参数驱动，把部署逻辑从业务代码侧挪到Jenkins侧，全程不需要改任何业务代码，原有流水线的构建、回溯、权限、回滚能力全部能保留。

第一步：把流水线改成参数化构建，彻底去掉分支匹配逻辑 #

• 所有流水线任务默认拉取唯一的master分支代码，删掉所有按分支名判断目标服务器的旧逻辑。
• 在Jenkins任务配置里开启参数化构建，加一个目标部署环境的下拉选项，把所有需要部署的服务器/环境都列进去，比如dev测试集群、staging预发机、prod线上节点1/2/3，每个选项提前在Jenkins全局凭据、全局变量里绑定好对应的SSH地址、登录凭据、部署路径，不要把敏感信息硬编码在脚本里。
• 可选加两个实用参数：一个是「跳过构建步骤」的布尔开关，需要把同一份构建包部署到多个环境的时候不用重复编译打包；另一个是「历史构建版本」下拉，选之前归档好的产物直接部署，实现快速回滚。

第二步：抽离部署逻辑，实现和业务代码完全解耦 #

原来的部署逻辑如果写在代码仓库的Jenkinsfile里，按下面的方式拆分，业务代码零侵入：

• 业务代码仓库里的Jenkinsfile只保留和代码强相关的通用步骤：拉取master代码、执行项目原有的构建命令（比如mvn package/npm run build）、归档构建产物，不要加任何和环境、服务器相关的判断逻辑。
• 所有和部署相关的逻辑：包括根据参数匹配目标服务器、传输构建包、执行远程服务重启脚本、部署后健康检查，全部挪到Jenkins全局共享库（Shared Library）里存着。后续要加服务器、改部署流程，只需要运维在Jenkins侧改共享库代码，不需要提交MR到业务仓库，开发完全无感知。
  代码仓里的Jenkinsfile可以简化成下面这样，除了构建命令和你原来的保持一致，其他逻辑都不用管：

// 引用Jenkins侧存的全局部署共享库
@Library('internal-deploy-lib') _
pipeline {
  agent any
  stages {
    stage('拉取Master分支代码') {
      steps {
        git branch: 'master', url: '你的业务代码仓地址'
      }
    }
    stage('项目构建') {
      steps {
        // 这里完全沿用你项目原来的构建命令，不需要做任何改动
        sh 'mvn clean package -DskipTests'
        archiveArtifacts artifacts: 'target/*.jar', fingerprint: true
      }
    }
    stage('部署到指定目标') {
      steps {
        // 直接调用共享库封装好的部署方法，传入用户选择的环境参数即可
        deployByEnv(targetEnv: params.DEPLOY_TARGET)
      }
    }
  }
}

• 如果你连代码仓里的Jenkinsfile都不想碰，直接把整个流水线脚本写在Jenkins服务端的任务配置里就行，构建的时候拉取master代码后直接执行服务端存的逻辑，业务代码仓完全不需要做任何提交修改。

第三步：保留原有流水线全能力 #

改完之后原来的流水线能力不会有任何损失，还能更灵活：

• 构建回溯：每次构建的记录里会明确记录部署的目标环境、对应的代码commit版本、使用的构建产物，和之前按分支部署的追溯体验完全一致。
• 权限管控：搭配Jenkins角色权限插件，可以给不同成员分配不同环境的部署权限，比如普通开发只能部署测试环境，运维才能操作生产环境，避免误操作。
• 自动触发：如果需要保留合并代码后自动部署测试环境、定时部署预发的能力，直接在触发器里配置对应参数的默认值就行，比如代码合并到master触发构建时，默认把部署目标设为测试环境，不需要额外写逻辑。
• 回滚能力：之前分支模式下回滚需要切旧分支重新构建，现在直接选历史归档的稳定版本，选目标环境点构建就能完成回滚，速度更快。

内容的提问来源于stack exchange，提问作者malviska