Power Platform——直接上线？
由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！
我最近读到一篇很有意思的文章（《直接上线生产环境》），它重点介绍了直接在生产环境中工作的人员如何能大幅提高工作效率。这篇文章引起了我的共鸣，因为微软最初的Power Platform愿景就是“直接上线生产环境”。
默认环境过去是、现在仍然是生产环境，微软强制要求所有想要与平台进行任何交互的人都必须能够访问该环境（包括 SharePoint 用户和自定义应用程序表单用户）。
所以在这篇博客中，我想谈谈三件主要事情：
- 直接生产的优势
- 直接生产模式的缺点
- 如何走钢丝
1. 直接生产的优势
直接生产的主要优点是简单快捷。
从遵循应用生命周期管理（ALM）所产生的额外开销可以看出其简洁性，主要有 3 个额外开销：
要实施 ALM，您需要额外的系统
，这些系统会带来使用成本、培训成本和使用时间成本。
例如，您很可能需要：
- 类似 GitHub 的代码仓库（虽然对于直接部署到生产环境来说，这也是个不错的想法）。
- 类似 GitHub Actions 的流水线实现
- 像 Smartbear 一样进行测试
- 项目管理工具，例如 Jira
- 变更审批，例如 ServiceNow
您需要支付许可费用，需要为每个设备配备支持人员，需要经过培训的开发人员来使用它们，而且您需要花费大量时间与它们互动，而不是编写代码。
这不仅适用于专业代码，Power Platform 也应该有类似的要求。
- 你如何备份你的解决方案
- 如何在各种环境中部署
- 你如何追踪你的工作
- 您如何管理变更控制
使用 ALM 会向项目中添加额外的代码
。对于专业代码来说，这包括管道配置、测试脚本、库等等。低代码和 Power Platform 也是如此。ALM 刚推出时没有环境变量或连接引用，你猜为什么？没错，因为如果你直接在生产环境中工作，就不需要它们。
添加这些额外的代码不仅会占用开发时间，还会增加主代码的复杂性。这种复杂性使得其他开发人员更难阅读代码，因此您需要投入更多资源进行文档编写和知识转移，并且所有未来的开发工作都需要更长时间。
存储方式
与代码存储类似，但主要针对重复代码。以前您的代码只存储在 1 或 2 个地方（生产环境和备份环境），现在您可以：
- 开发
- 测试
- 舞台布置（并非总是如此）
- 生产
- 备份
这至少相当于两倍的存储空间（别忘了存储空间可不是免费的）。虽然关闭开发/测试/预发布环境可以缓解这个问题，但并非所有系统都会这样做，尤其是在 Power Platform 平台上。
至于速度，这一点显而易见，关键在于过程。
流程
如果您直接更新到生产环境，流程通常如下所示：
- 变更要求
- 进行更改
- 单元测试
- 结束
如果只是一个非常简单的改动（开发只需 10 分钟），那么整个过程都可以在几分钟内完成。现在我们来看一下 ALM 流程：
- 变更要求
- 已添加到项目管理工具
- 从仓库启动开发
- 配置的环境变量
- 进行更改
- 单元测试
- 创建测试用例
- 更新管理工具
- 创建测试环境
- 部署测试
- 完成测试用例
- 部署到暂存区
- 将变更请求添加到变更审批工具
- 产品负责人和测试人员批准变更
- 部署到生产环境
这并非完整列表，具体数量可能因系统/组织而异。
4 个步骤对比 15 个步骤，想想看，这简单的改变就能节省 10 分钟。而上面的方法却要占用一个多小时的生产时间，而且很可能还要等待数周（等待审批，无法在同一迭代周期内部署和测试等等）。
最后还有其他一些杂项福利，例如：
如果代码中存在单一版本的信息
，而开发环境和生产环境又存在同样的问题，那么它们之间就可能出现不一致的情况。例如，我经常看到开发环境中存在一些未记录的修改，当需要修复 bug 时，这些修改会被忽略并推送到生产环境。
要求开发人员
了解完整的 ALM 周期意味着他们需要具备更高的技能，这会排除一部分可以从事开发工作但无法完成其他工作的普通开发人员。
2. 直接生产模式的缺点
那么，既然有这么多好处，为什么不直接投入生产呢？主要原因有1，那就是风险。
风险永远不会消失，但需要加以管理，并建立相应的流程来降低风险发生的概率，并在风险发生时尽可能减少其影响。这就是为什么我们不在生产环境中直接编辑的原因。
降低风险的可能性。
首要关键在于测试环境。通过搭建一个独立但完全相同的测试环境（而且它确实应该如此），我们可以全面检查代码。每个开发人员都会犯错，因此建立一套检查流程至关重要。即使代码完美无缺，也可能存在意料之外的配置或外部依赖项，从而导致问题。测试环境允许我们进行“预演”，确保所有组件都能正常工作。
阶段式开发方法允许进行代码审查等验证检查。代码审查可以发现错误，并确保代码符合规范。规范的代码有助于确保不同开发人员日后进行更新时更加便捷，从而减少错误的产生。
降低影响：
ALM流程本身就具有冗余和回滚机制。通过预先部署，生产环境中的任何关键问题都可以回滚到之前的版本。
此外，拥有开发和测试环境意味着可以更快地识别并修复任何缺陷原因。针对重大事件的理想解决方案应该是：
- 该漏洞将被记录在案。
- 先前版本重新部署
- 该错误已在测试环境中复现。
- 开发中构建的解决方案
- 已验证，测试中已修复
- 已重新部署到生产环境
该流程对最终用户的影响最小，修复开发速度最快、效率最高，而且绝对不可能通过直接上线生产环境的方式实现。
此外还有其他好处，例如：
问责制：
确保用户验收测试 (UAT) 通过并获得上线批准，从而确保合适的人员对部署的任何结果负责。
沟通：
建立流程和责任机制后，沟通便成为一项有益的副产品。用户和相关系统所有者将提前获知变更并有时间做好准备。
3. 如何把握分寸
如何既享受直接上线带来的好处，又规避风险，一直是人们关注的焦点。Power Platform 最初面向的是公民开发者，而公民开发者本身就非常适合直接上线。他们缺乏培训和工具，通常是单人开发团队，而且解决方案规模小、风险低。
但 Power Platform 并未止步不前，它变得更加强大，应用范围也更广，这催生了众多对企业至关重要的解决方案和更多实例，而这两点都加剧了风险。更不用说，当一个平台如此演进时，外部威胁会投入更多资源，再次推高风险。微软及其企业客户早已意识到这一点，并推动了以下举措的实施：
- 解决方案
- 环境变量
- 连接参考
- 分享限制
- 管道
- 粒度DLP
- 解决方案检查器
- 测试工作室
还有很多其他改进，但它的本质从未改变。默认设置仍然相同，他们也添加了一些改进，例如在流程中添加版本控制（创建具有回滚功能的迷你开发/生产环境）。那么我们该如何把握这个平衡点呢？对我来说，这遵循一个简单的比例：低风险直接部署到生产环境，高风险则使用应用生命周期管理（ALM）。
要点：
低风险 = 低影响和低发生次数，因为成千上万个小风险累积起来
也会变成高风险。上述情况的严重程度始终为高风险，即使发生次数很少。
上述情况的严重程度始终为高风险，即使严重程度较低。
我推荐的指标是：
低风险流量
- 个人解决方案——它们能解决我的问题，而失败也仅限于我的职责范围。
- 影响很小——自动化并非我职责范围内的工作，所以即使失败，我也有时间和技能手动完成。
- 数量不宜过多——单个开发者不应拥有过多的流量（上限为 20 个）。
- 非敏感数据——敏感数据不应冒险泄露，且必须根据 GDPR 等法规进行披露。
低风险应用
- 共享权限有限 - 仅限小型团队使用 / 最多 5 位用户
- 连接数有限——不应使用自定义集成
- 数量限制——单个开发者不应拥有大量应用（上限为 10 个）。
- 非敏感数据——敏感数据不应冒险泄露，且必须根据 GDPR 等法规进行披露。
- 专注——只解决一个具体的小问题
应用评级可能被认为很严苛，但应用风险主要有两个方面需要考虑：
它们利用用户的连接，因此不法分子可能会滥用这些权限并访问安全数据。
它们可以迅速扩展，一个应用程序很容易从只有少数用户使用发展到整个组织都在使用。到那时，如果应用程序宕机，后果可能是灾难性的。开发者甚至可能不知道应用程序有多少用户，也不知道它对这些用户有多重要。
一旦达到这些限制，就需要转而采用应用生命周期管理（ALM）流程。该流程需要尽可能自动化和简化，以确保非专业开发者也能继续使用该平台。
实践中，关键在于环境策略。您的直接生产环境应具备共享控制功能（理想情况下使用托管环境功能，否则应使用追溯性流程来移除共享，并且务必关闭“与所有人共享”选项），并采用有限的数据防泄漏 (DLP) 策略（理想情况下仅使用非阻塞策略）。监控和沟通应是重点，新开发人员应收到介绍邮件，了解平台的限制；对于构建大量流程或高 API 调用流程的开发人员，应联系他们以确认其并非业务关键型流程。
通常的实际拆分方式是：
