持续集成需要长久的不断的完善规范，但自动部署可是能够立竿见影的见效的东西了。
这个东西虽然是运维的工作，但在实际生活中，我们每个开发者都可以学一手。
通过自动化部署，我们可以省去很多运维的人力。
正文
自动化部署，也有个说法叫CD（CD-continuous deployment，持续部署）。
这两者可能在细分的含义上有点区别，但总的来说，这都是为了工程提速提出来的概念。
严格意义上来说，自动化部署是CD（CD-continuous deployment，持续部署）的一种手段。
目前，市面上已有的手段我这里稍微列举下。
- github提供git flow，通过git Action实现自动化部署
- 国内，阿里云的云效平台，腾讯云的coding，码云平台都有自己的自动化流程工具
- gitlab提供的工作流，不过这个流程需要用户需要懂很多自动化部署的工具，如docker，JENKINS等。
市面上常规的手段大多是以上介绍的内容，大多通过以上手段，搭建一套自动化部署的管线，缩减手动部署的时间和人力损耗。
通过让机器去处理重复事务的手段，让开发者更专注于开发和思考，不必被这些繁琐重复的事情所拖累。
持续部署
持续部署，也就是CD（CD-continuous deployment）。
是基于某种工具或平台实现代码自动化的构建、测试和部署到线上环境以实现交付高质量的产品。
持续部署在某种程度上代表了一个开发团队的更新迭代速率。
持续部署是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。
持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。
注：持续部署的前提是能自动化完成测试、构建、部署等步骤。
个人DevOps
DevOps这个词也是最近两年的招聘要求和社区中频繁出现。
这个词如果不深究其含义的话，其实就是Development（开发）和Operation（运维）组合而成的新词汇。
当然，DevOps里边的玩法不仅仅是我字面上说的这么简单，大多数公司都是用gitlab部署了自己的工作流程，然后需要自己用docker，JENKINS等方式搭建自己的自己自动化流程。
这个流程较为麻烦，我们今天这里不去详解用docker搭建自动化流水管线那一套，那个太过麻烦，很多人如果不对安全有有要求的话，未必用的上。
本次，通过github Action实现文档的自动化发布，以此为例，大家可以将这套流程应用在码云，云效等平台。
毕竟，这些成熟的自动化流程管线大多相差不多，都很好用。
Github Action
参考这篇：作为前端 leader，怎么快速搭建多环境CICD自动化部署？ - 掘金 (juejin.cn)
我通过Github Action的工作流，实现了部署自动化，在部署完成后，还可以通过外部的微信机器人告诉我，具体哪个项目已经完成更新。
而且，Github Action简单易用，非常的好上手，如果你是之前没用过这种自动化部署的流程的新手，非常推荐入门使用。
功能介绍
- 推送主分支后，自动部署项目到服务器
- 部署完成后，通过公众号通知部署成功
配置脚本
这一套流程是从别人那边上边的参考文档中套过来的，基本上和HEXO博客的自动部署发布类似，写的非常清楚简单。
稳定好用，这里推荐给大家使用，如果要是有需求，其实也可以考虑用GPT帮忙写流程。
name: 更新文档到服务器
on:
push:
branches:
- main
# 推送之后执行一系列的任务
jobs:
build:
runs-on: ubuntu-latest
steps:
# 获取代码
- name: 迁出代码
# 使用action库 action/checkout获取代码
uses: actions/checkout@main
# 安装Node环境
- name: 安装node.js
# 使用action库 actions/setup-node安装node
uses: actions/setup-node@main
with:
node-version: lts/*
# 安装依赖
- name: 安装依赖
run: npm install
# 打包
- name: 打包
run: npm run build
# 上传到腾讯云
- name: 发布到腾讯云
uses: easingthemes/ssh-deploy@main
env:
# 私钥
SSH_PRIVATE_KEY: ${{ secrets.PRIVATE_KEY }}
# SCP参数
ARGS: '-avzr --delete'
# 源目录
SOURCE: 'docs/.vitepress/dist/'
# 服务器ip
REMOTE_HOST: ${{ secrets.REMOTE_TXHOST }}
# 用户
REMOTE_USER: 'root'
# 目标地址
# TARGET: '/var/www/html'
TARGET: '/usr/local/lintdoc'
# 推送信息到微信
- name: 推送信息到微信
uses: easychen/github-action-server-chan@main
with:
sendkey: ${{ secrets.SERVER_J }}
title: '项目更新！Ciallo～(∠・ω< )⌒★'
配置KEY
在实现功能之前，我们先做一些准备，以github为例，我们需要配置项目setting中的内容。
我们进入setting > secrets and variables > Actions的目录下，设置如下三个配置项
- PRIVATE_KEY，私钥，用来配对服务器上的公钥
- REMOTE_TXHOST，服务器地址
- SERVER_J，方糖服务号提供的SendKey，需要先微信关注，获取对应的SENDKEY之后，添加到github的Action中
这里可能有些新手不清楚上边说的一些概念，这里先简单解释一下，后续会专门的就这些内容出文章仔细解释这些概念。
私钥与公钥
自动化部署，我们显然不该把自己的IP扔到流程上，那么，我们也要把服务器密码放在流程上吗？
显然，这种流程不可能将密码放在流程中裸奔，如此，我们需要将密码进行一个处理，这就是我们说到的私钥公钥。
这里打个不恰当的比方，私钥是电子门卡，公钥是电子锁。
公钥作为电子锁，谁都能看到，但如果没有电子门卡，自然就无法打开电子锁。
而我们自动部署，将私钥放在流程中，每次自动部署，就是将私钥丢给公钥解锁，连接服务器之后，自动部署。
这里要注意，私钥是本人需要保存的答案，是公钥的唯一解，请注意保存。
setting安全性
有些人可能会担心，如果我写了一个开源项目，项目中配置好的key会泄露吗？
这个可以不用担心，因为在yml的文件中，写的都是你配置的key，即便别人看到你的源码，也不用担心他人会发现你的配置项的内容。
而这些开源项目的setting不会被外部访问，除了当前项目的主导者，其他人无法访问到这个项目的setting里的配置。
因此，安全性是不用担心的。
使用场景
github action 这套流程，应该是目前我看过的所有管线中最成熟的一套了。
但是，github因为不在境内，而且出于安全性的考虑，很多公司项目都不会部署在github上。
因此这套流程大多都是用来放一下个人项目，大概应用场景如下。
- 文档类项目，如个人博客，团队规范，使用说明等
- 开源项目的自动化部署，可以用来部署开源项目的Demo和wiki
结语
最近因为个人生活的问题，本来想整理更详细的，将云效平台的部署流程也放上来。
但是时间实在不允许，所以这里就简单整理了一下github的部署。
后续如果时间允许，我会整理其他类型的自动化部署方式，如果文中写的有什么不对的地方，欢迎大家在评论区中指出。
参考
前端项目自动化部署——超详细教程（Jenkins、Github Actions）
作为前端 leader，怎么快速搭建多环境CICD自动化部署？
GitHub Actions 入门教程 - 阮一峰的网络日志 (ruanyifeng.com)
打造前端自己的CI/CD集成环境 - 掘金 (juejin.cn)
DevOps概念及搭建全过程（Jenkins、Harbor、SonarQube、K8s）_devops流程-CSDN博客
