GitLab CI\CD 相关学习

CI/CD 是一种软件开发方式，通过在应用开发阶段引入自动化，以实现软件的持续集成、测试、交付和部署。GitLab CI/CD是GitLab的一个内置工具，配合任务执行程序（持续监控）（如：GitLab Runner），可以实现基于GitLab的自动化流程构建。

1. 概述
2. CI/CD 方法相关介绍
   • 2.1 持续集成（CI）
   • 2.2 持续交付（CD）
   • 2.3 持续部署（CD）
3. GitLab CI/CD 介绍
   • 3.1 GitLab CI/CD 是怎么工作的
   • 3.2 基本的 CI/CD 工作流程
   • 3.3 首次设置GitLab CI/CD

1. 概述

GitLab CI/CD是GitLab的一个内置工具，用于通过持续的方法实现软件开发。其中包括几个重要概念：

• 持续集成 - Continuous Integration(CI)
• 持续交付 - Continuous Delivery(CD)
• 持续部署 - Continuous Deployment(CD)

持续集成的工作原理是将小块的代码块推送到Git的应用托管代码库中，并在每次推送时，都要运行脚本管道来构建、测试和验证代码更改，然后再将其合并到主分支。

持续交付和部署包括进一步的CI，可在每次推送到存储库相关分支时将应用部署到生产环境。

这些方法使你可以在软件开发的早期发现异常和错误，从而确保部署到生产环境的代码都符合代码标准.

2. CI/CD方法相关介绍

在软件开发中，持续化方法基本自动执行的脚本，以最大程序的减少应用开发引入错误的机会。从开发完新代码到部署新代码，几乎或完全不需要人工干预。

它通过每有小的版本迭代就不断的构建、测试和部暑所更改的代码，从而减少了基于错误或失败的先前版本开发新代码的机会。

其中包含三种主要方法，每种方法都需要根据最适合你的策略的方式进行应用：

2.1 持续集成（CI）

假设有一个应用，其代码存储在GitLab的Git存储库中。开发人员每天要多次推送代码更改。对于每次代码推送，我们都可以创建一组脚本来自动构建和测试你的应用，以减少引入错误的机会。这种做法称为持续集成

对于提交给应用（甚至开发分支）的每个更改，都会自动且连接的进行构建和测试，以确保所引入的更改通过为应用程序建立的所有测试、准则和代码合标准。

GitLab本身就是使用持续集成作为软件开发方法的示例。每次推送更改到项目时，都会使用一组脚本来检查代码。

2.2 持续交付（CD）

持续交付是超越持续集成的进一步。这时，我们的应用不仅会在每次推送更改到代码库时都进行构建和测试，通过额外的手动触发，仍然会持续部署。

在这一次方法中，可以确保自动代码检查，但需要人工干预才能从策略上手动触发更改的部署。

2.3 持续部署（CD）

类似于持续交付，持续部署也是超越持续集成的又一步。不同之处在于，无需手动部署，而是将其设置为自动部署。应用的部暑完全不需要人工干预。

3. GitLab CI/CD 介绍

GitLab CI/CD是GitLab内置的功能强大的工具，它使你可以将所有持续方法（持续集成、交付和部署）应用于软件开，而无需第三方应用或集成。

3.1 GitLab CI/CD 是怎么工作的

要使用GitLab CI/CD，首先需要将应用代码托管到Git存储库中，并在你代码存储库根目录下的.gitlab-ci.yml文件中指定构建、测试和部署脚本。

在这个文件中我们可以：定义要运行的脚本、定义包含和缓存依赖项、选择按顺序执行的命令及并行运行的命令、定义要部署应用的位置、以及指定是否自动运行或手动触发脚本。熟悉GitLab CI/CD后，可以在配置文件中添加更多高级步骤。

要将脚本添加到该文件中，需要按适合你应用并符合你要执行的测试的顺序来组织它们。为了可视化该过程，假设添加到配置文件中的所有脚本与在计算机的终端上运行的命令相同。

将.gitlab-ci.yml配置文件添加到存储库后，GitLab将检测到该文件并使用名为GitLab Runner的工具运行脚本，该工具的作用与命令行终端类似。

