每个微前端应独立部署

每个微型前端都有它自己的CI / CD管道，并且能够在没有其他微前端的任何依赖项的情况下部署到生产。应该避免的常见的反模式是“地狱的部署队列”，其中不同的微前端如此紧密地耦合，它们需要以特定顺序部署，以避免打破应用程序。

做✅：

• 具有单独的CI / CD管道。
• 按需发布。

不要❌：

• 有发布时间表。
• 具有允许以前版本的增量/顺序部署。

微前端应独立测试

因为需要单独的微前端以及容器应用程序内部呈现，因此还可以使用单位和整个方案的集成测试测试它们是有意义的。

做✅：

• 为隔离的每个微前端渲染具有单位和集成测试。
• 在容器应用程序中运行微前端渲染的集成测试作为端到端测试的一部分。

微前端应该是有版本的

当一个新的微前端被部署到生产时，不应删除以前的版本，并且应该使用语义版本或类似的版本号标记新版本。由容器应用程序决定要使用(管理)的特定微前端或始终使用最新版本(Evergreen)的特定版本。

做✅：

• 使用语义版本化。
• 使用特定版本或“最新”。

不要❌：

• 需要全局部署更改版本。
• 删除以前的版本。

最小的沟通

微前端之间的通信应尽可能最小，简单，避免尽可能多的全球状态和框架特定的解决方案。

如果两个或更多的微前端共享大量消息以提供其最小功能，它们可能太紧密耦合，并且它们可以共享类似的足够的目的，即它们应该被认为将它们集成到一个中。

做✅：

• 保持信息小而简单。
• 如果可能的话，避免有状态和通信框架。

不要❌：

• 股东。
• 有不必要的沟通。

CSS应该是范围

来自一个微前端的CSS不应影响其它微前端。

做✅：

• 为您的CSS定义范围。
• 使用CSS-IN-JS或命名法库(如CSS模块)。

不要❌：

• 使用全局CSS。

最终建议书

做✅：

• 尝试创建自治团队。
• 尝试安排围绕业务功能的微前端。
• 可重用性是一个很好的“副作用”而不是目标。