本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 组织和工作方式
与所有架构策略一样，微前端的影响远远超出了组织选择实施的技术。构建微前端应用程序的决定必须与业务、产品、组织、运营甚至文化保持一致（例如，赋予团队权力和去中心化决策）。作为回报，这种微前端架构支持真正敏捷、产品驱动的开发，因为它可以显著减少原本独立的团队之间的沟通开销。
## 敏捷开发
近年来，敏捷软件开发的想法已变得如此普遍，以至于几乎每个组织都声称要敏捷工作。虽然*敏捷*的确切定义超出了该策略的范围，但值得回顾一下与微前端开发相关的关键要素。
敏捷范式的基础是《[敏捷宣言》](https://agilemanifesto.org/)（2001），它假设了四个主要原则（例如，“个人和互动胜于流程和工具”）和十二项原则。诸如 Scrum 和 Scaled Agile Framework (SAFe) 之类的流程框架是围绕敏捷宣言出现的，并已进入日常实践。但是，它们背后的哲学在很大程度上被误解或忽视了。
在微前端架构的背景下，必须遵循以下敏捷原则：
+ “经常交付可运行的软件，从几周到几个月不等，优先考虑较短的时间范围。”
这一原则强调了分阶段工作并尽可能定期和频繁地将软件交付到生产环境是多么重要。从技术角度来看，这是指持续集成和持续交付（CI/CD). In CI/CD，用于构建、测试和部署的工具和流程是每个软件项目不可或缺的一部分。该原则还意味着运行时基础设施和运营责任必须归团队所有。这种所有权在分布式系统中尤其重要，在分布式系统中，独立的子系统对基础设施和运营的要求可能截然不同。
+ “围绕积极进取的个人构建项目。为他们提供所需的环境和支持，并相信他们能把工作做好。”
“最好的架构、要求和设计来自于自组织团队。”
这两项原则都强调所有权、独立性和 end-to-end责任感的好处。当（且仅当）团队真正拥有自己的微前端时，微前端架构才会成功。 End-to-end从构思到设计和实施，再到交付和运营的责任确保了团队能够真正行使所有权。无论是在技术上还是在组织上，团队都需要这种独立性，这样团队才能对战略方向拥有自主权。我们不建议在使用瀑布式开发模式的集中式组织中使用微前端平台。
## 团队组成和规模
软件团队要行使所有权，就必须在组织规定的界限内进行自我管理，包括团队交付的方式和内容。
为了提高效率，团队必须能够独立交付软件，并有权决定交付软件的最佳方式。如果团队从外部产品经理那里获得功能要求或从外部设计师那里获得用户界面设计，但不参与这些项目的规划，则不能被视为自主团队。这些功能可能违反现有合同或功能。此类违规行为将需要进一步的讨论和谈判，有可能延迟交付，并在团队之间引入不必要的冲突。
同时，团队不应变得太大。虽然规模更大的团队拥有更多的资源并且可以容纳个人缺席，但每增加一个新成员，沟通的复杂性就会呈指数级增长。无法说出一个普遍有效的最大队伍规模。项目所需人员数量取决于团队成熟度、技术复杂性、创新速度和基础设施等因素。例如，亚马逊遵循双披萨规则：一支规模太大而无法吃两个披萨的队伍应该分成较小的队伍。这可能是一个挑战。分裂应沿着自然界限进行，并应赋予每个团队对其工作的自主权和所有权。
## DevOps 文化
DevOps 是指一种软件工程实践，其中开发生命周期的各个步骤从组织和技术角度紧密整合。与普遍的看法相反， DevOps 这在很大程度上与文化和思维方式有关，而很少涉及角色和工具。
传统上，软件组织会有专家团队，例如设计、实施、测试、部署和运营。每当一个团队完成工作时，他们就会将项目移交给下一个团队。但是，通过专业团队的孤岛交付软件会导致移交过程中的摩擦。同时，当专家被迫以狭隘的重点工作时，他们缺乏邻近领域的知识，对产品也没有系统的看法。这些缺陷可能导致软件产品的一致性降低。
例如，当软件架构师设计的解决方案将由不同团队中的某人实施时，他们可能会忽略实现的固有方面（例如依赖关系不匹配）。然后，开发人员走捷径（例如猴子补丁），或者在架构师和开发团队之间启动正式 back-and-forth的补丁。由于管理这些流程的开销，开发不再是敏捷的（从灵活、自适应、增量和非正式的意义上讲）。
尽管该术语 DevOps 主要涉及文化，但它意味着在实践中使之成为 DevOps 可能的技术和过程。 DevOps 与之密切相关CI/CD. When a developer has finished implementing an increment of software, they commit it to a version-control system such as Git. Traditionally, a build system would then build and integrate the software, and have it tested and released in a more or less unified and centralized process. With CI/CD，软件的构建、集成、测试和发布是固有的、自动化的。理想情况下，通过专门为给定项目量身定制的配置文件，该过程是软件项目本身的一部分。
尽可能多的步骤是自动化的。例如，应减少手动测试做法，因为几乎所有类型的测试都可以实现自动化。以这种方式设置项目后，每天可以充满信心地多次交付软件产品的更新。另一种支持的技术 DevOps 是基础设施即代码 (IaC)。
传统上，设置和维护 IT 基础架构需要手动安装和维护硬件（在数据中心设置电缆和服务器）和操作软件。这是必要的，但它有很多缺点。安装既耗时又容易出错。硬件往往过度配置或配置不足，导致开支过高或性能降低。通过使用 IaC，您可以通过配置文件描述 IT 系统的基础架构要求，通过该文件可以自动部署和更新云服务。
所有这些与微前端有什么关系？ DevOps、CI/CD 和 IaC 是微前端架构的理想补充。微前端的好处取决于快速无摩擦的交付流程。只有在团队 end-to-end负责任地拥有软件项目的环境中， DevOps 文化才能蓬勃发展。
## 跨多个团队协调微前端开发
在跨多个跨职能团队扩展微前端开发时，会出现两个问题：首先，团队开始对范式进行自己的解释，做出框架和库选择，并创建自己的工具和帮助程序库。其次，完全自主的团队必须对诸如低级基础设施管理之类的通用功能负责。因此，在多团队的微前端组织中再引入两个团队是有意义的：支持团队和平台团队。这些概念在具有分布式系统的现代 IT 组织中被广泛采用，并且在 Tea [m Topologies 中有详细记录。](https://teamtopologies.com/key-concepts)
下图显示了支持团队向三个微前端团队提供工具、库、标准和测试。平台团队为这三个微前端团队提供基础架构、共享运行时功能和域服务。
平台团队通过将微前端团队从无差别的繁重工作中解放出来，为他们提供支持。这种支持可能包括基础设施服务，例如容器运行时、 CI/CD 管道、协作工具和监控。但是，成立平台团队不应导致组织将开发与运营分开。情况恰恰相反：平台团队提供工程产品，而微前端团队对平台上的服务拥有所有权和运行时责任。
支持团队通过专注于治理和确保微前端团队之间的一致性来提供支持。（平台团队不应参与其中。） 支持团队维护共享资源，例如用户界面库，并创建框架选择、性能预算和互操作性惯例等标准。同时，它为新团队或团队成员提供应用治理所定义的标准和工具的培训。
## 部署
微前端团队自主权的北极星是拥有一条独立于其他微前端团队的自动化管道，其生产途径是独立于其他微前端团队。遵循不共享原则的团队可以实现独立的管道。共享库或依赖平台团队的团队必须决定如何管理部署管道中的依赖关系。
通常，每个管道都执行以下操作：
+ 构建前端资产
+ 将资产部署到主机以供使用
+ 确保更新注册表和缓存，以便向客户交付新版本
实际的管道步骤因技术堆栈和页面合成方法而异。
对于客户端组合，这意味着将应用程序包上传到托管存储桶，然后通过在 CDN 上缓存来发布以供使用。在服务工作线程中使用浏览器缓存的应用程序还应实现更新服务工作线程缓存的方法。
对于服务器端组合，这通常意味着部署服务器组件的新版本并更新微前端注册表以使新版本可被发现。您可以使用 blue/green 或 canary 部署模式来逐步推出新版本。