GitLab CI/CD 是一个强大的工具,可以实现项目的自动化部署流程,从代码提交到部署只需几个步骤。本文将带你配置 GitLab CI/CD 完成一个前端项目的自动化部署。
前言
为什么使用cicd+docker?
目前我们公司开发环境使用的shell脚本部署,一是要登录服务器,二是要去手动执行脚本,要是部分同事不懂运行脚本的话还得教他,费时费力;但是搭建好了cicd之后只需要提交合并代码就会完成自动化部署不需要人工介入、使用docker是因为可以环境互不干扰(例如node14,node15,node16等不同版本都可以在一台服务器运行)
前置准备
GitLab 仓库:确保代码已经推送到 GitLab 仓库。
部署服务器:一台可以通过 SSH 访问的服务器,用于部署你的前端项目。
工具准备:GitLab Runner、docker
项目文件:.gitlab-ci.yml、Makefile、dockerfile
持续集成 (CI)
持续集成是一种开发实践,开发人员将代码频繁地合并到共享的代码仓库中,通常每天多次。每次代码合并后,都会触发自动化的构建和测试流程。
- 频繁集成:开发人员定期将新代码合并到主分支。
- 自动化测试:每次合并都会运行测试,确保新代码不会破坏已有功能。
- 快速反馈:测试失败或构建失败时立即通知开发者。
- 发现问题更快,因为每次小的更改都会被立即验证。
- 减少了“大规模集成”带来的风险和时间消耗。
持续交付 (CD - Continuous Delivery)
持续交付是在持续集成的基础上,进一步自动化了将软件交付到生产环境之前的所有流程。代码在通过构建和测试后,自动部署到一个可运行的环境(通常是预发布环境),但部署到生产仍需要手动触发。
- 自动化部署:代码经过验证后可以自动部署到预发布环境。
- 人为审核:生产环境的部署通常需要手动批准。
- 可随时交付:开发团队确保软件在任何时间点都可以部署到生产。
- 缩短了发布周期。
- 提高了软件交付的可靠性和稳定性。
- 可轻松在不同环境(如开发、测试、预生产)中验证软件。
持续部署 (CD - Continuous Deployment)
持续部署是持续交付的进一步延伸,完全自动化了整个交付过程。通过所有测试的代码会自动部署到生产环境,无需人工干预。
- 全自动化:不需要人为批准,代码直接进入生产环境。
- 高测试要求:需要非常可靠的自动化测试体系。
- 快速交付:代码从开发到上线的周期极短。
- 开发团队可以快速将新功能交付到用户手中。
- 减少人为操作导致的错误。
- 提高了产品的敏捷性。
GitLab Runner 是什么?
GitLab Runner 是一个开源的应用程序,用于执行 GitLab CI/CD 中定义的任务(也称为作业)。它是 GitLab CI/CD 的核心组件之一,用于从 GitLab 获取作业、执行作业,并将结果反馈给 GitLab。
GitLab Runner 的功能
执行 CI/CD 流水线作业:从 .gitlab-ci.yml 文件中获取任务配置并执行。
支持多种执行器:支持不同的环境运行作业,如 Docker、Shell、Kubernetes 等。
跨平台支持:可以安装在多种操作系统上,包括 Linux、Windows 和 macOS。
分布式运行:可以在多个 Runner 上并行执行流水线任务。
负载均衡:当有多个 Runner 注册到 GitLab 项目时,任务会自动分配。
GitLab Runner 安装
GitLab Runner 教程
部署
.gitlab-ci.yml教程
要使用 GitLab CI/CD,您需要:
- 托管在 Git 仓库中的应用程序代码。
- 仓库根目录中名为 .gitlab-ci.yml 的文件,其中包含 CI/CD 配置。
这是我自己项目中的.gitlab-ci.yml
stages:
- build # 编译
# - deploy-dev # 开发环境
- deploy-test # 测试环境
- deploy-online # 上线 - 推送镜像
build-job:
stage: build
tags:
- docker_test
variables:
GIT_CLEAN_FLAGS: -ffdx -e node_modules/
script:
- echo "Compiling the code..."
# - make build
- echo "Compile complete."
only:
- test
# - dev
build-online-job:
stage: build
tags:
- docker_online
variables:
GIT_CLEAN_FLAGS