优秀的技术方案很多，大部分时候我们感觉只是在现有技术方案里面做排列组合、求笛卡尔积、选择最优解，做出一个最适合当前项目的方案。未来，人类应该编写最核心的业务代码、设置规则，由云端和AI来根据当前项目情况自动选择和调整到最优的架构和方案。

前言

前端项目的工程化，不只对开发层面的组件化、模块化、规范化等，更涉及到构建、部署的工程化和自动化。工程化的一些概念，编译、构建、部署、发布、CI/CD、灰度等概念，其实都是软件工程中很成熟的概念，现在前端项目中也快速发展起来。

大部分知识在前后端项目中都是通用的，有些则根据项目有不同之处。

名词解释

很多人对一些名词的理解是会有或多或少的误差的，在做一些事情之前，必然得把这些概念理解。

• 编译和构建
• 构建产物（Artifacts）
• 部署、发布
• 蓝绿部署、滚动部署、金丝雀发布（灰度发布）、A/B测试

编译和构建

编译（compile）和构建（build）概念有一些区别。

编译是指将源代码变为目标代码的过程，从源代码的语言转变为另外一种计算机语言（一般为比源代码语言更为底层的语言）。

构建是指一些列的处理，包括编译。不同的语言构建会有不通的处理步骤，最终产生可在具体特性环境运行的Artifact。

前端的编译。为了更好的编程体验和更高的可维护性，会使用一些超集的语言，然后再转译为浏览器可以运行的语言。例如对 es5/6/7 等语法的转译为对应环境支持的代码；less、sass 等转译为 css；typescript、coffeescript 等转译 javascript 。

前端构建过程一般包括以下几个过程：

• 代码检查
• 运行单元测试等
• 语言编译
• 依赖分析、打包、替换等
• 代码压缩、spirit 图片压缩等
• 版本生成

构建结果一般生成为一个或多个文件，里面包括直接可以在部署在特定环境中的所有内容。

Artifacts

每一次成功构建后产出的结果，被称为 Artifacts。Artifacts 可以直接部署到特定环境中并正常运行。每个构建结果一般都会版本保存，为后续部署、回滚、灰度等。

可能是因为构建的速度，后端都会有一个 Artifacts 制品库。而早期一般的前端项目对 Artifacts 的概念比较弱化（更早的前端项目直接没有构建的概念）一般会从 Code 直接构建部署到指定的环境。现有的规范化的项目都会有对构建产物所有版本的保存，一般都提供CND来访问。

部署、发布

部署（deploy）是指把构建后的新版本应用或服务“安装”到目标环境（开发、测试或者生产）中。这时候部署好的应用或服务应该是在目标环境中正常运行着（或者待着），但是不会有任何访问的流量。

发布（release）则是把新版本应用或者服务交付给最终用户使用的过程。相当于把流量切到部署好的新版本的过程。

前端项目部署一般是指文件的增量替换或全量替换。根据项目按需决定，部署和发布可以同时进行，也可以分开进行，前提是在不影响用户访问的同时，把前端的代码更新到相应的版本。

CI/CD

CI，Continuous Integration，持续集成。指代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。目的就是让产品可以快速迭代，同时还能保持高质量。

CD 对应有两个意思：
CD，Continuous Delivery，持续交付。指的是任何的修改都经过验证，可以随时实施部署到生产环境。
CD，Continuous Deployment，持续部署。持续部署是持续交付的更高阶段，指的是任何修改后的内容都经过验证，自动化的部署到生产环境。

两者的区别，在于是否自动部署到生产环境。持续交付，需要用户手动点击“部署”按钮才能部署到生产环境。

前端项目的 CI/CD ，因为一定的特殊性，对通用化的库或框架可以有覆盖率很高的单元测试/自动化测试，然而对业务代码的单元测试、端对端测试则成本很高，所以 CI 的过程一般就是运行构建脚本，未报错的生成静态文件则为成功。一般不会有 CD（持续部署） 的过程，合并到 develop 分支触发 CI 成功后快速发布部署到测试或预发布环境通过测试人员的测试和一定的自动化测试。到需要发布的时间点，再拉取 master 分支来构建部署发布。

蓝绿部署

蓝绿部署中，绿色代表代表正在给用户提供正常服务的系统；蓝色代表另外一套准备发布的系统，还未对外提供，可以做线上测试。

