原文出自：Mia-Platform

越来越多的公司正在采用敏捷方法和 DevOps 方式来加速和改进他们的软件开发。尽管一些软件生命周期过程已经简化并加速，但企业仍然需要新的工具和技术才能将 DevOps 方法论付诸实践——例如任务管理器、自动化pipelines 和测试系统。

随着公司内部使用的技术和工具数量的增加，开发人员，尤其是那些对公司的技术堆栈和开发产品了解较少的开发人员，将有可能需要浪费时间寻找他们需要的资源，甚至是从头开发已经在公司的软件资产中可用的组件。

本应加快工作速度的工具最终可能会大大减慢开发者的工作速度。为了避免这种情况，需要彻底转变观点： 企业应该开始放弃以基础设施为中心的愿景，而应该将开发人员体验（或 DevX）置于部署过程的中心。内部开发人员门户（IDP，或内部开发人员平台）就是为了满足这一需求而创建的。IDP 是一个单一门户，汇集了公司内部可用的所有工具和技术。通过这种方式，开发团队可以专注于开发与公司核心业务相关的功能，而不是浪费精力和精力从头开始开发已经构建过的功能，或者借助已有的模板和资源可以更快地开发这些功能。

什么是内部开发人员门户？

在深入研究内部开发人员门户 IDP 的功能之前，让我们先强调一下其与外部开发人员门户 (EDP) 的区别。EDP 帮助组织外部的开发人员，为他们提供所需的所有信息和资源，以将他们的系统与组织的系统正确集成。通常集成是通过一些 API 实现的，因此，EDP 通常实际上是 API 门户。 IDP 有一个内部 API 的 API 目录，但它也旨在简化软件开发并鼓励公司内部组件的共享和重用。

一旦所有组件都由负责内部开发人员门户的团队标准化，这些组件将可供开发团队使用，开发团队只需根据自己的需要集成和配置组件。

内部开发人员门户在整个 DevOps 周期中提供增强的可见性、可追溯性、可审计性和可观察性。设计、基础设施、监控、部署、文档：每个阶段都受益于这个工具。为了向开发团队提供最大的支持，内部开发人员门户应包含：

• · 有据可查的 API 目录；
• · 执行常见功能的服务（或微服务）市场——已经过测试并可以重用。市场，也称为 服务目录，应该随着时间的推移不断丰富和维护，以满足开发人员不断变化的需求；
• · 直接访问公司内部使用和可用的所有开发和管理工具；
• · 基础设施的完整文档；
• · 新组件开发的指南和最佳实践；
• · 监控工具

通过这种方式，采用内部开发人员门户允许开发人员自行获取可用技术，改进治理，因为可复用的组件已经过测试和验证，并鼓励开发者在此知识共享。

IDP 对企业有什么好处？

内部开发人员门户可以帮助提高企业内部所有开发团队的生产力，无论其组织方式如何。如果您的企业已经采用了 DevOps 方法，旨在建立自己的 数字集成中心，并将其组织成功能团队，则内部开发人员门户是确保您充分利用它们的工具。

由于 IDP 应随着业务不断发展，因此以下是我们关于实施内部开发人员门户的建议和建议，该门户可在软件生命周期的每个阶段为您的组织提供帮助。

1. 基础设施：透明地管理集群

Ops 团队和开发团队拥有非常不同的专业领域，通常更喜欢留在自己的领域——除了可以在这两个领域工作的任何 DevOps 人物。事实证明，通常，当必须实施新的基础架构时，需要两个团队合作的组件创建和管理阶段很容易成为瓶颈，拖慢整个过程。

内部开发人员门户应该为开发人员提供即用型和标准化的组件：这样，开发人员可以安装集群、管理环境变量并独立更新基础架构。日志审计应该集中在整个基础设施中，并且你应该有一个单一的身份验证和授权系统。此外，建议自动化一些方面，如下所示：

• · 基础设施扩展，水平和垂直
• · 备份系统
• · 监控系统
• · 报警系统

内部开发人员门户还通过以下方式显着节省资源和成本：

• · 监控软件生命周期的各个方面，您可以知道是否有可以关闭或重新用于其他系统的未使用资源。
• · 根据多租户方法共享基础设施，这也允许分配基础设施成本。

2. 设计和复用：100% 控制已发布的软件

在设计云原生应用程序的基础架构时，确定您希望哪些组件可供其他应用程序重用非常重要。为了促进这种操作， 内部开发人员门户应使开发人员在配置、测试、API 和事件公开期间具有自主权。此外，在定义了业务标准之后，开发者还可以独立定义：

• · 安全
• · 服务版本策略
• · 服务聚合和产品版本

这可以通过构建一个提供服务、API 和源代码的服务目录来促进， 这些服务、API 和源代码已经过测试并可以复用。

3. 部署：部署过程无瓶颈

在部署方面，开发人员应该能够独立访问运行时环境。有了 IDP， 开发人员可以自主，无需担心管理集群和基础设施：他们只需要选择环境和部署，而无需等待 Ops 部门手动配置。这允许开发人员：

