前端在 DevOps 演进中的基建实战——团队转型

前端在团队进行 DevOps 转型的期间，需要进行一些什么样子的基础建设呢？

概述

本系列整理了一下从传统的瀑布模式开发到 DevOps 研发运维一体化的整个演进过程。内容很多，但对于正在进行 DevOps 转型的团队能起到不小的帮助，请耐心看完本系列。

DevOps（Development + Operations）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

随着 DevOps 的兴起，出现了持续集成（Continuous Integration）、持续交付（Continuous Delivery） 、持续部署（Continuous Deployment） 的新方法。传统的软件开发和交付方法变得过时，“小步快跑”才是主流。在瀑布模式下，大多数公司会每月，每季度甚至每年发布新版本。现如今，在 DevOps 时代，每周，每天，甚至一天多次是常态。当 PaaS 正在占领世界时，我们可以轻松地动态更新应用程序，而无需强迫客户下载新组件。

团队转型

建立快速敏捷团队

未转型前的团队结构和系统架构，一般分为七大部门：产品规划经理、视觉设计师、前端工程师、后端工程师、测试工程师、运维工程师、DBA等。各部门之间天然的形成了沟通障碍墙，相互之间主要以邮件和会议的形式沟通，效率低下、需求变更困难、很难快速响应市场变化和持续交付高品质的产品，如下图：

于是，我们对团队和架构进行一个调整：按照业务功能划分特性小组（Scrum 团队），设置产品负责人（一个规划人员）、Scrum Master（一般由技术专家级别担任）和开发者团队（前端工程师、后端工程师、测试）；这些团队负责自己的微服务同时要负责人员的管理。转型之后的组织结构和系统架构，如下图所示：

这是组织结构变化的部分，接下来讲一下前端架构的变化。

微服务架构升级

将原先的传统项目团队划分为多个 Scrum 小组并行开发，多小组同时发布的分支处理和代码冲突之类的问题频繁出现，前端发布几乎成为业务快速发布版本的阻塞点。目前，我们开发和维护代码的现状：

• 一个仓库包含了所有的业务组的前端代码；
• 只能一起构建出一个整包，小组功能也无法单独部署；
• 后端已完成微服务的拆分。

如上所述，虽然一般场景通过 git 多分支管理能解决【独立开发】和【发布】的问题，但是遇到【多团队同时发布】的场景就让人头疼了：

• 需要拉上各个团队的负责人，反复确认当天能否正常上线；
• 上线分支排列组合（release-a、release-b、release-ab ）预防某一个团队突发问题不上线；
• 测试工作量增加：原本只要验收一个代码包，现在还要验证多个代码包功能（> 1）。

既然梳理了已有问题，为了解决这些问题，我们意识到和后端一样将整个项目拆分成若干的子应用，将它们也变成微服务，不就可以解决目前的困境了吗？自然而然我们就想到了“微前端”的概念。有目标，就好发力了，我们参考了业务优秀方案，同时结合了自身实际情况，最终决定用webpack5 module federation 特性来进行微前端的实践与落地。

架构解耦

制定了整个前端微服务方案后，我们的项目整体的架构变成了如下图展示的样子：

前端侧的代码按照小组特性拆分成若干个子应用：

• 每个子应用只拥有自己相关的代码，基座应用可以看成比较特殊的子应用，它提供工程能力，最好不要有业务代码；
• 将应用代码划分到 packages/apps文件下， 通过 monorepo + pnpm 进行管理依赖；
• 所有的文件夹进行单独的打包构建，搭配 Docker + Kubernetes 构建成单独的容器（红色部分内所有的子应用都是单独的容器）变成真正的微服务。

以上的变化，让拆分出来的子应用能够独立开发 - 维护 - 发布之外，还使得我们前端应用升级时的 灰度 - 部署 - 回滚 操作变得更加简单、快速。

构建解耦

各个小组的前端代码存放在 packages/* 下，前端代码仓库目录：

platform
│  package.json
│
└─packages
   │  app1
   │  app2
   └─ app3

当每次更新代码时，会识别目标路径，单独构建产生变更的子应用，而不是以往的全量构建。如下图：

发布解耦

在达成独立部署上线的目标之后，所有的子应用都是独立的，发布不需要依赖于任何应用。只需要确认开发修改了哪些子应用的代码，那么升级对应的子应用即可。如下图：

具体流程：

1. 开发修改了 A 应用的代码，上库；
2. 构建平台（千流，公司自建）识别到 A 应用产生了代码变更，接着对 A 应用进行打包，生成镜像、版本号等，推送到制品库；
3. 升级对应服务。

配置解耦

在很多发布场景中，一个棘手的问题是：不仅应用存在代码层面的改动，还有伴随着特有的环境配置之类的改动，所以在发布时经常需要根据情况修改和选择正确的配置。但其实这个配置和应用代码一样，本身就是发布的一部分，而传统的通过控制台去维护的方式成本将会非常高。

举个例子：前端和 nginx 配置打交道比较多，像配置跨域、gzip 这些。那么这些 nginx 配置，我们可以通过 helm 编排的方式，搭配上镜像一同发布到环境上。这样就能优雅的解决配置类的发布问题了。

总结

一个高效的敏捷团队是 DevOps 能落地的保障，那么自动化流程就是保证产品快速交付和持续部署的有效机制，接下来为大家介绍我们是如何实现自动化流程的。