ServiceNow 和 Salesforce（仅举几例）等平台的推出是为了处理和解决与构建企业特定应用程序并保持公司敏捷、自动化和可扩展相关的许多极其繁重的任务。然而，为了在组织中采用这些平台并最大化其价值，它们需要类似于经典软件开发的开发实践、原则和纪律。
平台工程和实例管理平台的出现是一种对平台管理（包括 CI/CD 生产管道）进行编码和标准化的方法。然而，在如上所述的低代码/无代码 (LCNC) 平台时代，将平台工程原理应用于这些平台对于非开发人员和传统开发人员都是有益的。 LCNC 平台允许开发人员立即直接专注于开发完善的业务逻辑，而无需编写必要的应用程序逻辑。从理论上讲，这应该会缩短上市时间并降低维护成本，因为该平台处理所有应用程序基础设施（内存、存储、网络等）。然而，重要的是不要忽视，引入公民开发人员的组织将面临与专业编码人员在企业开发中遇到的相同挑战。
解决长期延误的根本原因
大多数知名企业的运营仍面临长期延迟，因此他们转向了平台。然而，他们经常很快发现，即使使用这些平台，他们仍然在开发生命周期的关键时刻遇到长期延迟，这可能是由于多种因素造成的。
低效的部署实践、缓慢的审批流程和冗长的手动测试都会导致延迟。固定的发布时间表是另一个重要的贡献者。当公司无法按需发布时，他们必须等待下一个变更窗口，这限制了他们发布到生产环境的频率。
除此之外，对于使用 ServiceNow 或 Salesforce 等平台的公司来说，克隆数据库或实例作为生产环境等流程也可能非常耗时。克隆通常用于将生产数据/信息复制到预生产环境以测试开发的更改。
虽然克隆对于在所有非生产环境中协调生产更新是必要的，但此过程（通常需要大量数据库）可能需要长达 10、20 甚至 30 小时。对于开发人员来说，有很多时间可以闲置；失去的时间只是冰山一角。
这些只是平台工程团队正在帮助公司克服的一些障碍，他们正在以多种方式做到这一点。
首先，平台工程团队和技术正在通过引入更好的基础设施、工具和流程来帮助实现从固定发布计划到按需发布的过渡，这些基础设施、工具和流程支持持续集成和持续交付（CI/CD）管道。除此之外，通过自动化部署流程，公司可以在无需人工干预的情况下将更改推送到生产中，从而允许频繁且较小的发布。
其次，当涉及克隆等过程时，自动化和准确性就是一切。如果平台工程团队能够自动化并加速克隆过程，他们就可以最大限度地减少源和目标之间的差异。关键是建立和标准化更好的方法来最大限度地减少停机时间和错误，以便平台本身能够支持更好的服务交付标准。
谁拥有该交付管道？
治理和标准化是平台工程中的关键要素。当软件工程师意识到构建 CI/CD 交付管道涉及大量编码时，平台工程运动就开始了。他们认识到管道本身应该被视为一个应用平台，需要专门的工程师团队。
许多企业预计不会专门雇用人员来维护和建立交付管道。他们可能认为使用云服务意味着一切都会自动处理。因此，开发团队的部分时间通常被分配来管理作为应用程序的交付管道，这是可行的，因为他们已经负责应用程序维护。这种隐藏的负担通常会纳入开发团队正在开发的所有应用程序的总体维护成本中。
然而，当管理权限变得过于广泛且部署实践过于不一致时，交付管道治理可能会出现问题。除此之外，当非生产环境发生太多变化时，平台环境可能会脱离治理。
在这里，我们看到平台工程团队开始拥有交付管道，并围绕治理和部署流程以及整个软件开发生命周期引入更多自动化。现实情况是，平台团队应该寻求以标准化代码开发、构建和部署方式的方式来实施治理。这些工具可以有意识地、有意地将治理嵌入到流程中，其结果正在帮助团队更好地协调一致。
尽可能保持与生产环境相似的环境
通常，当公司考虑平台工程时，他们会考虑管道，而不是管道所经过的环境，或者如何使非产品环境尽可能保持生产环境。如果没有这种协调，经典的“在开发中工作，而不是在生产中工作”的难题可能是不可避免的。
成功的平台工程团队尽可能保持环境与生产环境相似，因为他们了解测试和推送微小代码片段以降低出现问题的风险的价值。当新功能在类似生产的环境中进行全程测试时，公司可以明显降低规模和数量上的风险，并提高质量。这是扩展和构建可持续大型企业系统实践的一部分
归根结底，平台工程的任务是解决困扰开发人员生活的企业开发问题，而且还有很多工作要做。如果没有在现代 LCNC 平台本身内管理平台工程的战略方法，企业开发社区将无法在不影响质量或合规性的情况下以当今业务需求的速度提供交付。
您可能还喜欢……
平台工程不仅仅是基础设施！
分析师观点：平台工程的新变化、现在情况以及下一步是什么
