在 介绍 GitLab CI/CD 之前,先来说一下 什么是 CI/CD。
1. CI/CD 方法论简介
软件开发的连续方法是基于脚本的自动化执行,以减少在开发应用程序时引入错误的机会。从新代码的开发到部署,它们需要的人工干预更少,甚至根本不需要干预。
这种方法论有三种主要的方法,根据最适合您的策略来应用。
(1)持续集成
考虑一个将代码存储在GitLab中的Git存储库中的应用程序。开发人员每天都要推动代码更改,一天要进行多次。对于每一次向存储库的推送,您都可以创建一组脚本来自动构建和测试应用程序,从而减少向应用程序引入错误的机会。
这种做法被称为持续集成;对于提交给应用程序的每一个变更—甚至是开发分支—它都是自动地、持续地构建和测试的,以确保引入的变更通过您为应用程序建立的所有测试、指导方针和代码遵从性标准。
(2)持续交付
持续交付是超越持续集成的一步。您的应用程序不仅在每次将代码更改提交到代码库时构建和测试,而且作为附加步骤,它还将连续部署,尽管部署是手动触发的。
此方法确保自动检查代码,但需要人工干预以手动和策略地触发更改的部署。
(3)持续部署
持续部署也比持续集成更进一步,类似于持续交付。不同之处在于,您将应用程序设置为自动部署,而不是手动部署。部署应用程序根本不需要人工干预。
2.GitLab CI/CD
GitLab CI/CD是一个内置在GitLab中的强大工具,它允许您将所有的持续方法(持续集成、交付和部署)应用到您的软件中,而不需要第三方应用程序或集成。
(1) GitLab CI/CD 怎样工作
要使用GitLab CI/CD,您所需要的只是一个驻留在Git存储库中的应用程序代码库,以及一个名为 .gitlab-ci.yml
的文件中指定的构建、测试和部署脚本,位于存储库的根路径中。
在这个文件中,您可以定义您想要运行的脚本,定义包括和缓存的依赖关系,选择你想要运行命令序列和那些你想要并行运行,定义您想要部署应用程序,指定您想要运行的脚本自动或手动触发的。一旦您熟悉GitLab CI/CD,您就可以向配置文件中添加更多的高级步骤。
要将脚本添加到该文件中,您需要按照适合您的应用程序的顺序组织它们,并与您希望执行的测试相一致。为了可视化这个过程,假设您添加到配置文件中的所有脚本都与您在计算机终端上运行的命令相同。
一旦你添加了 .gitlab-ci.yml
将配置文件发送到您的存储库中,GitLab将检测它并使用名为GitLab Runner的工具运行脚本,该工具的工作原理与您的终端类似。
这些脚本被分组到作业中,并一起组成一个管道。.gitlab-ci.yml
的一个例子:
before_script:
- apt-get install rubygems ruby-dev -y
run-test:
script:
- ruby --version
before_script属性将在运行任何程序之前安装应用程序的依赖项,而一个名为run-test
的作业将打印当前系统的Ruby版本。它们都组成了一个在每次推送到存储库的任何分支时触发的管道。
GitLab CI/CD不仅会执行你设置的任务,还会显示执行过程中发生的事情,就像你在终端中看到的那样:
您为您的应用程序创建策略,GitLab根据您定义的内容为您运行管道。你的管道状态也显示GitLab:
最后,如果出现问题,您可以轻松地回滚所有更改:
(2) 基本的 CI/CD 工作流
考虑下面的示例,看看GitLab CI/CD如何适合于一个通用的开发工作流。
假设您已经讨论了某个问题中的代码实现,并在本地处理您提出的更改。一旦将提交提交到GitLab中的远程存储库中的特性分支,就会触发为项目设置的CI/CD管道。为此,GitLab CI/CD:
- 运行自动化脚本(顺序或并行):
- 构建和测试您的应用程序。
- 使用审查应用程序预览每个合并请求的更改,就像您在本地主机中看到的那样。
一旦你对你的实现满意:
- 让您的代码得到审查和批准。
- 将功能分支合并到默认分支中。
- GitLab CI/CD将您的更改自动部署到生产环境中。
- 最后,如果出现问题,您和您的团队可以轻松地进行回滚。
GitLab CI/CD能够做更多的事情,但是这个工作流证明了GitLab跟踪整个过程的能力,而不需要外部工具来交付您的软件。最有用的是,您可以通过GitLab UI可视化所有步骤。