二套系统必须有相同的基础设置和配置环境，当蓝色系统测试通过，达到上线标准，就把绿色系统的流量全部切到蓝色系统中，一旦蓝色系统出现问题，把所有流量切回到绿色系统中，待蓝色系统稳定后就成为新的绿色系统，之前的绿色系统资源就可以释放用于下一个蓝色系统。

蓝绿部署能够简单快捷实施的前提假设是目标系统是非常内聚的，如果目标系统相当复杂，那么如何切换、两套系统的数据是否需要以及如何同步等，都需要仔细考虑。

滚动部署

有多个集群实例的服务中，在不影响服务的情况下，停止一个或多个实例，进行版本更新，再启动加入到集群中提供正常服务，直到所有实例都更新到最新版本。

比起蓝绿部署不需要准备二套一样的集群，通过现有的机器或增加少量的机器就可以做到版本升级。但也引入了复杂度，需要控制好更新过程中服务会有新老版本用户共存的兼容情况、防止部署过程中自动伸缩的触发导致实例中版本的不确定、部署过程中出错的回滚策略等。

金丝雀发布（灰度发布）

一种比滚动部署更有控制力度的发布策略。

准备一个或多个服务实例（使用新机器或已有的机器都可），并确保该实例服务没有服务于线上的用户，在上面部署新版本的服务，并经过测试的验证。

通过定制好的策略，只更新部分服务实例到最新，使一部分用户使用到最新版本，如果服务正常，逐渐更新所有服务实例到最新。

发布过程中，需要有一些流量控制的策略跟随部署的过程，一般可以在负载均衡、路由、应用程序中做处理。

• 针对用户级别分流。比如先部署给内部用户，在逐渐根据外部用户的分类等级扩散。
• 地域、IP 级别分流。只部署新版本到某地理地域，慢慢扩大到全量发布。
• 应用程序中判断特性分流。比如通过什么渠道使用服务的、浏览器特征分析、某个使用触发才使用新版本。

A/B测试

A/B测试指的是效果测试，同一时间有多个版本的服务在线上运行，并通过一定的策略控制多个版本的流量分配，最终通过信息的收集，分析各个版本服务的实际效果，选出效果最好的版本。

A/B测试强调的是通过不同版本对比效果来选择出最好的版本，而然金丝雀发布（灰度发布）的方式正好可以满足A/B测试的需求。

构建和部署

现有的 CI/CD 方案都已经很成熟，Jenkins、Travis、Gitlab-CI 等。docker、k8s 让这些工具简直带上了无限手套，因为构建部署是需要机器资源的，相比之前固定的资源抢占和空置，k8s 让资源动态创建、销毁，提升资源利用率。

方案的选择应该都是需要具备上下文的，根据项目的规模、当前的境况。一个前端项目，发展越来越庞大之后，自然而然都会出现需要重构来更新技术方案和更适应已有的项目规模。之前简单的构建、部署、灰度方案的弊端会越来越显现。

前后端项目，对构建和部署的流程可能会有所不同，后端程序的发布上线相对来说复杂度更高。

相比之前手动的构建部署，现有相对优的方案步骤是这样的：

1. 提交代码，合并到具体分支
2. 自动触发 CI/CD
3. 通知结果到相关人员

流程很简单清晰，Jenkins、Gitlab-CI/CD 等工具完全可以快速上手和实践。

但隐藏了很多的细节，具体以下几点来看：

• 耦合 CI/CD 系统。一些构建的脚本是否和当前的 CI/CD 系统有较强的耦合，如果现有的 CI/CD 系统做迭代或替换时候，是否可以做到最小工作量的升级，应该有一个清晰的构建脚本和流程规范在项目中，通过 CI/CD 系统做执行，保持良好的规范和独立性。
• 构建和部署解耦和打通。前端项目的构建最终都是会产出 Artifacts(html/css/js/images/etc.) 的，这也就是 CI 系统负责的部分，部署发布过程根据公司的流程制度一般有多种角色介入，开发、测试、运维等人员，构建生成 Artifacts，由其他角色或系统部署上线。构建的过程一般到产生 Artifacts 为止，上传或通知到部署系统，部署的过程则有对应的人员或系统拉取对应的 Artifacts 进行发布部署。
• 部署环境的管理。项目中应该隐藏对具体部署环境的细节，具体由部署平台来接管部署到具体环境中。
• 部署策略。涉及上述提到的几种发布部署策略，需要对部署过程中出现的问题做预测和对应的方案，如部署过程中程序出错、网络问题导致不同步等。不过 k8s 集群的出现，让部署发布过程安全可靠了很多。
• 构建部署数据收集。构建成功/失败次数，部署频率等 CI/CD 的数据，这些数据可做各种支撑，也是项目的一部分。具体可调用相应的 api 把数据统一保存到数据库中，做进一步的分析、查看、整合。

