以前接触到这些词时，总是认为这些词离自己很远，自己永远也接触不到，当然曾经也出于好奇有上网了解过这些词的意思，不过在看了几篇文章之后，大抵都是泛泛而谈一些虚无缥缈的概念，于是看了忘，忘了看，看了又忘…还是没了解透这些新技术的作用。

最近，不管是开源项目维护，还是恰饭用的学校项目，或者是个人项目，都在同时并进。在和老师对接了一版Web项目之后，突然萌生了一个想法，如果Web项目在push上git分支之后，能够有一个python脚本定时获取分支状态，并且自动拉取并部署，对接流程就会变得非常方便。突然想到GitHub Actions这个功能，于是浅试了一下，上网一搜，恍然大悟，原来CI/CD就是干这事的。

CI

CI的全称是持续集成（Continuous Integration）。

顾名思义，就是专门有一个服务，能够在开发者push代码到分支上后，自动（或者根据条件触发，条件可以是commit的内容的前缀等等）将其合并到主分支，并执行构建、单元测试等功能，最后再通知给开发者执行结果。

这个图很好地解释了CI的整个流程：

比如我有一个Python项目，在我推送代码到dev分支后，CI服务就能够帮我执行自动化流程，比如检查我的python程序有没有语法错误、有没有代码规范错误等等。非常方便，减轻了开发者们的负担。

CD

CD的全称是持续部署（Continuous Deployment）。

同理，CD服务能够帮我们自动部署构建好的项目到对应的服务器/容器/平台上。

DevOps

以我个人经验来看，我所认为的DevOps就是能让开发者和运维人员更好对接项目的一个东西，具体实现可以是一个含有CI/CD、报警监控、两队人互相协作的平台系统。

应用

首先，CI/CD真的就只是一个概念，具体实现没有任何约束，只要它能实现一个基本目的：简化构建、测试、部署流程，减轻你的负担。

在GitHub或者GitLab平台上，都实装了CI功能。

想要创建一个CI服务，直接在自己的仓库上点击Actions，然后点击New workflow即可（对，非常形象，工作流）。

GitHub上提供了众多Workflow模板，并且Github会推荐最适合你项目的Workflow模板给你，你可以选择适合你的一个或多个Workflow，当然也可以自己编写一个Workflow文件。

在Workflow条件触发时，GitHub会分配一台虚机，然后执行Workflow文件中的指令。

在我的这个Web前端仓库下，我搭建了一个Workflow，Build And Deploy To Github Pages，他会在我们推送代码到main上时，自动拉取代码，并尝试npm install && npm build构建项目，构建成功后，会将dist文件夹下的文件推到gh-pages分支。gh-pages分支是GitHub的特殊分支，GitHub Pages会识别到此分支，然后我们就可以在GitHub上构建免费的静态页面。并且会送给我们一个免费的二级域名，格式为<你的github名字>.github.io/<你的仓库名>由于Vue项目的一些特殊性，我不能通过此域名成功打开打包好后的网页文件，因此用自己的域名通过CNAME，重定向到了github的这个域名上。

这有一个好处，如果不用自己的域名CNAME，那么由于同源策略，这个前端页面将不能连接到后端（其实也能，在config.js那里改一下代理即可）。如果用了自己的域名，那么就可以在自己服务器上跑后端服务，然后用nginx反代到这个域名上，实现前后端交互。

如果Workflow运行时报错，会通过邮件通知我们。我们就可以很方便快捷地知道哪出了问题。

当然除了这些仓库平台，很多互联网厂商内部早已建立起了一套成熟的DevOps流水线。

自动化！