CI/CD Pipeline

type

status

date

slug

summary

什么是CI/CD？

CICD的目标是提高软件交付的质量和效率，减少手动操作，缩短发布周期，降低风险和成本，并使开发团队能够更快地获得反馈和修复错误

CI/CD 的核心概念是代码集成、应用发布, 让自动化和监控贯穿于应用的整个生命周期。主要针对在合并新代码时所引发的问题，关联的动作通常被统称为 CI/CD 管道，由开发和运维团队以敏捷方式协同支持。

持续集成（Continuous Integration）

有助于发现和解决代码集成问题，保证代码质量和稳定性

问题

多分支同时开发，代码冲突是难以避免的

本地环境与线上环境不一致

如何解决问题

一旦开发人员将改动的代码合并到主分支，系统就会通过自动构建应用，并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证这些更改，确保这些更改没有对应用造成破坏。

如果自动化测试发现新代码和现有代码之间存在冲突，CI 可以更加轻松地快速修复这些错误。

CD（Continuous Delivery/Deployment）

将CI的成果自动部署到生产环境或预生产环境，包含持续监控，确保软件能够交付和运行

有两种不同程度的自动化：

自动把已验证的代码发布到一个存储库，旨在建立一个可随时将开发环境的功能部署到生产环境的代码库，后续由运维团队将其部署到实时生产环境中

自动将开发人员的更改从存储库发布到生产环境，以供客户使用

主要区别在于，需要手动批准才能更新到生产环境

Github Action

当我们想往自己的项目里接入Github Actions时，要在根项目目录里新建.github/workflows目录。然后通过编写yml格式文件定义Workflow(工作流程)去实现CI

Workflow中一些比较重要的概念：

Event(触发事件)：指触发 Workflow(工作流程) 运行的事件。

Job(作业)：一个工作流程中包含一个或多个Job，这些Job默认情况下并行运行，但我们也可以通过设置让其按顺序执行。每个Job都在指定的环境(虚拟机或容器)里开启一个Runner(可以理解为一个进程)运行，包含多个Step(步骤)。

Step(步骤)：Job的组成部分，用于定义每一部的工作内容。每个Step在运行器环境中以其单独的进程运行，且可以访问工作区和文件系统。

工作区（Workspace）：

工作区是 GitHub Actions 中的一个虚拟环境，用于执行你的工作流程中的任务和操作。

每个工作区都会在工作流程开始时创建，并在工作流程结束时销毁。

工作区是一个临时的存储位置，可以用于存储和处理工作流程所需的文件和数据。

工作区中包含一个虚拟的文件系统，允许你在其中操作文件。，这些更改不会影响你的代码仓库。

一个Workflow例子：

整个learn-github-actions工作流程弄成低代码可视化可如下所示：

CI 示例

master分支，广义上是一个包含多个已上和即将上线的特性的分支

github flow在开发新特性的运行模式如下所示：

开发期间，定期提交更改(commit and push change)到远程仓库的feature分支（后续写的新代码再开新的feature分支）

在编码以及自测完成后，通过创建pull request去对master发起合并feature的请求pull request

在经过审核确认可行后合并到master分支

删除已合并的特性分支feature

💡

核心：在集成代码前通过pull request，从而触发审核（审核可以是一系列的自动化校验测试（包括代码规范）以及代码审核Code Review），在审核通过后再合并到主干在Workflow中，定义Event是master分支的pull request事件

CD 示例

主要有三个步骤：

Build 更新后的源代码

自动部署到测试环境以校验其稳定性

自动部署到生产环境

一些私密信息放在代码源仓库的 Secret 里，在 Workflow 运行时这些Secret会以环境变量的形式注入到Runner里

💡

我们把CD Workflow的Event定义为master分支的push事件，因为CD Workflow的执行是在Merge pull request完成后的，而合并行为会触发主干的push事件。

❗

注意：每次提 pr 时要确保 package.json 中的 version 值有变化，不然 CD Workflow 会在 Create GitHub Release 的步骤里报已存在 Tag 的错误。

完善篇

Rollback Workflow的触发条件Event我们选择workflow_dispatch ，这个事件还能支持手动输入信息，然后把这个信息当作环境变量供整个Workflow读取

消息提醒

因为前端、后端、数据库同样会影响端对端测试的运行结果，因此在后端迭代发布或者数据库变更后，也要手动触发运行端对端测试以保证项目的稳定性。

多环境CI/CD

搭建多环境 CI/CD 需要综合考虑成本、服务器选择、CI/CD易用度、可扩展等方面

免费使用的 CICD 平台：Github Actions

这里我们给一个 vitepress 静态站点和一个 koa.js + mongodb 接口服务搭建多环境、多版本自动化部署（本文暂不涉及 gitlab、Jenkins、docker、k8s 等）

项目类型	源码地址	DevOps平台	部署在哪	多环境
前端静态站点	Github	Github Actions	OSS	测试/生产
后端接口服务	Github	Github Actions	ECS	测试/生产
ㅤ	ㅤ	ㅤ	ㅤ	ㅤ

OSS

OSS 是对象存储的意思，一般一个项目对应一个 Bucket (存储桶)，可以通过一个地址来访问里面的文件

静态站点部署在OSS上

前后端部署服务位置分离，防止服务器被 ddos 攻击后，静态站点、接口服务全挂掉

多环境

创建两条流水线，一条测试环境使用、一条生产环境

正式环境（线上）只能部署主分支，测试环境部署对应的版本分支。

测试验证通过后，以提交 Pull Request 的方式合并代码，这样可以通过 merge 历史记录进行整个版本代码的 code review。

新版本代码 merge 到主分支后，再部署到预发、再次测试后即可正式发布，每次上线后记得打版本 tag，也可通过脚本自动打 tag。

参考资料

作为前端，要学会用Github Action给自己的项目加上CICD - 掘金

前言这是一篇属于面向前端的关于CICD和Github Action的入门文章，其旨在：入门掌握Github Action的用法学习CI和CD的含义及其实现细节基于Github Action展示

https://juejin.cn/post/7113562222852309023?searchId=2023100722025657BD43FBE00029A022F2

作为前端 leader，怎么快速搭建多环境CICD自动化部署？ - 掘金

假设你入职了一家小公司，既没有内部自研的 DevOps 平台，也没有专业的运维。需要你自己去搭建多环境 CI/CD 自动化部署，你会怎么做？

https://juejin.cn/post/7250083673189253176?searchId=2023100722025657BD43FBE00029A022F2

Docker

打包

Docker从入门到部署项目 - 掘金

Docker是一个开源的应用容器引擎，它是基于Go语言并遵从Apache2.0协议开源。Docker可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的机器上

https://juejin.cn/post/7266721485812547625?searchId=202310072340495329B9E645C09E92A7D8