基于GitLab+Jenkins的DevOps赋能实践

共计 4635 个字符，预计需要花费 12 分钟才能阅读完成。

    随着微服务、中台架构的兴起，DevOps 也变得非常关键，毕竟是一些基础设施层面的建设，如果搞好了对后面的研发工作会有很大的效率提升。关于 DevOps 本身的概念，网上已经非常多了，在园子里随便搜索一些都一堆概念，我就不再重复介绍了。下面直接进入正题，怎么使用 GitLab+Jenkins 来完成 DevOps 的建设。

    在开始实战演练之前，首先用一张图来展示一下这次实践所要完成的功能：

    在这个流程中，分为 3 个环境，分别是预览环境、预发环境和生产环境，普通开发者接受到任务以后，在 GitLab 中基于 feature 分支进行开发，然后把开发好的需求申请合并到 dev 分支，在申请合并的过程中，会触发构建流水线进行编译、单元测试、接口测试、发布环境等系列校验，当 pipeline 完成以后，组长就可以在代码审查后，进行合并到 dev 分支。这个时候又会触发 dev 分支的构建流水线，然后再完成一遍上述的流程，把代码发布到预发环境。最后由项目负责人定期把 dev 合并到 master 分支，完成生产环境版本发布。

    首先，在 GitLab 中创建一个测试项目：

    这个项目是在 lizongshenblogs 的 group 下面的 applications 子 group 下的一个项目，代表了这是一个源代码项目。

接下来再为这个项目创建 3 个流水线配置，主要目的是为了让代码和配置分离：

     在 3 个配置项目中，分别存放了相应的 Jenkinsfile，用于 Jenkins 流水线的构建配置，接下来开始配置 Jenkins。首先进行 Jenkins 的全局配置：在 Jenkins 的 Manage Jenkins – Configure System 下面配置 Gitlab Connection，如图：

在这里需要注意，这个 connection 是需要一个 gitlab 的访问令牌，可以在 gitlab 的个人设置 – 访问令牌里面生成，生成完成之后，填入到相应的 Credentials 里面：

 最后测试一下，连接是否成功，只要显示 success，就可以了。

 接下来就可以配置具体 pipeline 了，首先使用 Jenkins 的 New Item 分别创建 3 个流水线类型的项目：

    在 Jenkins 中新建 3 个流水线类型的项目，分别叫 feature-pipeline、dev-pipeline、master-pipeline，然后对这 3 个项目分别进行配置，先来看 feature-pipeline 的配置：

    首先要配置的项是 Build Triggers, 在其中勾选 Opened Merge Request Events，并且把 Rebuild open Merge Requests 设置成 On push to source branch：

 然后点击 Advanced 按钮，进行高级设置：

这里需要注意的地方是原分支是任何分支，目标分支是 dev 分支，然后生成一个 Secret token，这个 token 在配置 gitlan webhooks 的时候会用到。

接下来是配置 Pipeline 项：

     这个地方需要配置具体的流水线仓储的地址，在 credentials 的地方，使用账号密码登录到 gitlab 即可。

    dev 流水线和 master 流水线配置略有不同，其中 dev 分支需要配置成 accepted merge request events，意思就是当组长接受合并请求的时候触发：

     而 master 分支需要改变的地方是匹配的分支，表示只接受从 dev 分支到 master 分支的合并请求：

     到这里 Jenkins 的配置已经配置完成，接下来再回到 gitlab 进行联动配置，首先配置项目的 webhoos，在项目的 Integrations Settings 里面添加一个 webhooks：

    其中 URL 就填写 Jenkins 的 Build Triggers 项目自动生成的那个 URL，secret token 是在 Build Triggers 的高级选项里面生成的那个 token，触发的选项选择 Merge request events，表示当合并请求的时候进行触发，点击保存，gitlab 和 Jenkins 的配置基本上就完成了。

    最后看一下 3 个项目中的 Jenkinsfile：

