团队在DevOps转型过程中，前端需要进行什么样的基础设施建设？Overview本系列总结了从传统瀑布模型开发到DevOps研发运维一体化的整个演进过程。内容很多，但对正在进行DevOps转型的团队有很大的帮助，请耐心阅读本系列。DevOps（开发+运营）是一组流程、方法和系统的统称，这些流程、方法和系统促进开发（应用程序/软件工程）、技术运营和质量保证(QA)部门之间的沟通、协作和集成。随着DevOps的兴起，出现了持续集成、持续交付和持续部署的新方法。传统的软件开发和交付方法正在变得过时，“小步骤”成为常态。在瀑布模式中，大多数公司每月、每季度甚至每年发布新版本。如今，在DevOps时代，每周、每天甚至一天多次是常态。当PaaS风靡全球时，我们可以轻松地动态更新应用程序，而无需强迫客户下载新组件。团队转型建立快速敏捷的团队。改造前的团队架构和系统架构一般分为产品规划经理、视觉设计师、前端工程师、后端工程师、测试工程师、运维工程师、DBA等七个部门，存在天然的沟通障碍各个部门之间。他们主要以电子邮件和会议的形式相互交流。效率低下，需求变更困难，难以快速响应市场变化，持续交付优质产品，如下图所示：因此，我们对团队和架构进行了调整：划分特性团队（Scrumteams）)按业务职能，设立产品负责人（策划人）、ScrumMaster（一般由技术专家担任）和开发人员团队（前端工程师、后端工程师、测试人员）；这些团队负责他们自己的微服务，并负责人员管理。改造后的组织架构和系统架构如下图所示：这是组织架构变化的部分。接下来说一下前端架构的变化。微服务架构的升级，将原来的传统项目团队拆分成多个Scrum团队进行并行开发。多个团队同时发布的分支处理、代码冲突等问题时有发生。前端发布几乎成为了业务快速发布的瓶颈。目前我们开发维护代码的状态：一个仓库，包含所有业务组的前端代码；只能一起构建一个包，不能单独部署组功能；后端完成了微服务的拆分。上面说到git多分支管理虽然可以解决一般场景下【独立开发】和【发布】的问题，但是遇到【多团队同时发布】的场景就很头疼了：需要招募leader每个团队，反复确认当天能否正常上线；线上分支（release-a、release-b、release-ab）的排列组合，防止某个团队突发问题无法上线；测试工作量增加：原本只接受一个码包，现在还要验证多个码包的功能（>1）。现在存在的问题已经梳理好了，为了解决这些问题，我们意识到，像后端一样把整个项目拆分成几个子应用，把它们变成微服务，不就可以解决当前的问题吗？困境？很自然地，我们就想到了“微前端”的概念。有了目标，努力就容易了。我们参考了优秀的商业计划书并结合自己的实际情况，最终决定使用webpack5的模块联邦特性来实践和实现微前端。架构解耦在制定了整个前端微服务方案后，我们的项目整体架构变成如下图所示：前端端的代码根据组的特点拆分成若干个子应用：子应用只有自己的相关代码，基础应用可以看作是一个比较特殊的子应用，提供工程能力，最好不要有业务代码；应用代码分为packages/apps文件，通过monorepo+pnpm管理依赖；将所有文件夹分开打包构建，用Docker+Kubernetes构建一个单独的容器（红色部分的所有子应用都是单独的容器），成为真正的微服务。上述变化不仅让拆分后的子应用可以独立开发-维护-发布，也让我们前端应用升级时的灰度-部署-回滚操作更加简单快捷。构建解耦各组前端代码，存放在packages/*下，前端代码仓库目录：platform│package.json│└─packages│app1│app2└─app3每次更新代码时，它会识别目标路径并单独构建产生变化的子应用程序，而不是之前的完整构建。如下图所示：发布解耦实现独立部署上线的目标后，所有子应用都是独立的，发布不需要依赖任何应用。您只需要确认开发修改了哪些子应用代码，然后升级对应的子应用即可。如下图所示：具体过程：开发修改应用A的代码，上传到库；构建平台（千流，公司自建）识别到应用A的代码发生变化，然后将应用A打包，生成镜像，版本号等推送到产品库；升级相应的服务。配置解耦在很多发布场景中，一个棘手的问题是应用不仅有代码层面的变化，还有具体环境配置等变化，因此发布时往往需要根据情况修改并选择正确的配置。但实际上，这个配置和应用代码一样，是发布本身的一部分，传统的通过控制台维护的方式成本会很高。比如：前端跟nginx配置有很大关系，比如配置跨域，gzip。然后这些nginx的配置可以通过helm进行整理，和镜像一起发布到环境中。这样一来，发布配置类的问题就可以优雅的解决了。综上所述，高效敏捷的团队是实施DevOps的保障。那么，自动化流程是保证产品快速交付和持续部署的有效机制。接下来介绍一下我们是如何实现自动化流程的。