这些脚本被分组作业(job)，它们共同组成了管道(pipeline)。以下是一个简单的.gitlab-ci.yml示例我，其可以包含：

before_script:
  - apt-get install rubygems ruby-dev -y

run-test:
  script:
    - ruby --version

在以上配置文件中，before_script属性将在所有内容之前运行，以安装应用的依赖项，并且名为run-test的job(任务)将打印当前系统的Ruby版本。两者构成了每次推送到存储库的任何分支时，所触发的pipeline(管道)。

GitLab CI/CD 不仅会执行已设置的作业，而且还向会显示执行期间的信息，就像在终端中看到的那样：

GitLab会根据我们创建的应用策略运行管道，管道状态也会在GitLab显示：

如果执行出现问题，还可以通过GitLab回滚：

3.2 基本的 CI/CD 工作流程

接下来，我们通过以下示例来了解GitLab CI/CD是如何适合通用开发工作流程的。

假设我们已经讨论了一个问题的代码实现，并在本地进行了相关更改。将提交(commit)推送到GitLab远程存储库的相关功能分支后，会触发我们为项目设置的CI/CD管道。这样，GitLab CI/CD将会：

• 运行自动化脚本（顺序或并行）以：
  • 构建并测试应用
  • 就像在localhost看到的那样，使用Review Apps预览每个合并请求的更改

对本次实施满意后：

• 使代码可以审查和批准
• 将功能分支合并到默认分支
  • GitLab CI/CD将更改自动部署到生产环境
• 最后，如果出现问题，我们可以轻松地将其回滚

GitLab CI/CD可以做更多的事情，但是此工作流程体现了GitLab跟踪整个过程的能力，无需任何外部工具来交付软件。而且，最有用的是，可以通过GitLab UI可视化所有步骤。

深入了解 CI/CD 基本工作流程

要深入研究基本工作流程，我们可以在DevOps生命周期的每个阶段看到GitLab中可用的功能，如下图所示。

我们从左到右查看上图，可以根据软件开发周期的每个阶段（验证、打包、发布）看到GitLab中的一些可用功能。

1. 验证(Verify)
   • 通过持续集成自动构建和测试应用
   • 使用GitLab Code Quality分析代码的质量
   • 使用Browser Performance Testing确定代码更改对性能的影响
   • 执行一系列测试，如：Container Scanning、Dependency Scanning、JUnit tests
   • 使用Review Apps部署更改，以预览每个分支上的应用更改。
2. 打包(Package)
   • 使用Container Registry存储Docker映像
   • 使用NPM Registry存储NPM包
   • 使用Maven Repository存储Maven工件
   • 使用Conan Repository存储Conan包
3. 发布(Release)
   • 持续部署，自动将应用部署到生产环境
   • 连续交付，手动单击以将应用部署到生产环境
   • 使用GitLab Pages部署静态网站
   • 将功能部分提交，并让一定比较的用户通过Canary Deployments访问临时部署的功能
   • 使用Feature Flags标记后再部署功能
   • 使用GitLab Releases将发行说明添加到任何Git标签
   • 使用Deploy Boards的Kubernetes运行的每个CI环境的当前运行状况和状态视图
   • 使用Auto Deploy将应用程序部署到Kubernetes集群中的生产环境

通过GitLab CI/CD还可以：

• 通过Auto DevOps轻松设置应用的整个生命周期
• 将应用程序部署到不同的环境
• 安装自己的GitLab Runner
• Schedule pipelines（定时管道）
• 使用Security Test reports检查应用程序漏洞

3.3 首次设置GitLab CI/CD

要开始使用GitLab CI/CD，你需要熟悉.gitlab-ci.yml配置文件的语法及其属性。

文档在GitLab Pages范围内介绍GitLab CI/CD概念，通过部署静态网站介绍了GitLab CI/CD相关概念。虽然其通过从头编写自己的Pages脚本为示例，但也可以作为GitLab CI/CD设置过程的简介。它涵盖了编写CI/CD配置文件的最初一般步骤，因此建议阅读该文档以了解GitLab CI/CD逻辑，并学习如何为任何应用编写自己的脚本（或调整现有脚本）。

了解 GitLab CI/CD配置选项，请参考完整的：.gitlab-ci.yml文档。