小团队前端部署演化之路
前言
前端部署相对来说其实是一件非常容易的事情，无论是最原始的html页面，还是现在热门的三大框架，最后交付部署的时候，始终会是一些静态文件。
虽然简单，但是对于不同的团队来说，都会在不同阶段有最适合他们的方式。
下面老黄聊聊所在团队是怎么演化的。
老黄把它们划分成了3个阶段，每向下一个阶段都是为了解决上一个阶段带来的不可避免的问题。
刀耕火种时期
CICD半自动化时期
半无服务器化时期
下面依次来看看这三个阶段的内容。
刀耕火种时期
在加入团队早期，团队只有两个前端，后面才发展到六七个，团队前端的主要技术栈是vue。
每次发版的时候，都是前端同学在自己的电脑打包好相应的部署文件之后，发给某个后端同学，由这个后端同学手动放到服务器上面，早期还都是部署在IIS上面的，和部分后端站点放在同一个服务器。
明眼人应该都可以看的出问题所在，整个部署的流程是比较漫长的，出差的概率也是比较高，毕竟人为参与的环节比较多。
随着项目逐步增多，那个部署前端站点的同学几乎要奔溃的节奏，每个项目都是一天连续发好几个版本，写接口的思路老是被打断。。。
对一个初创团队，人员都不充足的情况，其实这一阶段也是必经之路了吧。
这个时候引入CICD让发布流程略微自动一点点，其实是一个比较合适的时候了，刚好又是解决团队一大痛点的好东西。
老黄这边是采购了3台突发性能的4c4g的服务器。2台用于搭建jenkins，一台用于部署前端站点。
可能有人会问为什么要用突发性能的服务器，成本呀成本呀，这个是最实在的原因。
前端站点有CDN在前面挡着，回源到服务器的很少，这也是为什么敢如此大胆的用突发性能的机器来部署前端站点。
CICD半自动化时期
在这个时期其实就是简化部署操作，各自负责各自的项目。在快速的迭代过程中，前端同学负责自己对应项目的版本发布。
这也是老黄一直在推崇的，自己负责的项目要全权负责，至少该给开发的权限还是要给的。
为什么说是半自动化呢？因为不敢做到一提交代码就发布到测试环境，再发到生产环境，还是要有人为的点一下这个操作。
先来简单看看两张图，是怎么人为点一下的。
测试环境的部署：
生产环境的部署：
这里设置的都是参数化的，构建的时候都是看情况填写的。
拿个例子说明一下。
测试环境的流水线配置
生产环境的流水线配置
两个环境不一样的地方其实就是执行的脚本文件，以及生产环境多了一步刷新CDN的操作。
老黄是给每个不同的项目都编写了对应的脚本文件，每个项目会包含下面的几个文件。
其中Dockerfile就是用来编译源码和把生成的静态文件放到nginx里面。
nginx.config 就是nginx的配置文件了。
run.sh 是用来替换占位符，从而达到一个镜像，通过环境变量的方式去请求不同环境的接口。
buildtest.sh 主要就是打包好镜像，上传到阿里云容器服务，ssh到测试服务器，拉镜像，起容器。
buildprod.sh 主要就是ssh到生产服务器，拉镜像，起容器。
在这一阶段其实一切都是运行正常的，各位前端同学的反应也比较不错。
这里是以镜像的方式交付部署的，每次生成好镜像后都是push到阿里云的容器镜像服务。
这里始终是占着服务器资源，除了要自己维护域名端口的绑定之外，还要受限于阿里云单个负载均衡的域名个数。
前一段时间想在负载均衡里面添加一个新域名的时候，发现了这个无奈的问题。
买多一两个负载均衡是可以解决眼前这个问题的，但是不是长久之计。
所以还是决定走前端部署比较地道的一种方案，往无服务器时代的演进了。
半无服务器化时期
本来是想叫无服务器化时期的，不过想到jenkins还是自建的，所以在前面加了一个半字。
这里是借助阿里云的对象存储来完成的。
这里其实是只对CICD发布的对象调整一下就好了，对前端同学来说是无感知切换的。
buildtest.sh调整如下：
调整之后，交付只能是用文件的方式了，这里是将每次发布之后的文件保存一份到本地，保留最近2个月，当然，这里也可以保存到OSS的另一个bucket上面，不过现阶段似乎不太迫切。
发布之后，文件就会被上传到OSS上面了。
上传之后，还要配置三个地方，才算是真正的完成，这三个配置是一次性的。
首先是基础设置里面的静态页面，设置一下默认首页
其次是在传输管理的域名管理里面绑定域名，证书和CDN在这里是选填的。
最后一步是把域名CNAME到OSS的域名
到这里就已经是完成了最后的部署了，后面发版本的时候，只需要通过jenkins把编译好的静态文件丢到对象存储就可以了。
总结
老黄经历的这三个时期，应该有不少人也会有类似的感觉或经历。
在遇到痛点难点的时候，想办法解决掉就可以了。
对于前端站点的部署，最简单直接的办法的还是直接托管到云上面，可以省掉很多不必要的麻烦。