前言
前端项目的工程化，不只是对开发层面的组件化、模块化、规范化等，更涉及到构建、部署的工程化和自动化。
工程化的一些概念，编译、构建、部署、发布、CI/CD 、灰度等概念，其实都是软件工程中很成熟的概念。
大部分知识在前后端项目中都是通用的，有些则根据项目有所不同之处。
名词解释
- 编译和构建
- 构建产物（Artifacts）
- 部署、发布
- 蓝绿部署、滚动部署、金丝雀发布（灰度发布）、A/B测试
1 编译（compile）和构建（build）
编译是指将源代码变为目标代码的过程，从源代码的语言转变为另外一种计算机语言（一般比源代码语言更为底层的语言）。
构建是指一系列的处理，包括编译。不同的语言构建会有不同的处理步骤，最终产生可在具体特性环境运行的构建产物（Artifact）。
前端的编译 为了更好的编程体验和更高的可维护性，会使用一些超集的语言，然后再转译为浏览器可以运行的语言。例如es5/6/7等语法的转译为对应环境支持的代码；less，sass等转译为css；typescript等转译为JavaScript。
前端构建过程一般包括以下几个过程：
- 代码检查
- 运行单元测试等
- 语言编译
- 依赖分析、打包、替换等
- 代码压缩、spirit图片压缩等
- 版本生成
构建结果一般生成一个或多个文件，里面包括直接可以部署在特定环境中的所有内容。
2 Artifacts (构建产物)
每一次成功构建后产出的记过，被称为Artifacts。Artifacts可以直接部署在特定环境中并正常运行。每个构建结果一般都会版本保存，为后续部署、回滚、灰度等做备份。
可能是因为构建的速度，后端都会有一个Artifacts制品库。而早期一般的前端项目对Artifacts的概念比较弱化，一般会从Code直接构建部署到指定的环境。现有的规范化的项目都会对构建产物所有版本进行保存，一般都提供CND来访问。
3 部署、发布
部署（deploy）是指把构建后的新版本应用或服务 安装到目标环境（开发、测试或者生产）中。
这时候部署好的应用或服务应该在目标环境中正常运行着，但是不会有任何访问的流量。
发布（release）则是把新版本应用或者服务交付给最终用户使用的过程。相当于把流量切到部署好的新版本的过程。
前端项目部署一般是指文件的增量替换或全量替换。根据项目按需决定，部署和发布可以同时进行，也可以分开进行，在不影响用户访问的前提下，把前端的代码更新到相应的版本。
4 CI/CD
CI Continuous Integration 持续集成。指代码继承到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。目的就是让产品可以快速迭代，同时还能保持高质量。
CD，Continuous Deployment，持续部署。持续部署是持续交付的更高阶段，指的是任何修改后的内容都经过验证，自动化的部署到生产环境。
两者的区别，在于是否自动部署到生产环境。持续交付，需要用户手动点击“部署”按钮才能部署到生产环境。
前端项目的 CI/CD ，因为一定的特殊性，对通用化的库或框架可以有覆盖率很高的单元测试/自动化测试，然而对业务代码的单元测试、端对端测试则成本很高，所以 CI 的过程一般就是运行构建脚本，未报错的生成静态文件则为成功。一般不会有 CD（持续部署） 的过程，合并到 develop 分支触发 CI 成功后快速发布部署到测试或预发布环境通过测试人员的测试和一定的自动化测试。到需要发布的时间点，再拉取 master 分支来构建部署发布。
蓝绿部署、滚动部署、金丝雀发布（灰度发布）、A/B测试
蓝绿部署
蓝绿部署中，绿色代表代表正在给用户提供正常服务的系统；蓝色代表另外一套准备发布的系统，还未对外提供，可以做线上测试。
二套系统必须有相同的基础设置和配置环境，当蓝色系统测试通过，达到上线标准，就把绿色系统的流量全部切到蓝色系统中，一旦蓝色系统出现问题，把所有流量切回到绿色系统中，待蓝色系统稳定后就成为新的绿色系统，之前的绿色系统资源就可以释放用于下一个蓝色系统。
蓝绿部署能够简单快捷实施的前提假设是目标系统是非常内聚的，如果目标系统相当复杂，那么如何切换、两套系统的数据是否需要以及如何同步等，都需要仔细考虑。
滚动部署
有多个集群实例的服务中，在不影响服务的情况下，停止一个或多个实例，进行版本更新，再启动加入到集群中提供正常服务，直到所有实例都更新到最新版本。
比起蓝绿部署不需要准备二套一样的集群，通过现有的机器或增加少量的机器就可以做到版本升级。但也引入了复杂度，需要控制好更新过程中服务会有新老版本用户共存的兼容情况、防止部署过程中自动伸缩的触发导致实例中版本的不确定、部署过程中出错的回滚策略等。
金丝雀发布（灰度发布）
一种比滚动部署更有控制力度的发布策略。
准备一个或多个服务实例（使用新机器或已有的机器都可），并确保该实例服务没有服务于线上的用户，在上面部署新版本的服务，并经过测试的验证。
通过定制好的策略，只更新部分服务实例到最新，使一部分用户使用到最新版本，如果服务正常，逐渐更新所有服务实例到最新。
发布过程中，需要有一些流量控制的策略跟随部署的过程，一般可以在负载均衡、路由、应用程序中做处理。
针对用户级别分流。比如先部署给内部用户，在逐渐根据外部用户的分类等级扩散。
地域、IP 级别分流。只部署新版本到某地理地域，慢慢扩大到全量发布。
应用程序中判断特性分流。比如通过什么渠道使用服务的、浏览器特征分析、某个使用触发才使用新版本。
A/B测试
A/B测试指的是效果测试，同一时间有多个版本的服务在线上运行，并通过一定的策略控制多个版本的流量分配，最终通过信息的收集，分析各个版本服务的实际效果，选出效果最好的版本。
A/B测试强调的是通过不同版本对比效果来选择出最好的版本，而然金丝雀发布（灰度发布）的方式正好可以满足A/B测试的需求
构建和部署
现有的CI/CD方案都很成熟，Jenkins、Gitlab-CI等。docker、k8s让这些工具简直带上了无限手套，因为构建部署是需要机器资源的，相比之前固定的资源抢占和空置，k8s让资源动态创建、销毁，提升资源利用率。
网友评论