为什么要做

今年4月份，开始自己的第二份工作，习惯了老东家如丝般的发布体验，一下子感觉来到了“原始社会”。首先这是一篇长文，主要介绍自己在做自动发布这个过程的一些思考。

引用玉伯的Web研发模式演变来说，现在我们处于 - Web1.0时代：

遇到这种情况，首先会想到的肯定是前后端分离。但考虑到目前的人员、技术储备情况，直接过渡到基于NodeJS的全栈式开发，阻力大，周期长，很可能会难产。

而我们首要要解决的问题是：

所以我们暂时先做到前后端物理分离，大致如 - Web2.0时代

代码仓库分离，分开维护
发布部署分离
模板由前端维护，在浏览器渲染，后端只提供基础页面容器（视情况而定）
- 交互性、非SEO页面：后端负责接口，前端负责展现，通过接口读取数据在浏览器端渲染
- 需要SEO的页面：相关模板还是放在后端，但是会减少业务逻辑

目标

我们先从开发、发布流程来看我们最终希望的结果是什么，然后再分析如何完成这一目标

首先聊一下一般发布的流程：

这是一些纯体力活，要保证步骤顺序和正确性，容易出问题，而且没有记录和日志，所以一般做权限控制，发布个普通需求还要找对应的同学发布，变更麻烦

所以发布必须自动化，网上搜前端自动化发布，大多数的结果都是Jenkins + githook （ Jenkins+github 前端自动化部署）

其核心原理主要是通过

但是如果我想要查看发布记录、回滚、控制发布流程，看起来Jenkins就帮不上忙了（可能有对应的插件，没深究）

同样的发布脚本，用node也能执行，所以我们打算使用node来写一个发布集成服务来代替Jenkins，它可以做更细致的控制：

所以我们的发布自动化主要做三个东西

该CLI是一套标准的前端开发生命周期命令，通过几个子命令去完成前端开发流程的各个任务，包含了：

init：初始化项目结构，类似于vue-cli init，不过比较入门简单（因为暂时业务的体量并不需要频繁创建新项目）
dev：启动开发调试服务，主要是npm run dev，也不是重点
publish：发布项目代码，执行publish后将执行项目仓库中对应开发分支下的代码发布任务。在云端构建后的代码最终会发布到对应的环境（SIT、UAT、生产）。