为什么发布周期总是停滞不前

我们公司有十个应用程序在生产环境中，每个月都会更新。“发布开发人员”或“发布工程师”的角色在团队内部轮换，每次发布都会进行更新。

为了遵循最小权限原则 (PoLP)，我​​们希望仅在发布开发人员需要时才授予部署权限。因此，在每次发布之前，我们都需要能够授予合适的人员部署到生产环境的权限，并在发布后撤销他们的访问权限。

分配项目角色 Mendix

In Mendix 你可以通过分配一个 具体作用。截至 2025 年 XNUMX 月，我们做出了一些更新：

• 只有公司管理员可以定义角色。
• 角色现在可以包括公共云环境权限。
• 您也可以使用 项目 API 将团队成员分配到具有特定角色的项目。

对于此发布周期示例，我们需要设置两个角色：一个是常规开发人员，另一个是具有部署到生产权限的发布开发人员。

创建常规开发人员角色

让我们首先创建一个普通的开发者角色。在 控制中心 按一下 员工 菜单部分并打开 角色和权限 部分。

1 – 编辑项目角色详细信息部分

由于已经有了定期 开发商 选择一个角色后，我们将首先编辑该角色。第一步是描述该角色将拥有哪些权限（例如，参见下方截图）。

2 – 编辑项目权限

完成描述后，点击 下一篇 为该开发者角色设置项目权限。以下是一些需要考虑的事项：

• 项目管理员权限： 我们建议仅将此权限分配给（系统）Scrum Master 角色。该权限允许用户管理团队成员权限并更改项目设置——这些操作非常强大，应该严格控制。
• 团队服务器权限： 此权限授予访问团队服务器的权限，以便开发人员提交其工作。这对于任何开发人员角色都至关重要。
• 规划和反馈： 开发人员需要此权限才能查看和处理分配给他们的用户故事。
• 邀请成员： 我们建议将此权限限制为（系统）Scrum Master 角色。该权限允许用户邀请新成员加入项目并为其分配角色，因此最好将其保持在最低限度。

3 – 设置非生产环境权限

访问权限

首先选择该角色是否应该具有非生产环境的访问权限。

• 对于开发人员角色，需要一定级别的访问权限。
• 对于其他角色，您可以将其设置为 禁止访问，这意味着用户将不会获得非生产环境的任何权限 - 并且您可以跳过该角色的本节其余部分。

权限管理：固定与自定义

此设置控制如何应用和管理非生产环境权限。

固定

当角色使用“固定权限”时，角色定义中列出的权限将自动强制执行。分配了此角色的用户将获得此处定义的确切权限，项目中拥有 管理云权限 将无法手动更改具有此角色的成员的权限。

简而言之，这意味着公司管理员可以确保项目中具有此角色的成员具有此处列出的权限。

定制化

使用自定义权限时，角色本身不决定访问权限。权限必须在 Mendix 由具有适当权限的人员管理或通过 API 设置的开发者门户。

重要提示：如果用户已拥有权限（例如 Scrum Master），则分配自定义权限的角色不会自动撤销这些权限。这些现有权限将保留，直到手动或通过 API 更改为止。

我们建议尽可能使用“固定”权限，因为它能为您提供完全的集中控制，并避免意外的权限差距。仅当您必须区分不同的非生产环境（例如允许部署）时，才使用“自定义”权限 研发支持 和 《测试》（Test）， 但不是 接受.

就我们的开发人员角色而言，除了管理权限本身的能力之外，我们还将授予开发人员在非生产环境中的完全权限。

4 – 设置生产环境权限

在编辑项目角色的最后一步，我们将配置生产环境权限。由于任何生产环境的更改都需要双因素身份验证，因此公司管理员需要先对帐户进行身份验证，然后才能继续操作。

身份验证完成后，我们就可以设置相应的权限了。开发者应该能够监控其应用在生产环境中的运行情况，因此授予监控权限是个好主意。

这样，常规开发人员角色就设置好了。现在，当开发人员在项目中被分配到此角色时，他们将能够立即部署到非生产环境并查看生产环境中的监控信息——这在过去需要由 Scrum Master 或技术联系人手动配置。这极大地提高了生产力！

创建发布开发人员角色

接下来，我们将定义发布开发人员角色——专门用于部署到生产环境。

为了鼓励仅在需要时使用此角色（并确保部署后撤销），我们将对其权限进行严格限制。这意味着拥有此角色的团队成员需要恢复其常规开发人员角色才能继续正常工作。

这意味着..

• 无项目权限
• 无法访问非生产环境

...并且仅具有以下生产环境权限：

• 部署——发布到生产环境
• 备份——在部署之前创建备份
• 监控——确认一切顺利

如何运用这些角色

可以通过多种方式为开发人员分配项目中的角色：

• Scrum Master 可以添加/邀请具有角色的开发人员。
• 公司管理员可以添加/邀请具有角色的开发人员。
• 该项目的 API 用于将开发人员添加到具有角色的项目中。

如果像 Gaby Gable 这样的单个开发者需要发布多个应用程序，公司管理员可以按照以下步骤分配 发布开发人员 在必要的项目中发挥作用： 控制中心，在 成员名单:

单击她的名字即可查看她参与的所有应用程序的列表。

点击应用程序名称打开 软件详情 面板。前往 会员专区 页面。

点击后 管理会员，将 Gaby 的角色改为 发布开发者。

对每个需要发布的应用重复这些步骤。角色更新后，Gaby 将拥有在所有分配的应用中部署的正确权限。

发布完成后，公司管理员可以使用相同的流程将 Gaby 恢复到她的原始角色 - 确保她返回常规开发人员访问权限而无需不必要的生产权限。

授予特定环境的临时权限

有时，您可能需要授予团队成员临时访问某个环境的权限，但并非访问所有生产或非生产环境。具有固定权限的角色不支持这种粒度级别；它们会将权限应用于生产或非生产类别中的所有环境。

那么，如果你有多个生产环境，例如 生产部门 和 生产2，并且你只想授予临时访问权限 生产部门?

对于此用例，您可以定义 开发者自定义 角色。与普通开发人员拥有相同的权限，但项目角色不包含（非）生产权限，尽管可以手动或通过 API 设置。

处理方法如下：

将非生产和生产权限设置为 定制化.

假设 Gaby 当前拥有一个具有固定权限的角色。这意味着她的环境访问权限已被锁定，Scrum Master 或技术联系人无法更改该权限。

您可以在 Mendix 门户网站 应用程序的 权限 的选项卡 生产部门 环境——她的权限将显示为只读。

为了使 Gaby 的权限可编辑，请为她分配不同的项目角色，在本例中， 开发者自定义.

此新角色拥有与普通开发者相同的项目级权限。但是，由于其环境权限是自定义的，因此现在可以由拥有环境访问权限管理权限的团队成员（例如技术联系人）手动更新，也可以使用 Deploy API 进行更新。

这使您可以灵活地授予对单个环境的临时访问权限，而不会影响对所有其他环境的控制。

平衡灵活性与控制力

自定义角色让您能够灵活地处理异常情况（例如授予对单个环境的临时访问权限），而不会破坏您的安全模型。另一方面，当您希望在所有项目和环境中强制执行一致、集中的权限时，固定角色是理想的选择。

通过精心结合两种方法，您可以支持一项关键的安全最佳实践：最小特权原则 (PoLP)。这意味着每个团队成员都只能获得完成工作所需的访问权限——不多不少。使用固定角色作为默认设置，并将自定义角色保留用于特殊情况，有助于最大限度地降低风险，同时保持发布流程的顺畅高效。