点击上方蓝色字体,关注我们
预告: 《GitLabCI/CD实践》教程在路上,敬请期待!
本教程的目的是对GitLab CI / CD进行介绍,本教程适用于希望尝试使用CI / CD工具(如GitLab CI / CD)的初学者。在本教程中,我将简要介绍什么是CI / CD,为什么决定使用GitLab的工具以及有关如何.gitlab-ci.yaml
使用示例应用程序创建的演练。
CI/CD基础概念
+
CI / CD是持续集成/持续交付/持续部署的缩写。它使团队可以更快地构建,测试和发布软件。CI / CD消除了手动的人机交互,从而使最终的手动代码部署到生产过程之外的一切都实现了自动化。实施此实践的挑战之一是集成构建CI / CD管道所需的各种工具和系统。
为什么选择GitLabCI/CD?
+
使用GitLab CI / CD的原因有以下三个:
可以使用一个工具构建完整的CI / CD管道,它既快速又开源。在同一应用中使用GitLab CI / CD,可以创建凭证,合并请求,编写代码和设置CI / CD工具,而无需其他应用程序。它本质上是一站式DevOps。
GitLab CI / CD在GitLab Runners上运行。Runner 是一台独立的机器,运行通过GitLab CI API定义的流水线步骤。与在单个实例上运行相比,单独使用此工具可使项目在管道构建过程中运行得更快。
它是开源的,因此可以随时为代码库做出贡献,并在出现问题时提出新的问题。
需求场景
+
假设我们有一个Node.js API,可以检索数据库中的书籍列表。我们可以创建一个包含三个阶段的管道:构建,测试和部署。管道是一个或者多个不同的步骤组成的,在这些阶段中,我们的管道由三种类型定义:
项目管道
持续集成管道
部署管道
该项目管道用于安装依赖,运行脚本处理的代码。在持续集成管道运行自动化测试和代码构建。最后,部署管道将代码部署到指定的环境。
这三个管道执行的步骤称为作业。通过这些特征将一系列作业分组时,称为阶段。作业是管道的基本构建块。可以将它们分阶段组合在一起,也可以将各个阶段组合成管道。这是作业,阶段和管道的示例层次结构:
A.) Build i. 安装NPM依赖 ii. 运行ES-Linter iii. 运行 Code-MinifierB.) Test i. 运行测试 ii. 编译构建C.) Deploy i. 发布 1.) 测试环境
在此层次结构中,所有三个组件均被视为三个不同的管道。主要项目符号(构建,测试和部署)是阶段,这些部分下的每个项目符号都是作业。让我们将其分解为一个GitLab CI / CD yaml
文件。
使用GitLabCI/CD
+
要使用GitLab CI / CD,请在您的GitLab存储库中的项目根目录下创建一个名为.gitlab-ci.yml
的文件,并添加以下内容yaml
:
image: node:10.5.0
stages:
— build
— test
— deploy
before_script:
— npm install
如上所述,GitLab CI / CD使用运行程序来执行管道。通过使用image
指令,我们可以定义希望基于Runner的操作系统和预定义库。在我们的实例中,我们将为Runner使用最新版本的Node.js。该stages
指令使我们可以预定义整个配置的阶段。作业将根据stages
指令中列出的顺序执行。该before_script
指令用于在所有作业之前运行命令。
现在让我们开始致力于Build阶段的工作。我们要称这项工作build-min-code
。在这项工作中,我们希望它安装依赖项并减少代码。我们可以使用script
指令开始。该script
指令是在Runner中执行的Shell脚本。然后,我们将把这项工作分配到“构建”阶段。要将作业分配给阶段,请使用stage
指令。
build-min-code:
stage: build
script:
- npm install
- npm run minifier
现在我们有一个与Build阶段相关的工作,我们将在Test阶段进行。我们的测试工作将被调用run-unit-test
,我们将使用API中的npm脚本来运行测试npm test
。
run-unit-test:
stage: test
script:
- npm run test
最后,我们将添加一个任务来处理我们的部署阶段:deploy-production
,deploy-staging
。在这种情况下,我们将有两个不同的部署工作(预生产和生产)。这些工作将反映与我们以前的工作相同的布局,但是变化很小。当前,我们所有的作业都自动设置为在任何代码推送或分支上触发。当我们将代码部署到预生产和生产环境时,我们不希望这样做。为了防止这种情况的发生,我们使用了only
指令。该only
指令定义了要为其运行作业的分支和标签的名称。该工作将如下所示:
deploy-staging:
stage: deploy
script:
— npm run deploy-stage
only:
— develop
deploy-production:
stage: deploy
script:
— npm run deploy-prod
only:
— master
在我们的deploy-staging
工作,如果有一个变化的分支将只执行它develop
的分支和deploy-production
该master
分支。这是下面的屏幕截图,显示了对该master
分支进行的代码推送。
从此镜像中,所有三个阶段和作业都被触发,但deploy-staging
由于代码推送到了master
分支。GitLab CI / CD带有直观的界面,可帮助显示正在运行的作业和阶段以及在构建过程中发生的错误。下面是.gitlab-ci.yaml
文件的最终版本。如果您希望自己进行测试,请参见示例应用程序的链接。
image: node:10.5.0
stages:
- build
- test
- deploy
before_script:
- npm install
build-min-code:
stage: build
script:
- npm install
- npm run minifier
run-unit-test:
stage: test
script:
- npm run test
deploy-staging:
stage: deploy
script:
- npm run deploy-stage
only:
- develop
deploy-production:
stage: deploy
script:
- npm run deploy-prod
only:
- master
上面介绍的项目是GitLab CI / CD可以提供的功能的高级概述。通过构建和发布Docker映像以与第三方工具集成,GitLab CI / CD能够对代码库的自动化进行更深入的控制。希望本教程对您有所帮助。谢谢阅读!
如果你对GitLabCI/CD感兴趣,不妨听听上周的分享。{每周末都会直播分享}
详细介绍为什么使用GitLabCI/CD。[订阅上面分享后这个可以忽略]