入职可以是一个有据可查、最新的、可重复的过程，它可以帮助新员工快速提高工作效率，而无需提出太多问题。
译自 Improve Developer Onboarding With an Internal Developer Portal，作者 Jonathan Gruber。
开发者入职归结为教育新队友了解你的软件开发生命周期 (SDLC)，以便他们交付软件。根据人力资源管理协会，大约 70% 的新员工 在美国工作超过三年，如果他们有积极、结构良好的入职体验。这也 提高了他们的生产力和保留率 分别达到 58% 和 60%。
但如果你曾经为新队友进行过入职——或者自己经历过入职——你就会知道像这样的任务有多么耗时。有时你花在 回答问题和提供反馈 上的时间比执行与实际角色相关联的任务还要多。
为新开发者进行入职会消耗大量时间和资源，因此它通常会出现在冲刺中的一个单独任务中，这会占用团队本可以用来开发新功能的时间。另一方面，新开发者必须了解很多关于公司文化、政策和同事的信息——他们最不需要的就是低效的入职体验。
内部开发者门户 可以简化入职体验并解决众多入职挑战。我们来探讨一下它是如何做到的。
内部开发者门户 可以解决一些特定的痛点。其中包括：
- 缺乏明确的入职流程：缺乏明确的流程会导致延迟、混乱和开发者完全消极的体验，甚至可能影响员工保留率。
- 配置工具、访问控制和可见性：必须向新开发者授予其新的软件开发生命周期 (SDLC) 的每个部分的访问权限。他们也可能无法在某些工具中看到其他相关服务，除非他们获得完全编辑权限，这可能会带来不必要的风险。总体而言，有时可能需要长达 10 天才能向新开发者授予他们所需的所有服务的访问权限。
- 了解代码和相关软件基础设施：每个应用程序都是独一无二且复杂的。理解不同服务、运行时资源和工程团队之间的关系可能需要几个月的时间才能掌握。
- 提供任务和模板操作：入职的最终目标是为你的团队增加一名有效的新成员——那么为什么不向他们提供他们开始工作所需的一切呢？模板任务和操作可以使开发者更快速地自主工作，从而缩短他们达到生产力的所需时间。
开发者需要记住很多内容，例如入职任务的顺序、如何交付特定角色的权限、服务如何相互交互——以及像往常一样交付新功能或提交。我们深入了解这些 摩擦点，并研究内部开发者门户如何解决这些问题。
入职的目标是帮助团队成员尽快提高生产力，使该结果比记录流程更有价值。
DevOps 或平台工程师通常承担早期入职的主要任务，因为他们必须提供访问权限并弄清楚：
- 每个开发者需要访问哪些工具。
- 如何设计他们的权限。
- 每个开发者根据其角色需要对其他团队设置的可见性级别。
每次必须为开发者进行入职时，弄清楚所有这些都会消耗团队宝贵的时间。如果没有明确的流程，开发者可能会因其角色的复杂性而不知所措，无法轻松识别服务所有者或最佳实践，并且总体上脱离他们的新团队。这不仅会对你的新开发者产生负面影响，还会给你的现有团队带来额外的压力，这些团队负责使新开发者适应他们的工程环境。
使用内部开发者门户，你可以为不同的常见开发者角色创建特定的入职结构。与传统的入职流程（或缺乏流程）相比，这种视图提供了许多好处，包括入职体验的可重复性、特殊性和标准化。 门户大幅减少了准备工作，以接纳新员工并标准化流程，确保所有新开发人员的接纳体验一致且直接。反过来，这会提升新开发人员的满意度和参与度，有时提升近 70%。
如果没有适当的工具和软件访问权限，开发人员无法进行首次提交或执行任何有价值的操作。另一方面，如果开发人员拥有过多的访问权限，则会引发隐私和安全问题。
在接纳上下文中，很难跟踪每个开发人员需要访问哪些服务以及他们需要多少访问权限或哪种类型的访问权限。随着开发人员离开公司、调动团队或项目，或需要特殊权限来完成一次性任务，这种情况也会随着时间而改变。这增加了 DevOps 和平台团队的权限复杂性。
如果您正在接纳外部开发人员，包括供应商和承包商团队，当他们需要访问敏感的生产环境或发布管道以启用新软件或构建功能时，就会出现其他问题。
内部开发人员门户通过基于角色的访问控制 (RBAC) 解决这些问题，该控制可以根据时间限制以及组织内的角色授予和撤销对不同服务的访问权限。导入单点登录 (SSO) 还可以通过将外部团队的基础设施导入到您的门户中来批量处理权限：
门户可以将服务视图限制为仅限于用户的服务和资产。
内部开发人员门户还使您能够控制每个开发人员可以看到的内容、有权访问的内容以及他们在每个环境中拥有的特定权限。
动态决定谁可以看到哪些目录页面，例如，只有具有管理角色的用户才能访问指标页面。
动态 RBAC 控制确保用户只能看到其团队的服务或资产。
这些权限也可以在团队级别查看，这在构建开发人员自助操作和体验时非常有用。所有这些权限也可以在门户内更改，无需在各个服务之间跳转。
让我们重新审视我们的接纳情况：您刚开始工作，需要了解您负责的代码。您需要弄清楚：
- 代码运行在哪里。
- 它依赖哪些（如果有）其他微服务。
- 微服务如何分解。
- 在哪里可以找到每个微服务的描述（如果存在）及其 API 规范。
- 谁负责您自己的服务正在调用的其他微服务。
在这一点上，您可能会发笑，因为一个人不可能记住构建现代网站所需的数千个组件。即使有全面、维护良好的文档，服务和依赖项也经常发生变化，以至于任何手动文档通常都会立即过时。
内部开发人员门户提供服务目录和蓝图，通过以图形方式展示互连服务之间的关系来添加到目录中。服务目录和蓝图相结合，为新开发人员提供了公司用于生产软件的每项服务的完整、最新列表，从暂存和演示环境到其实时生产环境：
我们新开发人员的服务及其相关云资源、API 和运行时资产的信息视图。
我们服务、其依赖项和云资产的图形视图。
通过门户中的这些视图，新开发人员可以立即了解他们开始工作所需了解的一切，从而节省了向经理和同事提问的时间。
这些工具减少了对冗长的解释和白板的需要来解释服务之间的关系及其交互方式。它们还消除了维护单独文档的需要，因为蓝图和目录都会在创建新服务时自动摄取新服务并导入其他相关服务之间的关系，从而实时维护更新的服务依赖关系和关系图。
现在，我们的新开发人员已经获得了对工具的适当访问权限，并了解了他们拥有的服务及其相关组件，他们仍然需要知道从哪里开始或他们的任务是什么。
请看下面的示例，它展示了为开发人员提供的“计划我的日程”体验，其中列出了他们当天的任务：
在 Port 中构建的开发人员体验，这是一个开放的内部开发人员平台。
这篇关于规划体验的简短视频在开放的内部开发人员门户中进行了更多解释。
内部开发人员门户可以轻松提供开发人员任务的动态视图，以便他们可以识别他们需要做的下一件事。您可以在门户中创建视图，向开发人员显示：
- 他们需要完成的下一个入职任务。
- 他们的公开缺陷。
- 正在等待审查的拉取请求（以及他们已经等待了多长时间）。
- 正在进行的事件。
- 影响其服务的主要漏洞。
内部开发人员门户为每个开发人员提供他们拥有的任务，并进行动态筛选。
这些任务通常称为第 2 天操作，它超越了培训的初始阶段，并为开发人员提供自主感，从而提高他们的生产力和满意度。在门户中提供第 2 天操作还可以通过明确转移重点的位置来缩短新员工的生产力时间。
自助操作还有助于抽象内部流程的复杂性。这些操作可以让开发人员立即执行任务或部署资源，遵循黄金路径，这通常不会在他们的第一个月内对新开发人员提出期望。
使用模板化自助服务操作，新开发人员可以轻松地按照公司的黄金路径执行任务，而无需担心犯错或需要深入审查。
在一些内部开发人员门户中发现的自动化工作流还允许您向需要审查工作或将任务链接在一起以完全自动化入职的经理发送 Slack 提醒。您还可以自动化标准管理，这可能有助于新开发人员在首次编码时建立对内部最佳实践的了解。
新开发人员入职需要大量基础工作、维护良好的文档和可重复的流程——在典型情况下，这些事情既耗时又复杂。内部开发人员门户通过以下方式消除了一些复杂性：
- 定义入职流程：在门户中构建入职体验后，您可以将其用于新开发人员或作为其他类型入职体验的模板，从而推动标准化。这消除了在门户外部维护内部文档或入职文档的需要。
- 提供工具、访问控制和可见性：开发人员可以看到他们需要的一切，但只能访问和编辑他们拥有的服务。
- 显示代码和软件基础设施之间的关系：服务目录提高了自主性和透明度，使新开发人员更容易根据 SDLC 定位自己并根据需要采取行动。
- 鼓励自主性和生产力：内部开发人员门户中的视图将操作、服务、工单、任务等定制到一个地方，使新开发人员更容易开始工作并更快地提高生产力，而且动手培训更少。
如果您不确定从入职体验开始，请查看我们的终极开发者入职清单以获得一些灵感。如果您尚未使用内部开发者门户，请查看我们的现场演示并加入我们的社区！