精华内容
下载资源
问答
  • 【Git】GitLab CI/CD 的执行流程及实战

    千次阅读 多人点赞 2020-11-06 10:02:12
    配置服务器 weget 安装服务器下载 yum -y install wget maven 官网下载 apache-maven-3.6.3-bin.tar.gz ...tar -zxf 文件 -C 指定目录 配置环境变量 # Maven export MAVEN_HOME=/opt/software/apache-

    介绍

    GitLab CI/CD 是一个简洁好用的的持续集成/持续交付的框架。通过为你的项目配置一个或者多个 GitLab Runner,然后撰写一个 .gitlab-ci.yml,你就可以很方便地利用 GitLab CI/CD 来为你的项目引入持续集成/交付的功能。

    执行流程

    Stage顺序执行(编译、测试、开发)

    在这里插入图片描述

    GitLab CI/CD 的执行过程中首先驱动的是 Stage。

    每个 GitLab CI/CD 都必须包含至少一个 Stage。多个 Stage 是按照顺序执行的。如果其中任何一个 Stage 失败,则后续的 Stage 不会被执行,整个 CI 过程被认为失败。

    例如,整个 CI 环节包含三个 Stage:build、test 和 deploy
    build 被首先执行。如果发生错误,本次 CI 立刻失败;
    test 在 build 成功执行完毕后执行。如果发生错误,本次 CI 立刻失败;
    deploy 在 test 成功执行完毕后执行。如果发生错误,本次 CI 失败。

    Stage 在 .gitlab-ci.yml 中通过如下的方式定义:

    stages:
      - build
      - test
      - deploy
    

    如果文件中没有定义 stages,那么则默认包含 build、test 和 deploy 三个 stage。
    Stage 中并不能直接配置任何具体的执行逻辑,具体的执行逻辑应该在 Job 中配置。

    Job(执行逻辑配置)

    在这里插入图片描述

    Job 可以被关联到一个 Stage。当一个 Stage 执行的时候,与其关联的所有 Job 都会被执行。需要注意的是,Job 在设计上是可并行执行的。这样的好处是可以利用多个 Runner 来加速 CI/CD 的流程。

    因此,如果 Job 之间有依赖关系的话,需要通过关联到不同的 Stage 来实现。
    Job 在 .gitlab-ci.yml 中通过如下的方式来和 Stage 关联:
    如果一个 Job 没有显式地关联某个 Stage,则会被默认关联到 test Stage

    job_build_module_A:
      stage: build
    

    Job 的执行(script shell脚本)

    Job 包含了真正的执行逻辑,例如调用 mvn 或者 gcc 等命令。

    job_build_module_A:
      script:
        - cd module_A
        - mvn clean compile
    

    公共配置

    随着项目越来越大,Job 越来越多,Job 中包含的重复逻辑可能会让配置文件臃肿不堪。.gitlab-ci.yml 中提供了 before_scriptafter_script 两个全局配置项。这两个配置项在所有 Job 的 script 执行前和执行后调用。

    例如:

    job_build_module_A:
      script:
        - export MAVEN_OPTS="-Xmx256m"
        - cd module_A
        - mvn clean compile
    
    ...
    
    job_build_module_Z:
      script:
        - export MAVEN_OPTS="-Xmx256m"
        - cd module_Z
        - mvn clean compile
    

    这其中 export MAVEN_OPTS="-Xmx256m" 显然是可以抽取公用的部分,在 before_script 的帮助下,配置文件可以优化成:

    before_script:
      - export MAVEN_OPTS="-Xmx256m"
    
    job_build_module_A:
      script:
        - cd module_A
        - mvn clean compile
    
    ...
    
    job_build_module_Z:
      script:
        - cd module_Z
        - mvn clean compile
    

    after_script 也可以起到类似的作用,不过是在每个 Job 执行完毕以后被调用。

    公共数据Cache

    Job 的执行过程中往往会产生一些数据,默认情况下 GitLab Runner 会保存 Job 生成的这些数据,然后在下一个 Job 执行之前(甚至不局限于当次 CI/CD)将这些数据恢复。这样即便是不同的 Job 运行在不同的 Runner 上,它也能看到彼此生成的数据。

    不过这些行为可能会带来意料之外的问题,比如说上一次 CI/CD 执行的是 master 分支的 build,下一次 CI/CD 执行的却是 devel 分支的 build,而 build 脚本偏偏是增量执行的,那么有可能导致第二次 build 的过程错误地引用了 master 编译生成的中间结果。
    这个情况下,我们需要配置 cache.key:

    cache:
      key: "$CI_COMMIT_REF_NAME"
    

    这个配置的意思是:所有的 Job 在恢复 cache 的时候,是根据当前的分支名称去选择对应的 cache。换句话说,前面例子中的两次 build 会选中不同的 cache,数据自然就隔离开了。

    当然,上面的隔离粒度是分支级别的,你还可以配置成 分支+Job 级别的:

    cache:
      key: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
    

    上面两个例子中的 CI_COMMIT_REF_NAMECI_JOB_NAME 是 GitLab CI/CD 的预定义变量。除了它们以外,还有许多预定义变量可以供我们选择,详情可以参阅

    总结

    在了解了 Job 配置的 script、before_script、after_script 和 cache 以后,我们便可以将整个 Job 的执行流程用一张图概括下来了:
    在这里插入图片描述
    GitLab CI/CD 是通过 GitLab Runner 来执行的
    GitLab CI/CD 将按照 Stage 定义的顺序来执行,任何一个 Stage 失败,整个 CI/CD 将失败
    每一个 Stage 可以被若干个 Job 关联。Stage 在执行的时候,关联到这个 Stage 的所有 Job 都将被执行,不过不同的 Job 可能是并行执行的。
    每个 Job 在执行的时候,会先按照缓存策略加载缓存数据,然后按照顺序依次运行 before_script、script 和 after_script 中配置的脚本,运行完毕以后,会将生成的数据保存到缓存中。

    配置服务器

    weget

    安装服务器下载
    yum -y install wget

    maven

    官网下载
    apache-maven-3.6.3-bin.tar.gz
    下载maven
    https://downloads.apache.org/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz
    解压文件
    tar -zxf 文件 -C 指定目录

    配置环境变量

    # Maven
    export MAVEN_HOME=/opt/software/apache-maven-3.6.3
    export PATH=$PATH:$MAVEN_HOME/bin
    

    阿里云镜像配置

    参考过往项目github
    vim apache-maven-3.6.3/conf/settings.xml

    <mirror>
       <id>alimaven</id>
       <name>aliyun maven</name>
       <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
       <mirrorOf>central</mirrorOf>    
    </mirror>
    

    配置Gitlab

    配置.gitlab-ci.yml

    165机器做测试,未做输出版

    # shipper
    stages:
      - test
      - build
    
    test:
      stage: test
      script:
        - echo "test stage"
      only:
        - develop
      tags:
        - dev-165
    
    build:
      stage: build
      script:
        - echo "build stage"
      when: manual
      only:
        - develop
      tags:
          - dev-165
    

    添加maven到script中ci测试

      script:
        - echo "test stage"
        # Maven
        - export MAVEN_HOME=/opt/software/apache-maven-3.6.3
        - export PATH=$PATH:$MAVEN_HOME/bin
        - mvn clean package  -DskipTests=true
    

    服务端注册gitlab
    gitlab-runner register
    对应生成指令
    添加描述
    shell

    在这里插入图片描述

    备份时间片

    stages:
      - build
      - test
      - deploy
    
    build-dev:
      stage: build
      script:
        - echo "dev build stage"
        # Maven
        - export MAVEN_HOME=/opt/software/apache-maven-3.6.3
        - export PATH=$PATH:$MAVEN_HOME/bin
        - mvn clean package -DskipTests=true
        - backuptime=$(date "+%Y%m%d%H%M%S")
        - mv /home/gitlab-runner/odeon/shipper/shipper-0.0.1-alpha0.jar /home/gitlab-runner/odeon/shipper/shipper-0.0.1-alpha0.jar.bak.${backuptime}
        - cp target/shipper-0.0.1-alpha0.jar /home/gitlab-runner/odeon/shipper
      only:
        - develop
      tags:
        - dev-165
    
    build-test:
      stage: build
      script:
        - echo "build stage"
      only:
        - test
      tags:
        - dev_161
    
      # dev deploy
    deploy-dev:
      stage: deploy
      script:
        - echo "deploy dev"
        - pwd
        - ls -al
        - PID=$(cat /home/gitlab-runner/odeon/shipper/process.pid)
        - kill $PID
        - nohup java -jar /home/gitlab-runner/odeon/shipper/shipper-0.0.1-alpha0.jar >> shipper.log 2>&1 & echo $! > process.pid
      only:
        - develop
      when: manual
      tags:
        - dev-165
    
    

    管道验证

    在这里插入图片描述

    展开全文
  • GitLab CI/CD 的执行流程

    千次阅读 2019-02-21 14:23:16
    介绍 GitLab CI/CD 是一个简洁好用的的持续集成/持续交付的框架。通过为你的项目配置一个或者多个 GitLab Runner,然后...执行流程 Stage GitLab CI/CD 的执行过程中首先驱动的是 Stage。 CI 中 Stage 的执行 ...

    介绍

    GitLab CI/CD 是一个简洁好用的的持续集成/持续交付的框架。通过为你的项目配置一个或者多个 GitLab Runner,然后撰写一个 .gitlab-ci.yml,你就可以很方便地利用 GitLab CI/CD 来为你的项目引入持续集成/交付的功能。

    执行流程

    Stage

    GitLab CI/CD 的执行过程中首先驱动的是 Stage。

    CI 中 Stage 的执行

    每个 GitLab CI/CD 都必须包含至少一个 Stage。多个 Stage 是按照顺序执行的。如果其中任何一个 Stage 失败,则后续的 Stage 不会被执行,整个 CI 过程被认为失败。

    以图中所示为例,整个 CI 环节包含三个 Stage:buildtest
    deploy

    • build 被首先执行。如果发生错误,本次 CI 立刻失败;
    • testbuild 成功执行完毕后执行。如果发生错误,本次 CI 立刻失败;
    • deploytest 成功执行完毕后执行。如果发生错误,本次 CI 失败。

    Stage 在 .gitlab-ci.yml 中通过如下的方式定义:

    stages:
      - build
      - test
      - deploy
    

    如果文件中没有定义 stages,那么则默认包含 buildtestdeploy 三个 stage。

    Stage 中并不能直接配置任何具体的执行逻辑,具体的执行逻辑应该在 Job 中配置。

    Job

    Stage 中 Job 的执行

    Job 可以被关联到一个 Stage。当一个 Stage 执行的时候,与其关联的所有 Job 都会被执行。需要注意的是,Job 在设计上是可并行执行的。这样的好处是可以利用多个 Runner 来加速 CI/CD 的流程。

    因此,如果 Job 之间有依赖关系的话,需要通过关联到不同的 Stage 来实现。

    Job 在 .gitlab-ci.yml 中通过如下的方式来和 Stage 关联:

    job_build_module_A:
      stage: build
    

    如果一个 Job 没有显式地关联某个 Stage,则会被默认关联到 test Stage。

    Job 的执行

    Job 包含了真正的执行逻辑,例如调用 mvn 或者 gcc 等命令。

    job_build_module_A:
      script:
        - cd module_A
        - mvn clean compile
    

    公共配置

    随着项目越来越大,Job 越来越多,Job 中包含的重复逻辑可能会让配置文件臃肿不堪。.gitlab-ci.yml 中提供了 before_scriptafter_script 两个全局配置项。这两个配置项在所有 Job 的 script 执行前和执行后调用。

    例如:

    job_build_module_A:
      script:
        - export MAVEN_OPTS="-Xmx256m"
        - cd module_A
        - mvn clean compile
    
    ...
    
    job_build_module_Z:
      script:
        - export MAVEN_OPTS="-Xmx256m"
        - cd module_Z
        - mvn clean compile
    

    这其中 export MAVEN_OPTS="-Xmx256m" 显然是可以抽取公用的部分,在 before_script 的帮助下,配置文件可以优化成:

    before_script:
      - export MAVEN_OPTS="-Xmx256m"
    
    job_build_module_A:
      script:
        - cd module_A
        - mvn clean compile
    
    ...
    
    job_build_module_Z:
      script:
        - cd module_Z
        - mvn clean compile
    

    after_script 也可以起到类似的作用,不过是在每个 Job 执行完毕以后被调用。

    公共数据 - Cache

    Job 的执行过程中往往会产生一些数据,默认情况下 GitLab Runner 会保存 Job 生成的这些数据,然后在下一个 Job 执行之前(甚至不局限于当次 CI/CD)将这些数据恢复。这样即便是不同的 Job 运行在不同的 Runner 上,它也能看到彼此生成的数据。

    不过这些行为可能会带来意料之外的问题,比如说上一次 CI/CD 执行的是 master 分支的 build,下一次 CI/CD 执行的却是 devel 分支的 build,而 build 脚本偏偏是增量执行的,那么有可能导致第二次 build 的过程错误地引用了 master 编译生成的中间结果。

    这个情况下,我们需要配置 cache.key

    cache:
      key: "$CI_COMMIT_REF_NAME"
    

    这个配置的意思是:所有的 Job 在恢复 cache 的时候,是根据当前的分支名称去选择对应的 cache。换句话说,前面例子中的两次 build 会选中不同的 cache,数据自然就隔离开了。

    当然,上面的隔离粒度是分支级别的,你还可以配置成 分支+Job 级别的:

    cache:
      key: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
    

    上面两个例子中的 CI_COMMIT_REF_NAMECI_JOB_NAME 是 GitLab CI/CD 的预定义变量。除了它们以外,还有许多预定义变量可以供我们选择,详情可以参阅《GitLab CI/CD Variables: Predefined variables》

    Job 的执行总览

    在了解了 Job 配置的 scriptbefore_scriptafter_scriptcache 以后,我们便可以将整个 Job 的执行流程用一张图概括下来了:

    Job 执行流程

    总结

    通过上面的介绍,我们可以了解到:

    1. GitLab CI/CD 是通过 GitLab Runner 来执行的
    2. GitLab CI/CD 将按照 Stage 定义的顺序来执行,任何一个 Stage 失败,整个 CI/CD 将失败
    3. 每一个 Stage 可以被若干个 Job 关联。Stage 在执行的时候,关联到这个 Stage 的所有 Job 都将被执行,不过不同的 Job 可能是并行执行的。
    4. 每个 Job 在执行的时候,会先按照缓存策略加载缓存数据,然后按照顺序依次运行 before_scriptscriptafter_script 中配置的脚本,运行完毕以后,会将生成的数据保存到缓存中。

    参阅

     

    展开全文
  • Gitlab--CI执行用户问题

    千次阅读 2020-04-04 20:25:17
    19年团队使用了 Gitlab-CI,做一些自动构建流程。最近团队小伙伴自己尝试搭建流程,参照了我之前发的文章 – Gitlab–CI。但过程中,遇到了用户执行权限的问题。于是有了下面的内容… 问题描述 按照文章...

    19年团队使用了 Gitlab-CI,做一些自动构建流程。最近团队小伙伴自己尝试搭建流程,参照了我之前发的文章 – Gitlab–CI。但过程中,遇到了用户执行权限的问题。于是有了下面的内容…

    问题描述

    按照文章(https://ligang.blog.csdn.net/article/details/89785856)中说明,操作完成发现了权限问题。

    问题复盘

    首先要明确,CI 默认执行用户为 gitlab-runner

    $ ps aux | grep gitlab
    
    /usr/bin/gitlab-ci-multi-runner run --working-directory /home/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog --user gitlab-runner
    

    文章中包括 gitlab-runner 服务启动在内的,所有操作都是使用 sudo。这也是为什么,文章中,将 gitlab-runner 免密使用sudo命令,并在脚本的命令前加上 sudo 的要求。

    # 切换到root账号下
    $ su
    # 添加sudo文件的写权限
    $ chmod u+w /etc/sudoers
    # 编辑sudoers文件
    $ vi /etc/sudoers
    # 添加如下内容 允许用户gitlab-runner执行sudo命令,并且在执行的时候不输入密码
    gitlab-runner ALL=(ALL) NOPASSWD: ALL
    # 撤销sudo文件写权限
    $ chmod u-w /etc/sudoers
    

    官方关于权限的说明,可参照:Super-user permission

    上述内容,是团队小伙伴所忽略的。当然,小伙伴提出了另外一种方式,使用 root 执行。

    1. 修改 /etc/systemd/system/gitlab-runner.service

      [Service]
      ExecStart=/usr/bin/gitlab-ci-multi-runner "run" "--working-directory" "/工作目录" "--config" "/etc/gitlab-runner/config.toml" "--service" "gitlab-runner" "--syslog" "--user" "root"
      
      arameterDefaultDescription
      –servicegitlab-runnerSpecify service name to use
      –configSee the configuration fileSpecify a custom configuration file to use
      –syslogtrueSpecify if the service should integrate with system logging service
      –working-directorythe current directorySpecify the root directory where all data will be stored when builds will be run with the shell executor
      –userrootSpecify the user which will be used to execute builds
      –passwordnoneSpecify the password for the user that will be used to execute the builds
    2. 重新加载配置文件,并启动

      $ systemctl daemon-reload
      $ systemctl restart gitlab-runner
      

    综上,欢迎大家积极讨论~~~

    展开全文
  • 持续集成,Continuous integration ,简称CI。 随着软件开发复杂度的不断提高,团队开发成员间如何更好地协同工作以确保软件开发的质量已经慢慢成为开发过程中不可回避的问题。尤其是近些年来,...

    那什么是持续集成?Jenkins具体用来做什么,对软件开发有什么益处呢?

    总得来说,这两者主要是涉及一个软件质量的主题,特别是团队开发软件项目。下面就来介绍介绍下这两者。

    持续集成

    持续集成,Continuous integration ,简称CI。

    随着软件开发复杂度的不断提高,团队开发成员间如何更好地协同工作确保软件开发的质量已经慢慢成为开发过程中不可回避的问题。尤其是近些年来,敏捷(Agile) 在软件工程领域越来越红火,如何能在不断变化的需求中快速适应和保证软件的质量也显得尤其的重要。

    持续集成正是针对这一类问题的一种软件开发实践。倡导团队开发成员必须经常集成他们的工作,甚至每天都可能发生多次集成。而每次的集成都是通过自动化的构建来验证,包括自动编译、发布和测试,从而尽快地发现集成错误,让团队能够更快的开发内聚的软件。

    -------以我经过的项目(假设为A项目)为例进行描述---------

    首先,解释下集成

    我们所有项目的代码都是托管在SVN服务器上。

    每个项目都要有若干个单元测试,并有一个所谓集成测试。

    所谓集成测试就是把所有的单元测试跑一遍以及其它一些能自动完成的测试。只有在本地电脑上通过了集成测试的代码才能上传到SVN服务器上,保证上传的代码没有问题。

    所以,集成指集成测试

    再说持续

    不言而喻,就是指长期的对项目代码进行集成测试。

    既然是长期,那肯定是自动执行的,否则,人工执行则没有保证,而且耗人力。

    对此,我们有一台服务器,它会定期的从SVN中检出代码,并编译,然后跑集成测试。每次集成测试结果都会记录在案。

    完成这方面工作的就是下面要介绍的Jenkins软件。

    当然,它的功能远不止这些。在我们的项目中,执行这个工作的周期是1天。也就是,服务器每1天都会准时地对SVN服务器上的最新代码自动进行一次集成测试。

    持续集成的特点

    • 它是一个自动化的周期性的集成测试过程,从检出代码、编译构建、运行测试、结果记录、测试统计等都是自动完成的,无需人工干预;
    • 需要有专门的集成服务器来执行集成构建;
    • 需要有代码托管工具支持;

    持续集成的作用

    • 保证团队开发人员提交代码的质量,减轻了软件发布时的压力;
    • 持续集成中的任何一个环节都是自动完成的,无需太多的人工干预,有利于减少重复过程以节省时间、费用和工作量;

    持续集成(CI)的流程

    该系统的各个组成部分是按如下顺序来发挥作用的:

    1. 开发者检入代码到源代码仓库。

    2. CI系统会为每一个项目创建了一个单独的工作区。当预设或请求一次新的构建时,它将把源代码仓库的源码存放到对应的工作区。

    3. CI系统会在对应的工作区内执行构建过程。

    4. (配置如果存在)构建完成后,CI系统会在一个新的构件中执行定义的一套测试。完成后触发通知(Email,RSS等等)给相关的当事人。

    5. (配置如果存在)如果构建成功,这个构件会被打包并转移到一个部署目标(如应用服务器)或存储为软件仓库中的一个新版本。软件仓库可以是CI系统的一部分,也可以是一个外部的仓库,诸如一个文件服务器或者像Java.net、SourceForge之类的网站。

    6. CI系统通常会根据请求发起相应的操作,诸如即时构建、生成报告,或者检索一些构建好的构件。

    上面我们了解了持续集成的知识。既然有这么多的好处,那我们怎么样实现它呢?

    这就是接下来要介绍的名角:Jenkins软件。

     

    Jenkins

    Jenkins,原名Hudson,2011年改为现在的名字,它 是一个开源的实现持续集成的软件工具。官方网站:http://jenkins-ci.org/

    Jenkins 能实时监控集成中存在的错误,提供详细的日志文件和提醒功能,还能用图表的形式形象地展示项目构建的趋势和稳定性

    Jenkins特点

    • 易安装:仅仅一个 java -jar jenkins.war,从官网下载该文件后,直接运行,无需额外的安装,更无需安装数据库;
    • 易配置:提供友好的GUI配置界面;
    • 变更支持:Jenkins能从代码仓库(Subversion/CVS)中获取并产生代码更新列表并输出到编译输出信息中;
    • 支持永久链接:用户是通过web来访问Jenkins的,而这些web页面的链接地址都是永久链接地址,因此,你可以在各种文档中直接使用该链接;
    • 集成E-Mail/RSS/IM当完成一次集成时,可通过这些工具实时告诉你集成结果(据我所知,构建一次集成需要花费一定时间,有了这个功能,你就可以在等待结果过程中,干别的事情);
    • JUnit/TestNG测试报告:也就是用以图表等形式提供详细的测试报表功能;
    • 支持分布式构建:Jenkins可以把集成构建等工作分发到多台计算机中完成
    • 文件指纹信息:Jenkins会保存哪次集成构建产生了哪些jars文件,哪一次集成构建使用了哪个版本的jars文件等构建记录;
    • 支持第三方插件:使得 Jenkins 变得越来越强大;

    Jenkins应用场景

    • l 持续、自动地构建/测试软件项目。
    • l 监控一些定时执行的任务。

     

    其它集成工具

    其它比较著名的持续集成工具有:CruiseControl,TeamCity,Continuum等。

    参考链接:http://velep.com/archives/867.html

    展开全文
  • gitlab ci/cd自动化部署流程

    千次阅读 2020-12-03 18:53:37
    nginx默认指向/gitci/ci/dist目录,这里我们在root账户里只创建/gitci,至于/ci/dist使我们在其他用户gitlab-runner里面完成,下面是具体操作 gitlab-runner安装流程 curl -L ...
  • CI框架工作流程

    千次阅读 2016-05-28 14:33:43
    CI工作流程:  所有的入口都从根目录下的index.php进入,确定应用所在目录后,加载 codeigniter/CodeIgniter.php 文件,该文件会顺序加载以下文件执行整个流程。  index.php:检测文件路径,加载codeigniter...
  • MyEclipse2017CI10激活工具能够完美激活MyEclipse 2017 CI10,完美解锁最贵的2000元一年的Bling版本 Myeclipse激活流程 0.下载安装MyEclipse_2017_CI10,安装完最好千万别直接打开软件 1.先将patch里的文件拷贝到...
  • 简述SpringMVC的执行流程

    千次阅读 2018-07-15 22:26:58
    老板指使我们工作,此时我们化身为员工(Handler,也就是请求所对应的事件),我们工作的内容就控制层(也就是MVC中的C)下请求url所对应的方法,工作完成之后,我们需要提交工作数据呈现给老板看(返回ModelAndView...
  • GitLab 容器化 CI 流程填坑记(一)

    千次阅读 2018-09-10 20:52:58
    本文以SpringBoot项目的部署构建为例,对基于GItLab的CI流程进行简要介绍。   环境准备: 1. 系统环境: 操作系统:CentOS 7.2 1511 GitLab:v11.1.4 GitLab-runner:v11.2.0 Docker:17.03.2 ce   2. ...
  • GitLab CI 介绍

    千次阅读 2018-09-04 08:12:00
    GitLab CI 即是 gitlab continuous integration,意思是持续集成。中心思想是当每一次 push 到 gitlab 的时候,都会触发一次脚本执行,脚本的内容可以包括测试,编译,部署等一系列自定义的内容。   二、相关概念...
  • Drone CI:搭建自己CI/CD(一)

    千次阅读 2020-05-15 13:47:44
    CI全称为Continuous Integration,意为持续集成,是在源代码变更后自动检测、拉取、构建和进行自动化测试的过程,属于开发人员的自动化流程。该解决方案可以解决在一次开发中有太多应用分支,从而导致相互冲突的问题...
  • myeclise_2017_CI_10破解文件(可选版本)

    热门讨论 2018-04-02 12:02:49
    MyEclipse2017CI10激活工具能够完美激活MyEclipse 2017 CI10 Myeclipse激活流程 0.下载安装MyEclipse_2017_CI10,安装完最好千万别直接打开软件 1.先将patch里的文件拷贝到myeclipse2017安装目录下的 plugins下 2...
  • 一步一步在docker中构建CI流程

    千次阅读 2015-09-05 19:46:05
    这里我们使用Jenkins作为CI工具,构建一个简单自动部署的Java项目的流程。其中源码使用Git管理(这里托管在 oschina ) 我们需要构建的镜像包括: Jenkins(CI工具) Tomcat(java web项目服务器) 这里...
  • 【SpringMVC】——图解执行流程

    万次阅读 多人点赞 2018-07-12 10:11:44
    springmvc执行流程执行流程1、用户发送请求到前端控制器DispatcherServlet2、DispatcherServlet收到请求调用处理映射器HandlerMapping3、处理映射器根据请求url找到具体的处理器,生成处理器执行链...
  • GitLab CI介绍——入门篇

    万次阅读 2019-07-30 09:25:10
    本文将会对Gitlab CI进行简要介绍,包括Gitlab Runner,Gitlab CI中的相关概念以及.gitlab-ci.yml的常用配置。 那么,GitLab CI 是什么? GitLab CI 是GitLab内置的进行持续集成的工具,只需要在仓库根目录下创建....
  • GitLab CI/CD 基础教程(一)

    万次阅读 多人点赞 2019-03-08 08:57:09
    1.1 CI/CD CI,Continuous Integration,为持续集成。即在代码构建过程中持续地进行代码的集成、构建、以及自动化测试等;有了 CI 工具,我们可以在代码提交的过程中通过单元测试等尽早地发现引入的错误; CD,...
  • GitLab CI 安装步骤图文详解

    千次阅读 2018-09-05 08:25:07
    如果你还不了解 GitLab CI 的话,最好先参考一下这篇博客对 GitLab CI 的简介, 链接:https://blog.csdn.net/afei__/article/details/82377382 GitLab 8.0 之后的版本已经默认集成了 CI,所以我们只需要安装 CI ...
  • CI、CD、Pipeline 概念

    千次阅读 2020-03-22 16:34:34
    文章:什么是持续集成(CI)/持续部署(CD)? 简要摘抄: 对于 “持续” 一词的概念 这并不意味着“一直在运行”,而是“随时可运行”。 CI 即持续集成 持续集成(continuous integration)是在源代码变更后自动...
  • 文章目录gitlab CI中单元测试与集成测试的研究与实践配置说明GitlabGitlab RunnerSonarqubeCI流程图需要解决的问题代码编写项目代码单元测试Service单元测试Controller单元测试集成测试提供专门用于测试的配置文件...
  • GitLab-CI 是一套 GitLab ...当工程有代码更新时,GitLab 会自动触发 GitLab-CI,此时 它会找到事先注册好的 GitLab-Runner 通知并触发该 Runner 来执行预先定义好的脚本,介绍 Kubernetes 集群中运行 GitLab-Runner
  • [ 利器篇 ] - GitLab CI 部署GitBook

    千次阅读 2019-04-16 23:27:26
    一般来说,构建任务都会占用很多的系统资源 (譬如编译代码),而 GitLab CI 又是 GitLab 的一部分,如果由 GitLab CI 来运行构建任务的话,在执行构建任务的时候,GitLab 的性能会大幅下降。 GitLab CI 最大的作用...
  • GitLab CI/CD +Docker 实现自动化部署

    千次阅读 2020-03-13 16:26:45
    步骤简介 1 准备工作 1.1. gitlab环境 1.2. 装有docker和gitlab-runner环境...1.5. .gitlab-ci.yml 2 环境配置 2.1. 配置权限 2.2. 为项目注册执行部署任务的Runner服务器 3 自动部署 3.1. 提交代码到git maste...
  • GitLab CI/CD工作原理及使用

    万次阅读 2018-09-12 15:52:11
    持续集成(Continuous Integration) 持续集成指的是频繁的将代码集成到主干,每次集成都通过自动化的构建(包括编译、发布、自动化测试)来验证,它的好处主要有两个: ...GitLab CI/CD 从8.0版开...
  • Java程序执行流程

    千次阅读 2019-01-02 10:39:52
    简单说来,一个java程序的运行需要编辑源码、编译生成...下面有一段简单的java源码,通过它来看一下java程序的运行流程: 1 class Person 2 3 { 4 5 private String name; 6 7 private int age; 8 ...
  • .gitlab-ci.yml关键词完整解析(一)

    千次阅读 2020-12-11 09:46:05
    .gitlab-ci.yml关键词完整解析(一) 使用GitLab自带的流水线,必须要定义流水线的内容,而定义内容的文件默认叫做.gitlab-ci.yml,使用yml的语法进行编写。 目前任务关键词有28个,全局的关键词有10个,两者重叠的...
  • 忽然想到来探探51单片机的执行流程。这个念头起源于最初见到每个51程序里面的主函数里面最终都挂一个while(1);语句。为何要加一句while死循环让程序停留在main函数中呢。将while(1);语句去掉有什么影响么? ...
  • CI框架快速入门2--执行流程图解析

    千次阅读 2016-06-29 22:20:07
    上图是官网给出的CI框架执行流程图,首先记住一点:index.php是CI框架的唯一可直接执行的php入口文件。 index.php首先会define一些环境常量,最后require CodeIgniter.php核心文件: require_once BASEPATH.'core/...
  • gitlab-ci实现前端自动化部署

    万次阅读 2018-09-18 16:38:26
    gitlab-ci 即 gitlab提供的持续集成的功能。 持续集成:是一种软件开发实践,即团队开发成员经常集成它们的工作,集成每天可能会发生若干次。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,...
  • 深度理解PHP执行流程

    千次阅读 2018-07-13 17:46:54
    二、PHP的执行流程&opcode  我们先来看看PHP代码的执行所经过的流程。 1. Scanning(Lexing),将PHP代码转换为语言片段(Tokens) 那什么是Lexing? 学过编译原理的同学都应该对编译原理中的词法分析步骤有所了解,...
  • CI框架学习笔记第一天

    万次阅读 2017-04-30 09:13:19
    此文章为自己书写,在Word上做的笔记,然后...学习目标使用CI框架开发商城(前台和后台)。 CI简单介绍小巧,快速。 相对于学习其他框架,更容易掌握。 CI快速入门获取与安装: 在官网下载:http://codeigniter.org

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 329,520
精华内容 131,808
关键字:

ci执行流程

友情链接: Java-8-Features.pdf.zip