• · 标签部署；
• · 在实际部署之前进行试运行部署以预览新开发；
• · 在出现问题时运行回滚；
• · 启动自动化测试。

通过这种方式，开发人员完全独立于其他团队，并且可以完全跟踪每个部署的内容，知道由谁执行以及何时执行。

4. Monitor：检查应用程序的健康状况

通过将每个工具和工件集中在内部开发人员门户中，您可以创建一个仪表板来监控所有服务的状态。您还可以创建自动化，从而创建其他仪表板和警报，这对于 24/7 运行的应用程序尤其重要。日志是聚合和集中的，因此开发人员始终可以使用它们：这样，他们不必向其他部门请求它们，并且如果出现问题，他们可以及时采取行动。业务指标也很容易可见和可用，所有与安全相关的警报都集中在一个地方：这允许更轻松、更有效的监控。

5. 文档：知识共享

内部开发人员门户还应为文档提供空间，以确保知识得到保存和共享。 因此，文档集中在一个地方并由 IDP 提供：开发人员不需要访问许多不同的工具（例如 Wiki、共享文件夹、专用平台）来查找和查阅它。

由于文档是由开发人员为开发人员制作的，因此鼓励编写和使用的最佳方式是 采用 Docs as Code 方法。这种方法表明文档是软件的一部分，因此应该使用开发人员在日常代码活动中使用的工具和方法来起草和维护它。一般来说，文档应该是基于 Git 的，以促进协作和管理版本控制，并且应该用基于文本的标记语言编写，例如 Markdown。

自动化可以增强其他关键功能：可以从 API 规范和事件模式开始创建自动化文档，还可以在一个地方收集每个微服务的 README 文件，以便获得一个完整的概览，并在每次发生故障时自动更新。单个文件被编辑。

创建指南、示例、最佳实践以加速新团队成员的入职和标准化公司内的开发实践总是非常有用的。最后，插入最新的架构图可以让开发人员始终保持一致。

结论

通过采用敏捷方法和 DevOps 范式，以及功能团队中的组织，公司可以显着改进云原生软件开发。但是，为了防止大规模部署新的开发工具和技术，而不是加快开发团队的工作速度，有必要以开发人员和他们的经验为中心。 为了改进 DevX，最有效的工具是内部开发人员门户 (IDP)，这是一个将所有可用服务和工具收集在一个地方的单一门户。内部开发人员门户简化了每个阶段的开发过程，从设计开始到文档结束。

但是，从头开始创建 IDP 可能是一个漫长而昂贵的过程，因为为了最大限度地提高其有效性，有必要开发许多不同且相互关联的功能。通过采用新技术和方法来创建和维护 IDP，您可以将所节省的所有时间都投入其中，而不是将这些时间再投资于提高生产力。 解决方案是采用现成的内部开发人员门户，例如 Mia-Platform * 提供的门户，以避免基础设施问题，并专注于根据业务需求对其进行定制。

行云企业应用商店

行云企业应用商店解决方案，通过服务商店实现企业标准化、模块化的业务组件和能力的沉淀，并以SaaS化的形式将服务开放给各业务团队使用，避免重复“造轮子”，实现业务数字化转型和业务现代化。最终帮企业达到消除竖井效应、沉淀企业能力、梳理数字资产、优化资源调配等目的。

基于CloudOS构建的API、业务逻辑组件、微服务、算法等，都属于数字资产的范畴。通过持续的调用与迭代，形成一套高度抽象、可以快速复用的数字资产能力，沉淀到企业应用商店，形成企业云原生数字资产“共建、共用、共享”。

适用场景：

1、解决“烟囱式”研发

“烟囱式”研发导致研发沟通困难，形成信息孤岛，不利于业务沉淀，研发效率低，阻碍业务创新发展。通过落地企业服务商店实现企业标准化、模块化的业务组件和能力的沉淀，并以SaaS化的形式将服务开放给各业务团队使用，避免重复“造轮子”，实现业务数字化转型和业务现代化。最终可以帮企业达到消除竖井效应、沉淀企业能力、梳理数字资产、优化资源调配。

2、企业数字化资产管理

本方案支持将API、业务逻辑组件、微服务、算法等，通过持续的调用与迭代，形成一套高度抽象、可以快速复用的数字资产能力，沉淀到企业应用商店。同时，企业使用的标准中间件及定制中间件同样作为数字资产能力沉淀到企业应用商店。

3、建立行业云生态，从成本中心向利润中心的转型

通过企业的持续治理与运营，形成企业的数字资产“共建、共用、共享”，促进行业内数字资产的复用与共享，使能数字化云原生应用快速构建与创新。

同时数字资产可以租用、售卖等形式为企业提供持续性的价值收益。一些行业已经开始探索科技部门从成本中心向利润中心的转型，以应用商店形态进行“业务能力输出”就是很典型的一种实践。

了解行云创新企业应用商店解决方案详情>