jenkins pipeline 复杂的发布流程

1.参数化构建界面

2.交付流水线界面

3.脚本详解

#!groovy
pipeline {
    //在任何可用的代理上执行Pipeline
    agent any
    //参数化变量,目前只支持[booleanParam, choice, credentials, file, text, password, run, string]这几种参数类型,其他高级参数化类型还需等待社区支持。
    parameters {
    //git代码路径【参数值对外隐藏】
    string(name:‘repoUrl‘, defaultValue: ‘[email protected]*****.com:*****/*****.git‘, description: ‘git代码路径‘)
    //repoBranch参数后续替换成git parameter不再依赖手工输入,JENKINS-46451【git parameters目前还不支持pipeline】
    string(name:‘repoBranch‘, defaultValue: ‘master‘, description: ‘git分支名称‘)
    //pom.xml的相对路径
    string(name:‘pomPath‘, defaultValue: ‘pom.xml‘, description: ‘pom.xml的相对路径‘)
    //war包的相对路径
    string(name:‘warLocation‘, defaultValue: ‘rpc/war/target/*.war‘, description: ‘war包的相对路径 ‘)
    //服务器参数采用了组合方式,避免多次选择,使用docker为更佳实践【参数值对外隐藏】
    choice(name: ‘server‘,choices:‘192.168.1.107,9090,*****,*****\n192.168.1.60,9090,*****,*****‘, description: ‘测试服务器列表选择(IP,JettyPort,Name,Passwd)‘)
    //测试服务器的dubbo服务端口
    string(name:‘dubboPort‘, defaultValue: ‘31100‘, description: ‘测试服务器的dubbo服务端口‘)
    //单元测试代码覆盖率要求,各项目视要求调整参数
    string(name:‘lineCoverage‘, defaultValue: ‘20‘, description: ‘单元测试代码覆盖率要求(%),小于此值pipeline将会失败!‘)
    //若勾选在pipelie完成后会邮件通知测试人员进行验收
    booleanParam(name: ‘isCommitQA‘,description: ‘是否邮件通知测试人员进行人工验收‘,defaultValue: false )
    }
    //环境变量,初始确定后一般不需更改
    tools {
        maven ‘maven3‘
        jdk   ‘jdk8‘
    }
    //常量参数,初始确定后一般不需更改
    environment{
        //git服务全系统只读账号cred_id【参数值对外隐藏】
        CRED_ID=‘*****-****-****-****-*********‘
        //测试人员邮箱地址【参数值对外隐藏】
        QA_EMAIL=‘*****@*****.com‘
        //接口测试(网络层)的job名,一般由测试人员编写
        ITEST_JOBNAME=‘Guahao_InterfaceTest_ExpertPatient‘
    }
    options {
        //保持构建的最大个数
        buildDiscarder(logRotator(numToKeepStr: ‘10‘))
    }
    //定期检查开发代码更新,工作日每晚4点做daily build
    triggers {
        pollSCM(‘H 4 * * 1-5‘)
    }
   //pipeline运行结果通知给触发者
    post{
        success{
            script {
                wrap([$class: ‘BuildUser‘]) {
                mail to: "${BUILD_USER_EMAIL }",
                subject: "PineLine ‘${JOB_NAME}‘ (${BUILD_NUMBER}) result",
                body: "${BUILD_USER}‘s pineline ‘${JOB_NAME}‘ (${BUILD_NUMBER}) run success\n请及时前往${env.BUILD_URL}进行查看"
                }
            }
        }
        failure{
            script {
                wrap([$class: ‘BuildUser‘]) {
                mail to: "${BUILD_USER_EMAIL }",
                subject: "PineLine ‘${JOB_NAME}‘ (${BUILD_NUMBER}) result",
                body: "${BUILD_USER}‘s pineline  ‘${JOB_NAME}‘ (${BUILD_NUMBER}) run failure\n请及时前往${env.BUILD_URL}进行查看"
                }
            }

        }
        unstable{
            script {
                wrap([$class: ‘BuildUser‘]) {
                mail to: "${BUILD_USER_EMAIL }",
                subject: "PineLine ‘${JOB_NAME}‘ (${BUILD_NUMBER})结果",
                body: "${BUILD_USER}‘s pineline ‘${JOB_NAME}‘ (${BUILD_NUMBER}) run unstable\n请及时前往${env.BUILD_URL}进行查看"
                }
            }
        }
    }

    //pipeline的各个阶段场景
    stages {
        stage(‘代码获取‘) {
            steps {
            //根据param.server分割获取参数,包括IP,jettyPort,username,password
            script {
                def split=params.server.split(",")
                serverIP=split[0]
                jettyPort=split[1]
                serverName=split[2]
                serverPasswd=split[3]
            }
              echo "starting fetchCode from ${params.repoUrl}......"
              // Get some code from a GitHub repository
              git credentialsId:CRED_ID, url:params.repoUrl, branch:params.repoBranch
            }
        }
        stage(‘单元测试‘) {
            steps {
              echo "starting unitTest......"
              //注入jacoco插件配置,clean test执行单元测试代码. All tests should pass.
              sh "mvn org.jacoco:jacoco-maven-plugin:prepare-agent -f ${params.pomPath} clean test -Dautoconfig.skip=true -Dmaven.test.skip=false -Dmaven.test.failure.ignore=true"
              junit ‘**/target/surefire-reports/*.xml‘
              //配置单元测试覆盖率要求,未达到要求pipeline将会fail,code coverage.LineCoverage>20%.
              jacoco changeBuildStatus: true, maximumLineCoverage:"${params.lineCoverage}"
            }
        }
        stage(‘静态检查‘) {
            steps {
                echo "starting codeAnalyze with SonarQube......"
                //sonar:sonar.QualityGate should pass
                withSonarQubeEnv(‘SonarQube‘) {
                  //固定使用项目根目录${basedir}下的pom.xml进行代码检查
                  sh "mvn -f pom.xml clean compile sonar:sonar"
                }
                script {
                timeout(10) {
                    //利用sonar webhook功能通知pipeline代码检测结果,未通过质量阈,pipeline将会fail
                    def qg = waitForQualityGate()
                        if (qg.status != ‘OK‘) {
                            error "未通过Sonarqube的代码质量阈检查,请及时修改!failure: ${qg.status}"
                        }
                    }
                }
            }
        }

        stage(‘部署测试环境‘) {
            steps {
                echo "starting deploy to ${serverIP}......"
                //编译和打包
                sh "mvn  -f ${params.pomPath} clean package -Dautoconfig.skip=true -Dmaven.test.skip=true"
                archiveArtifacts warLocation
                script {
                    wrap([$class: ‘BuildUser‘]) {
                    //发布war包到指定服务器,虚拟机文件目录通过shell脚本初始化建立,所以目录是固定的
                    sh "sshpass -p ${serverPasswd} scp ${params.warLocation} ${serverName}@${serverIP}:htdocs/war"
                    //这里增加了一个小功能,在服务器上记录了基本部署信息,方便多人使用一套环境时问题排查,storge in {WORKSPACE}/deploy.log  & remoteServer:htdocs/war
                    Date date = new Date()
                    def deploylog="${date.toString()},${BUILD_USER} use pipeline  ‘${JOB_NAME}(${BUILD_NUMBER})‘ deploy branch ${params.repoBranch} to server ${serverIP}"
                    println deploylog
                    sh "echo ${deploylog} >>${WORKSPACE}/deploy.log"
                    sh "sshpass -p ${serverPasswd} scp ${WORKSPACE}/deploy.log ${serverName}@${serverIP}:htdocs/war"
                    //jetty restart,重启jetty
                    sh "sshpass -p ${serverPasswd} ssh ${serverName}@${serverIP} ‘bin/jettyrestart.sh‘ "
                    }
                }
            }
        }

      stage(‘接口自动化测试‘) {
            steps{
                echo "starting interfaceTest......"
                script {
                 //为确保jetty启动完成,加了一个判断,确保jetty服务器启动可以访问后再执行接口层测试。
                 timeout(5) {
                     waitUntil {
                        try {
                            //确保jetty服务的端口启动成功
                            sh "nc -z ${serverIP} ${jettyPort}"
                            //sh "wget -q http://${serverIP}:${jettyPort} -O /dev/null"
                            return true
                        } catch (exception) {
                            return false
                            }
                        }
                    }
                //将参数IP和Port传入到接口测试的job,需要确保接口测试的job参数可注入
                 build job: ITEST_JOBNAME, parameters: [string(name: "dubbourl", value: "${serverIP}:${params.dubboPort}")]
                }
            }
        }

        stage(‘UI自动化测试‘) {
             steps{
             echo "starting UITest......"
             //这个项目不需要UI层测试,UI自动化与接口测试的pipeline脚本类似
             }
         }

        stage(‘性能自动化测试 ‘) {
            steps{
                 echo "starting performanceTest......"
                //视项目需要增加性能的冒烟测试,具体实现后续专文阐述
                }
        }

        stage(‘通知人工验收‘){
            steps{
                script{
                    wrap([$class: ‘BuildUser‘]) {
                    if(params.isCommitQA==false){
                        echo "不需要通知测试人员人工验收"
                    }else{
                        //邮件通知测试人员人工验收
                         mail to: "${QA_EMAIL}",
                         subject: "PineLine ‘${JOB_NAME}‘ (${BUILD_NUMBER})人工验收通知",
                         body: "${BUILD_USER}提交的PineLine ‘${JOB_NAME}‘ (${BUILD_NUMBER})进入人工验收环节\n请及时前往${env.BUILD_URL}进行测试验收"
                    }

                    }
                }
            }
        }

        // stage(‘发布系统‘) {
        //     steps{
        //         echo "starting deploy......"
        //     //    TODO发布环节后续专题阐述
        //     }
        // }
    }
}

原文地址:https://www.cnblogs.com/lvcisco/p/12067945.html

时间: 2024-08-10 17:01:41

jenkins pipeline 复杂的发布流程的相关文章

使用Jenkins Pipeline自动化构建发布Java项目

简介 Pipeline,简而言之,就是一套运行于Jenkins上的工作流框架,将原本独立运行于单个或者多个节点的任务连接起来,实现单个任务难以完成的复杂流程编排与可视化. Pipeline是Jenkins2.X的最核心的特性,帮助Jenkins实现从CI到CD与DevOps的转变. 一,创建pipeline项目 二,清除部分历史构建 三,参数化构建 这里使用三个参数,分别对应是否拉取代码,项目名称,以及发版选项 四,编写pipeline脚本 选择pipeline script编写pipeline

Jenkins CICD代码构建发布流程

一.发布环境 发布脚本 #!/bin/bash #node group1="172.16.8.11 172.16.8.12" group2="172.16.8.13 172.16.8.14" #deloy tomcat1_dir=/app/tomcat1 tomcat2_dir=/app/tomcat2 tomcat3_dir=/app/tomcat3 tomcat4_dir=/app/tomcat4 #BACKUP backup_dir1=/app/backup1

(转)Jenkins2.0 Pipeline 插件执行持续集成发布流程

1.Jenkins 2.0 的精髓是 Pipeline as Code Jenkins 2.0 的精髓是 Pipeline as Code,是帮助 Jenkins 实现 CI 到 CD 转变的重要角色.Pipeline是一套运行于 Jenkins 上的工作流框架,将原本独立运行于单个或者多个节点的任务连接起来,实现单个任务难以完成的复杂发布流程.Pipeline 中任何发布流程都可以表述为一段 Groovy 脚本,并且 Jenkins 支持从代码库直接读取脚本. ----------------

Docker的Jenkins Pipeline工作流

原文地址:http://www.youruncloud.com/blog/127.html 分享主题 一个软件产品的开发周期中,尤其是敏捷开发,持续集成和持续部署是必不可少的环节,而随着产品的丰富,模块的增多.随即带来了更加多的问题,各模块间编译环境的准备,编译复杂,耗时增加,还需要专人去负责这个流程.而Jenkins则可以很好的解决这个单一而容易出错的CI(持续集成)工作. Jenkins也存在着编译环境不隔离的问题,虽然可以通过集群的方式解决,可是需要为每种环境甚至是一种语言的不同版本准备多

jenkins + pipeline构建自动化部署

一.引言 Jenkins 2.x的精髓是Pipeline as Code,那为什么要用Pipeline呢?jenkins1.0也能实现自动化构建,但Pipeline能够将以前project中的配置信息以steps的方式放在一个脚本里,将原本独立运行于单个或者多个节点的任务连接起来,实现单个任务难以完成的复杂流程,形成流水式发布,构建步骤视图化.简单来说,Pipeline适用的场景更广泛,能胜任更复杂的发布流程.举个例子,job构建工作在master节点,自动化测试脚本在slave节点,这时候je

基于 Jenkins+Docker+Git 的CI流程初探

在如今的互联网时代,随着软件开发复杂度的不断提高,软件开发和发布管理也越来越重要.目前已经形成一套标准的流程,最重要的组成部分就是持续集成(Continuous Integration,CI)及持续部署.交付(CD).在此,我们来以一个案例初步了解 CI 流程.那么什么是 CI 呢?简单来讲,CI 就是将传统的代码合并.构建.部署.测试都集成在一起,不断地执行这个过程,并对结果进行反馈. CI 流程设计图: 工作流程: 1. 开发人员提交代码到Git版本仓库:2. Jenkins人工/定时触发项

基于Jenkins Pipeline的ASP.NET Core持续集成实践

原文:基于Jenkins Pipeline的ASP.NET Core持续集成实践 最近在公司实践持续集成,使用到了Jenkins的Pipeline来提高团队基于ASP.NET Core API服务的集成与部署,因此这里总结一下. 一.关于持续集成与Jenkins Pipeline 1.1 持续集成相关概念 互联网软件的开发和发布,已经形成了一套标准流程,最重要的组成部分就是持续集成(Continuous integration,简称 CI) . 持续集成指的是,频繁地 (一天多次) 将代码集成到

基于Jenkins的开发测试全流程持续集成实践

今年一直在公司实践CI,本文将近半年来的一些实践总结一下,可能不太完善或优美,但的确初步解决了我目前所在项目组的一些痛点.当然这仅是一家之言也不够完整,后续还会深入实践和引入Kubernetes进行容器编排,以及通过阿里云K8S服务进行高效的云上托管,希望对各位童鞋有一点用. 一.持续集成全流程介绍 今年一直在开发我司的一个核心业务系统,一个还未上线的产品开发阶段,其中后端采用ASP.NET Core + 一系列开源组件开发微服务并且部署在Linux Docker中,前端采用React + Fl

基于Jenkins的持续交付全流程设计与实践

1 从理论开始 什么是DevOps? 近年来,随着DevOps理念的逐渐深入人心,企业逐渐意识到从看似重复的手工劳动中实现自动化流程处理,对于提高企业劳动生产力已经非常重要,尤其是面向互联网的开发者,往往每次上线时,最大的挑战并非需求的走查或测试和改bug,而是由于发布的流程不够规范,将成果发布到目标环境后可能造成的配置错误或引发其他已知未知问题所造成的额外工作量,使得生产环境的发布流程总会存在不顺利. 而DevOps则致力于统一整合软件开发和软件运维,其特点是强烈倡导对构建软件的所有环节(从集