构建由 CI 工具来具体负责，只要定制好具体的规范和脚本。后端项目部署的过程由 k8s 的出现变成风险可控。我们要做的就是把构建和部署做规范的制定、系统的打通、数据的整合。

前端构建后产物都会带版本号，采用hash指纹，构建出来的文件没有改变则hash也不会变，可以先发布新版的静态资源文件，旧版同时存在。控制好入口文件（一般为html）的发布的顺序，一般就可正常上线。如果有依赖的后端接口的更改便需要先上线新版本的接口（向上兼容或新版本），再上线前端项目。

静态资源大多会使用 CDN，发布到源站后，CDN 则会自动拉取源站的文件。

前端灰度、A/B测试方案

后端服务一般都会在负载均衡层（nginx居多）做灰度方案等，业界成熟的方案大多为：

1. 简单灰度逻辑通过 nginx 配置做规则判断（路由、参数、ip等）然后 upstream 到不同的服务器。
2. 复杂灰度逻辑通过 nginx+lua 结合自己业务来做流量的灰度、切换等。

前端静态资源要做到灰度或 A/B 测试的效果，几种方案为：

1. JS 代码中做埋点判断，通过对用户特征（UA、cookie、或后端提供字段等）的判断显示为不同功能等。
2. 服务端渲染，在服务端通过特征规则判断显示不同分支版本或功能。
3. 控制入口文件，使用 nginx 判断变量 upstream 到不同 server。

方案1，对业务的入侵性大，灰度规则与代码耦合，增加了文件的大小。
方案2，因为控制了渲染入口，能做的很多，但也增加了服务端渲染的复杂度，使用场景有限。
方案3，前端入口一般都是一个 html 文件，后再去加在各种静态资源，通过对入口文件的控制，结合 nginx 方案可以做到很好的灰度和 A/B 测试方案。

首屏渲染速度对大多数应用来说都是一个重要的衡量指标，但不排除对首屏渲染速度要求不高，复杂度高，需要有灰度的需求，如内部管理系统、部分企业级应用等。

方案的选择应该考虑项目需求，俗话说，没有银弹。

首屏渲染要求较高

类似于方案3，新增一个服务，增加对入口文件的控制，来实现访问不同版本。

该服务保存所有构建时候生成的入口文件（包括分支、描述等信息），其他静态资源的发布部署和之前流程一样发布到对应的服务器和 CDN。

请求入口文件时，通过 upstream 到该服务来获取，服务可以设置特征规则等匹配条件（UA、cookie等），没有则默认获取最新版本。

性能则可以通过优化该服务，设置缓存等，没有规则时则完全直接返回。

首屏渲染要求较低

通过增加一个静态资源管理服务。

该服务保存所有构建时候生成的静态资源列表（包括分支、描述等信息），发布部署和之前流程一样发布到对应的服务器和 CDN。

入口文件则通过访问这个服务来获取自己所需要加载的静态资源列表，服务可以设置特征规则等匹配条件（UA、cookie等），没有则默认获取最新版本。

总结

上述提到的后二种方案大同小异，增加一个中心服务，通过特征规则匹配判断来实现不同版本的灰度控制和 A/B 测试。对复杂度高和业务逻辑比较多的，比如微前端方案、有较多独立的功能和页面需要做到灰度和 A/B 测试的项目则会比较合适。

二种方式可结合使用在微前端方案中。

优点：

• 独立服务，不与业务逻辑耦合
• 可灰度和 A/B 测试的颗粒度比较细，灵活度更高
• 构建后版本的管理、可快速的回滚

缺点：

• 增加了一个服务，降低了一定的速度和增加了一定复杂度，提高了风险性
• 需要保持该服务的速度和高可用性

最后

即使每天枯燥重复的工作或天天都是在挑战自己，重要的都是人，我们在对自己所做事情的观察、沉淀和思考。虽然科技的创新很难，需要持续不断的投入。我们大部分人都是直接利用现有的方案来快速发展我们的业务，然而在发展中不断向社区反馈自己沉淀的优秀的东西，这是才是可持续的发展。

原文来自：https://zhuanlan.zhihu.com/p/71562853

链接: https://fly63.com/article/detial/5376