前沿追踪|GitLabCI/CD自动集成和部署到远程服务器


前沿追踪|GitLabCI/CD自动集成和部署到远程服务器目的是通过一个示例应用程序对GitLab CI/CD进行友好的了解 , 该应用程序有助于入门 , 而无需阅读所有GitLab文档 。
持续集成的工作原理是:将小的代码块-commits-推送到Git存储库中托管的应用程序的代码库中 , 并且每次推送时 , 都要运行脚本管道来构建 , 测试和验证代码更改 , 然后再将其合并到主分支中 。
持续交付和部署包括进一步的CI , 可在每次推送到存储库默认分支时将应用程序部署到生产环境 。 这些方法使您可以在开发周期的早期发现错误和错误 , 从而确保部署到生产环境的所有代码均符合为应用程序建立的代码标准 。
使用Gitlab CI/CD的主要好处之一是 , 您无需使用许多第三方插件和工具来创建工作流的繁琐过程 。 GitLab CI/CD由位于存储库根目录的一个名为.gitlab-ci.yml的文件配置 。 该文件中设置的脚本由GitLab Runner执行 。
要将脚本添加到该文件 , 需要按照您的应用程序适合的顺序组织它们 , 并通过执行的测试 。 为了可视化该过程 , 请想象添加到配置文件中的所有脚本与在计算机的终端上运行的命令相同 。
【前沿追踪|GitLabCI/CD自动集成和部署到远程服务器】这些脚本被分组为job , 它们共同组成了一个管道 。
流水线我们可以根据需要构造管道 , 因为YAML是一种序列化的人类可读语言
建立3条管道的假设:

  • Project Pipeline 将安装依赖项 , 运行linters , 以及处理该代码的所有脚本 。
  • 持续集成管道运行自动化测试并构建代码的分布式版本 。
  • 部署管道将代码部署到指定的云提供商和环境 。
管道执行的步骤称为作业 。 当您通过这些特征将一系列作业分组时 , 这称为阶段 。 作业是管道的基本构建块 。 可以将它们分为多个阶段 , 也可以将各个阶段分为多个管道 。
前沿追踪|GitLabCI/CD自动集成和部署到远程服务器根据上图 , 我们来配置一个基本的管道实例 。 以下是.gitlab-ci文件
stages:- build- test- deployimage: alpinebuild_a:stage: buildscript:- echo "This job builds something."build_b:stage: buildscript:- echo "This job builds something else."test_a:stage: testscript:- echo "This job tests something. It will only run when all jobs in the"- echo "build stage are complete."test_b:stage: testscript:- echo "This job tests something else. It will only run when all jobs in the"- echo "build stage are complete too. It will start at about the same time as test_a."deploy_a:stage: deployscript:- echo "This job deploys something. It will only run when all jobs in the"- echo "test stage complete."deploy_b:stage: deployscript:- echo "This job deploys something else. It will only run when all jobs in the"- echo "test stage complete. It will start at about the same time as deploy_a."在此层次结构中 , 所有三个组件都被视为三个不同的阶段[{build_a , build_b} , {test_a , test_b} , {deploy_a , deploy_b}] 。 主要阶段-build , -test和-deploy是阶段 , 这些部分下的每个项目都是一项工作 。
作业将根据stages指令中列出的顺序执行 。
您可以使用only指令使deploy_a部署到登台服务器 , 将deploy_b部署到生产服务器 , 当在only指令下将提交推送到分支时 , 将触发作业