蓝盟IT小贴士，来喽！
GitLab CI/CD是GitLab中内置的工具，用于以持续的方式进行软件开发。
连续集成(ci ) :持续集成
连续交付(CD ) :持续交付
连续部署(CD ) :持续部署
持续集成的功能是将小代码块推送到Git仓库托管的应用程序代码库，每次推都执行一系列脚本来构建、测试和验证代码更改，并集成到主分支中。
持续交付和部署相当于每次推送到仓库的默认分支时都可以将应用程序部署到生产环境中的更多CI。
这些方法可以在开发周期的早期发现bugs和errors，并确保部署到生产环境中的所有代码都符合为应用程序制定的代码标准。
GitLab CI/CD由名为. gitlab-ci.yml的文件组成，修改后的文件位于仓库的根目录下。 文件中指定的脚本由GitLab Runner执行。
GitLab CI/CD介绍
软件开发的持续方法基于自动执行脚本，最大限度地减少了在应用程序开发时引入错误的机会。 从开发新代码到引入新代码，他们几乎不需要人工干预，也不需要干预。
这包括持续构建、测试和部署每一次小迭代的代码更改，从而减少了根据错误或失败的早期版本开发新代码的机会。
连续集成假定代码存储在GitLab的Git仓库中的应用程序。Continuous Integration (持续集成)。 开发者每天推送多次代码更改。 每次推送到仓库时，都可以编写一组脚本来自动构建和测试应用程序，从而减少在应用程序中引入错误的机会。 这种方法称为持续集成，对于提交给应用程序(甚至开发分支)的所有更改，自动持续构建和测试，为应用程序建立所引入的更改的所有测试、准则和代码
连续交付(Continuous Delivery )是超越持续集成的进一步操作。 应用程序不仅可以在每次推送到代码库的代码更改时生成和测试，而且可以手动触发部署，但可以作为附加步骤连续部署。 这种方法会自动检查代码，但必须从策略手动触发才能输入此更改。连续部署与连续部署类似，但设置为自动部署，而不是手动部署。 不需要手动部署应用程序。
GitLab CI/CD的工作原理
要使用GitLab CI/CD，需要GitLab上托管的应用程序代码库，必须指定要在根目录中的. gitlab-ci.yml文件中构建、测试和部署的脚本。
在该文件中，指定要执行的脚本、定义包含的依赖关系、选择与按顺序执行的命令并行执行的命令、定义放置应用程序的位置、自动运行脚本还是手动启动脚本，
假设为了可视化进程而添加到配置文件中的所有脚本都与在计算机终端上运行的命令相同。
在仓库中添加. GitLab-ci.yml时，gitlab会检测文件，并使用名为GitLab Runner的工具运行脚本。 这个工具的操作类似于终端。
这些脚本被分组到jobs中，它们共同组成一个Pipeline。 最简单的. gitlab-ci.yml文件可能如下所示：
before\_script:
- apt-get install rubygems ruby-dev -y
run-test:
script:
- ruby --version 6
before_script属性在执行任何操作之前安装应用程序依赖关系，名为run-test的job (作业)打印当前系统的Ruby版本。 两者构成了每次被推到仓库的任一分支时触发的Pipeline (管道)。
GitLab CI/CD不仅可以显示在终端上设置的作业，还可以显示在运行过程中发生的情况。
为你的应用程序创建策略后，GitLab会根据你的定义运行Pipeline。 你的配管状态也由GitLab显示。
最后，如果出现问题，可以很容易地回滚所有更改。
基本CI/CD工作流程
如果将提交推送到远程仓库的分支，将触发为项目设置的CI/CD管道。 GitLab CI/CD就是这样运行自动脚本(串行或并行)代码Review并得到批准
构建和测试应用程序。
使用Review Apps预览每个合并请求的更改，如您的本机中所示
得到代码Review和批准
将feature分支合并到默认分支中，并自动将此更改引入生产环境
如果出现问题，很容易回滚
GitLab UI的所有步骤都是可视化的。
文/上海蓝盟 IT外包专家
中文
电话咨询
微信咨询
公众号
