Marico's space
【译者前言】说实话，Power Platform 我也用过一段时间，环境这块一直是痛点——动不动就冒出来一堆 Dynamics 时代的遗留角色，看得人头皮发麻。这篇文章的作者和架构师聊完后的思考挺实在的，尤其是 Security Roles 那段，简直是我每天都在经历的噩梦，分享出来给大家共鸣一下 😂
\n\n最近我和架构师聊了聊 Power Platform Environments，挺有意思的。这让我开始思考它们应该如何改进，以及未来的发展方向。
\n\n说实话，Power Platform 这些年功能更新很快，但 Environments 这个底层概念说实话变化真心不大。感觉就是在旧房子里刷了新漆，骨子里还是那一套。
\n\n我想聊三个方面：
\n可靠的 Power Platform Environments 多年来没什么大变化。是的，我们有了托管环境（managed environments）和开发环境（developer environments），但这些都是表面变化，深层架构一成不变。这个怎么说呢，也说得通吧，毕竟它是平台的基础，不能随便做破坏性变更，否则大家的流程都要重写。
\n\n但我认为还是有几个容易实现的改进。
\n\n每个新环境都会添加 100 个 Security Role，说出来你可能不信，我用过的可能还不到 10 个。天哪，100 个角色，光是看完名字就要花半天，谁记得住哪些是自己需要的啊！
\n\n想象一下，如果我们只有 Power Platform 专用的角色，比如：
\n然后提供选项来添加 Approvals、Copilot Studio 和 Power Automate Desktop 相关的角色。所有系统级的 SPN 角色都可以被抽象掉。最后，我会默认启用 Basic User，这样只要你访问环境就会获得该角色。对于那些被移除且无法添加的角色，可以提供文档说明，这样管理员可以自己创建（或者让 Copilot 来帮忙 😎）。
\n\n说实话，每次给客户配置环境，光是解释那堆角色就要花大半天，真心希望 Microsoft 能把这事简化一下。
\n\nSystem Customizer 角色也有问题。这个 Dynamics 时代的角色本意是让 maker 能够创建自定义表。如果没有它，创建自定义表后就没法往里面添加数据（你需要先创建表，再创建角色，然后才能使用表）。这个设计初衷是好的，因为它去除了环境设置，但允许开发者在非生产环境中完全访问数据。但随着 Power Platform 发展并变得 solution-aware，这个计划就失效了。
\n\n因为平台构建在平台之上——例如 flows 和自定义数据以相同方式存储——这给 Security Roles 带来了大问题。
\n\n没错，要做以上任何开发，我都需要查看所有 Dataverse 表（包括 flows 等系统表）的权限。如果你想给别人这个 Security Role，那只有管理员能做，因为用户可以轻易地给自己赋予任何角色。
\n\n说实话，这个设计简直是给自己挖坑——做个表格都要管理员权限，小团队还好，大企业走个审批流程等半天，开发热情都凉透了。
\n\n需要一个新角色，专门作用域 maker 创建的自定义表。这样如果你创建一个表，你就可以添加数据等等，但在获得权限之前其他人都无法访问。
\n\n还有 Common Data Model 表的问题。作为环境所有者，我应该能决定是否需要 Accounts 表，不要用那些我永远不会用或会误用的表来浪费我昂贵的 Dataverse 存储空间和容量。
\n\n说实话，每次看到那些莫名其妙自带的表（Account、Contact 之类的），我就想：这占用的容量算谁的？微软能不能让我自己选要装什么啊！
\n\n不仅能节省所有 Dataverse 容量，还附带以下好处：
\n我认为 Power Platform 需要更智能的环境分类方式。现在的分类方式相当死板——默认情况下，你只有一种环境类型，这限制了你如何利用 Power Platform 的功能。
\n\n一个简单但有效的改进是：根据使用场景给环境添加元数据标签，比如"开发"、"测试"、"UAT"、"生产"、"演示"。这样可以帮助我们更好地组织和管理 Power Platform 资源。
\n\n说真的，现在我区分环境全靠取名规范和颜色标签，太原始了……
\n\n我认为环境之间的关系是一个大问题。目前，如果我想迁移解决方案，我必须导出到文件，手动将其复制到另一个环境，然后导入。这个过程非常繁琐，容易出错，而且缺乏版本控制。
\n\n我想看到的是一种更优雅的方式，让环境之间能够"对话"，比如一个开发环境可以将解决方案推送到测试环境，测试环境可以将解决方案推送到 UAT 环境，UAT 环境可以将解决方案推送到生产环境。
\n\n这样可以让我们更清晰地了解解决方案在不同环境之间的流转，同时保持环境的隔离性。
\n\n说实话，现在的导出导入流程简直是上世纪的产物，2026 年了还在手动拷贝文件，服了。
\n\n我想看到 Power Platform 提供的关于环境使用情况的洞察。当前的报告功能相当有限，没有提供足够的透明度来了解我们真正使用 Power Platform 的方式。
\n\n说白了，我现在连自己花了多少容量、每个环境有多少人在用都不太清楚，全靠人工统计，太不现代化了。
\n\n我认为 Power Platform 环境的未来是 AI 驱动的。想象一下，如果 Power Platform 能够自动检测环境的使用模式，并提供优化建议——比如识别出哪些环境使用率较低，建议合并，或者检测到某个环境有异常活动，自动标记给管理员。
\n\n这个听起来确实很美好，就是不知道能不能真正落地……不过微软现在大力推 Copilot，期待一下也不是不行。
\n\n我想看到环境配置即代码（IaC）的支持。能够用 YAML 或 JSON 定义环境配置，然后通过 Power Platform 部署这些配置，将使管理大规模 Power Platform 部署变得更加容易。
\n\n说实话，这个才是我真正想要的！想象一下所有环境配置都在 Git 里管理，审计、回滚都方便，这才是现代开发该有的体验。
\n\nPower Platform 应该智能地处理解决方案在不同环境之间的迁移。当前的导出/导入过程容易出错且耗时。未来应该能够自动处理依赖关系、保留版本历史，并提供回滚能力。
\n\nPower Platform Environments 是一个强大的功能，但它的发展速度跟不上平台本身的发展。我们需要一些重大的改进，以确保 Power Platform 能够继续满足现代企业的需求。
\n\n从更智能的安全角色管理，到环境之间的无缝协作，再到 AI 驱动的管理——Power Platform Environments 的未来充满了可能性。Power Platform 团队需要认真考虑如何推进这些改进，以确保平台能够继续为企业提供价值。
\n\n说实话，Power Platform 这几年进步是有的，但环境这块确实拖了后腿。希望 Microsoft 能认真听听用户的声音，别让这么好的平台毁在管理体验上。