使用门户自动创建应用程序可以通过降低复杂性并提高与标准的一致性来加快软件开发速度。
译自 How to Scaffold a New Application with a Developer Portal，作者 Matar Peles。
当平台团队开始创建新应用程序时，他们通常会在构建过程中陷入困境——构建结构、文件系统和其他部分以开始编写代码。此瓶颈通常源于开发人员和研发经理想要解决的问题。
开发人员希望：
- 不再从头开始创建每个新微服务或应用程序，并开始使用标准化自动化。
- 一个自助服务流程来创建初始应用程序框架，而不是向平台团队提交工单以帮助配置 CI/CD 或创建云资源。
研发经理希望：
- 轻松地对齐其微服务并设置其 组织标准，以实现 CI/CD、安全性和文档化。
- 为开发人员提供黄金路径，以便在没有帮助的情况下管理自己的微服务开发周期。
通常，构建新应用程序的常用方法是从模板创建新存储库。但是，单个模板存储库可能无法满足开发人员的所有需求。他们可能需要多个 git 存储库、更多与外部工具和平台的逻辑、更多设置自动化和其他复杂性的工作。
手动构建微服务会给开发团队带来真正的混乱。我们从两个角度来看。
当开发人员没有模板时，他们必须逐个拼凑微服务，手动配置和设置基础设施。这会造成混乱，导致编码实践不一致，并且难以达到组织标准。
不得不依赖传统的工单系统来创建基础设施会加剧问题，增加挫败感，造成延误并减慢开发过程。
想象一下，一家大公司的开发人员需要根据产品经理创建的工单开发一个新的微服务。仅仅因为他们已经考虑了所有实施步骤——例如他们将使用哪种语言、如何使其通用以支持不同的 webhook 以及如何编写出色的代码——并不意味着他们已经准备好了。
理想情况下，他们可以检查是否有人已经编写了可以重复使用的代码。然后，他们需要：
- 使用 README 文件和与组织标准一致的文件夹层次结构创建一个新存储库。
- 通过编写基础设施即代码 (IaC) 代码部分来创建 Kafka 主题，以便在其服务旁边启动 Kafka 主题。或者，在较大的公司组织中，他们必须向 平台工程团队 提交工单，这意味着要等待一到三天。
- 为测试创建样板并配置 CI 流程。
- 在每次合并到主分支时配置 SonarCloud 扫描。
- 创建一个新的 Argo CD 应用程序，并通过向 Argo 管理存储库提交拉取请求将其连接到其新服务。
- 将初始应用程序部署到测试环境。
在开发人员甚至可以开始编码之前，这增加了大量的工作。开发人员必须对工程组织的标准有充分的了解才能遵守这些标准。负责舒适区（编码）之外的许多任务会增加认知负荷，并使这些开发人员更难完成待办事项列表。
研发经理也很难指导开发人员解决这些问题。这会影响整个开发工作流程的生产力、创新和效率，并最终影响整体业务。
对于平台工程师来说，工程标准是保持微服务井然有序和一致的关键。他们管理着数百个微服务，并一次又一次地看到相同的问题：不同的存储库结构，这使得难以搜索信息、缺乏必要的文档、未受保护的存储库分支、部署设置问题和过时的版本。
现实情况是，如果没有指导或自动化，期望如此多的不同团队遵守其公司标准是不可能的。
为开发人员提供用于新应用程序的即用型设置有助于解决这些问题。对设置使用内部开发者门户超越了基本存储库，并提供了必要的自动化资源，例如：
- 即用型存储库
- 易于遵循的管道
- Terraform 请求新数据库
- Argo CD 应用程序
- 简单 Kubernetes 部署
- 一个与代码库关联的新 lambda 函数
- 预配置 AWS S3 存储桶
开发者可以使用这些现成的路径轻松遵守标准，并在不出现复杂情况的情况下保持一致性。
要快速入门，请按照以下步骤操作：
没有两个平台团队具有相同的标准和脚手架流程。平台工程师需要询问开发者在打包新应用程序时需要什么，以帮助他们专注于他们最擅长的工作：编写代码。
虽然这些问题的答案可能因团队而异，但它们可能涉及工程师可以自动化或模板化的元素，以便为开发者提供先机和独立性。
通过调查、非正式对话和定性访谈，从开发者那里持续获得有关其痛点和他们希望看到什么的反馈，使工程师能够接受 产品思维。这确保了平台工程师 专注于开发者实际需要什么 来构建应用程序，而不是他们认为应该包含什么。
对于此示例，假设构建新应用程序的脚手架包括创建代码库、配置 CI/CD 和使用 Terraform 创建云资源。
确定哪些参数应由开发者定义至关重要。您希望专注于 抽象化复杂性，因此只询问对自定义脚手架流程真正重要的输入。换句话说，专注于“什么”而不是“如何”，使开发者能够精确定位其项目的特定方面，而无需考虑实现细节。
以下是一些基本的常见输入示例列表：
- 应用程序名称
- 描述
- 编程语言
- Kubernetes 副本数
- Kafka 主题名称
- 数据库
使用开发者的输入，脚手架逻辑可以自动设置新项目，从而消除创建代码库、设置基础设施以及配置工具和环境的手动步骤。
下图中的示例使用 GitHub Action 实现自动化。
该图表显示了自动化如何根据开发者的输入与不同平台进行交互，同时遵守已选择的特定权限并使用公司的最佳实践管理资源。
前面的步骤启用了创建新应用程序的自动化。但这还不够。
使用 GitHub Actions 管理应用程序创建对开发者来说可能具有挑战性，这凸显了对集中式解决方案的需求。一个具有直观用户界面、详细的基于角色的访问控制 (RBAC)、强大的输入验证和自定义审批流程的自助服务门户可以极大地简化应用程序设置流程，而无需额外的开发工作。
我将演示如何使用 Port（一个用于 创建内部开发者门户 的无代码平台）来实现此目的。Port 可以与您现有的自动化集成，用直观的用户界面对其进行包装，并为开发者创建简单、抽象的体验。Port 还支持管理和触发长期运行和异步操作，并向开发者显示他们需要的运行日志。
当用户在开发者门户 UI 中触发自助服务操作时，该过程便开始。
一个包含用户输入和相关操作元数据的有效负载被发送到所需的 GitHub 工作流。
触发作业，用户会持续收到有关其进度的指示。
一旦您构建了与脚手架逻辑匹配的自定义自助服务体验并使用它创建了应用程序，您就可以在一个地方可视化所有已创建的资源（例如，Argo 应用程序、云资源、Sonar 扫描），以与相关应用程序相关联。这样，整个过程及其输出都会在每个步骤中反映给您的开发者。
一旦一切设置就绪，使用 Port 创建新应用程序的例程如下：
- 开发者登录到 Port，然后在自助服务中心中单击“构建新服务”操作。
- 开发者在自定义表单中提供脚手架流程的相关输入。
- 操作启动，脚手架流程反映在 Port 中，包括流程状态和日志。
- 一旦应用程序搭建完成，开发人员就可以在服务目录中看到它，并连接到相关的资源，例如 SonarQube 问题、Argo 应用程序、Amazon RDS 实例、AWS S3 存储桶和 Kafka 主题。
- 应用程序及其相关实体也可以在鸟瞰图视图中可视化。
您已创建了应用程序，但还没有完全完成。上述过程是确保应用程序符合标准的第一步。从那时起，您必须确保维护标准。为此，您可以使用该门户的记分卡 来评估应用程序的成熟度、生产准备情况和工程质量。
为了简化搭建新应用程序的过程，您需要戴着产品经理的帽子思考：搭建必须满足开发人员的目标，同时确保该过程融入您组织的 DNA。Port 使您能够自定义流程以适应您的文化和标准。通过这样做，您可以在保持护栏的同时为开发人员提供最佳体验。
有关搭建新应用程序的更多见解，请查看我们的分步指南。