持续集成需要长久的不断的完善规范,但自动部署可是能够立竿见影的见效的东西了。
这个东西虽然是运维的工作,但在实际生活中,我们每个开发者都可以学一手。
通过自动化部署,我们可以省去很多运维的人力。
正文
自动化部署,也有个说法叫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博客