pipeline {
    agent {
        label ‘slave-pipeline’
    }
    options {
        gitLabConnection(‘gitlab’)
    }
    stages {
        stage(‘Prepare’){
            steps{
                script{
                        git branch: ‘${gitlabSourceBranch}’, changelog: false, credentialsId: ‘gitlab’, poll: false, url: ‘https://gitlab.com/lizongshenblogs/applications/devopsdemo.git’
                               
                        script {
                            GIT_COMMIT_ID = sh(returnStdout: true, script: ‘git rev-parse –short HEAD’).trim()
                            IMAGE_TAG = “${GIT_COMMIT_ID}-snapshot”
                            INGRESS_HOST = “preview-${gitlabSourceRepoName}-${gitlabMergeRequestIid}”
                            MR_URL = “${gitlabSourceRepoHomepage}/merge_requests/${gitlabMergeRequestIid}”
   
                            build_tag = “feature-${gitlabSourceRepoName}-${gitlabSourceBranch}-${GIT_COMMIT_ID}”
                            currentBuild.displayName = “#” + BUILD_NUMBER + “_” + gitlabMergeRequestIid + “_” + build_tag
                        }
                }
            }
       
        }
   
        stage(‘Build’) {
       
            when {
                expression {
                    “${gitlabTargetBranch}” == ‘dev’
                }
            }
           
            steps {
                script {
                    updateGitlabCommitStatus name: ‘Build’, state: ‘running’
   
                    try {
                   
                        echo “ 开始编译 …”
                       
                    } catch(Exception ex){
                        updateGitlabCommitStatus name: ‘Build’, state: ‘failed’
                        throw ex;
                    } finally {
   
                    }
   
                    updateGitlabCommitStatus name: ‘Build’, state: ‘success’
   
                }
            }
        }
        stage(‘Test’) {
            steps {
                script {
                    updateGitlabCommitStatus name: ‘Test’, state: ‘running’
   
                    try {
                        echo “ 开始进行单元测试 …”
                    } catch(Exception ex){
                        updateGitlabCommitStatus name: ‘Test’, state: ‘failed’
                        throw ex;
                    } finally {
   
                    }
                   
                    updateGitlabCommitStatus name: ‘Test’, state: ‘success’
                     
                }
            }
        }
        stage(‘Deploy’) {
            steps {
                script {
                    updateGitlabCommitStatus name: ‘Deploy’, state: ‘running’
   
                    try {
                        echo “ 开始进行发布 …”
 
                    } catch(Exception ex){
                        updateGitlabCommitStatus name: ‘Deploy’, state: ‘failed’
                        throw ex;
                    } finally {
   
                    }
                   
                    updateGitlabCommitStatus name: ‘Deploy’, state: ‘success’
                    addGitLabMRComment comment: “App ${gitlabSourceRepoName} preview link: <a href=’http://localhost’>${gitlabSourceRepoName}</a>”
                }
            }
        }
    }
   
    post {
        failure {
            updateGitlabCommitStatus name: ‘Complete’, state: ‘failed’
        }
        success {
            updateGitlabCommitStatus name: ‘Complete’, state: ‘success’
        }
    }
}

 其中 updateGitlabCommitStatus 就可以实时地把 Jenkins 的构建状态发回到 gitlab 中去：

    点击这些构建状态，就可以实时地查看到构建日志。在这里 gitlab 和 Jenkins 的配置基本上就全部完成了，接下来再看一下 gitlab 中关于代码管理配置，一般情况下，dev 分支和 master 分支是不允许直接 push 代码的，只允许从需求分支中合并代码，这就需要在 gitlab 的       Settings – Repository – Protected Branches 中把 dev 和 master 保护起来：

     另外还可以设置只有当流水线成功了以后，才可以进行合并：

    通过这样一些保护措施，就可以让 dev 和 master 分支变得相对稳定。由于篇幅有限，如果有不明白的地方，可以私下找我相互交流。DevOps 是一个很广泛的话题，今天讲的 GitLab+Jenkins 这套流程只是 DevOps 中的一部分，完全实现 DevOps 还需要更多的流程配合，以后有机会再为大家分享。