Microsoft 365 在对系统进行代码和非代码更改以保持其安全态势时强制实施变更管理过程。 任何与初始状态的配置偏差都可能会引入漏洞、中断功能或中断可用性。 在 Microsoft 365 中部署了可靠的安全态势的信息系统后，将强制实施详细的变更管理流程来帮助维护系统完整性。
Microsoft 365 中有许多变化的驱动因素，包括新的功能或安全要求、客户的反馈、识别的漏洞和审核结果。 无论更改的驱动因素如何，服务团队都使用票证或源代码管理工具来记录批准证据并跟踪所有更改。
源代码更改
根据 Microsoft 的安全开发生命周期 (SDL) 部署更改，随后是 Microsoft 365 中的所有工程和开发项目。 这是一种软件开发模型，其中包含与代码评审、测试和审批相关的特定安全注意事项，然后系统地将其发布到 Microsoft 365 环境。
SDL 充当框架，包括识别已完成开发项目的可能风险，以及可在开发阶段实施和测试的缓解策略。 还包括关键安全评审和审批检查点。
更改标识和规划
服务团队定期开会讨论建议的更改，包括理由、范围、安全影响、优先级、依赖项、部署计划、角色和职责。 此信息记录在更改管理跟踪系统中。 如果更改被拒绝，则理由将显式记录在票证中，以供将来参考。
人员代码评审
在将任何新代码包含在新版本中并部署之前，它必须通过人员代码评审。 这些评审的强制执行是通过附加到每个代码存储库的自动化代码管道处理的，无法规避。 收到所需的批准后，代码可以进入下一阶段。
代码审阅者检查编码错误，验证更改是否符合要求，并执行安全影响分析。 审查必须由制定准则的人员以外的人进行，并强制执行职责分离原则。 防止同一人员提交和批准自己的代码是 Microsoft 严格强制执行的关键控制措施。 这大大降低了用户有意或无意地、有害或错误代码的单独发布的可能性。 如果审阅者在代码评审过程中发现问题，他们会停止更改，并让开发人员使用建议的更改和其他测试重新提交代码。 代码审阅者还可能决定对不符合所标识要求的代码完全拒绝检查。 审阅者认为代码令人满意后，会提供审批，并将代码签入main分支，以包含在下一个生成中。
自动生成管道和安全检查
将冲刺的所有更改提交到 main 分支后，将开始自动生成过程。 代码会接受各种自动安全检查，包括静态代码分析、二进制分析、凭据和机密扫描以及加密扫描。 Microsoft 365 定义了一组基本测试，每个生成在部署到预生产环境之前都必须通过这些测试。 未通过的生成将被拒绝并发送回开发团队，在该团队进行调整，直到所有检查都通过。 成功的生成通过自动化部署管道进入预生产环境。
内部版本发布
版本最初仅发布给开发该功能的服务团队。 在发布之前，在逻辑隔离的云环境中（称为环）中逐步测试更大的测试组的稳定性和功能。 在服务团队之后，生成将发布到所有内部 Microsoft 365 组，然后向所有内部 Microsoft 组发布内部版本。 此测试（在内部通常称为 dogfooding）允许 Microsoft 在向外部客户发布生成之前识别真实生产环境中的 bug。 这些测试方法可确保 Microsoft 代码在到达客户和全球部署之前安全并按预期运行。 以前的版本始终保留以用于回滚目的。
工程团队确定生成在每个环中花费的时间，通常在多个高负载期间停留，然后再继续下一个环。 如果每个内部圈中的所有测试都成功，则内部版本将发布给全球客户，首先作为已选择加入该圈的客户租户的目标发布，然后是全球标准版本。
非代码更改
非代码更改定义为对 Microsoft 365 系统不涉及创建或编辑服务源代码的任何修改。 这可以包括打开端口、更改访问控制 Lists (ACL) 或对基础系统的其他更改。 相比之下，非代码更改的发生频率低于代码更改，但仍需要高级别的审查。
更改说明以及实现步骤、验证步骤和回滚计划。 在实施更改之前，至少一个人对计划的准确性和安全性影响进行同行评审。 批准后，将实施记录的计划。 如果所有验证步骤都成功通过，结果将记录在票证中，并将其标记为已解决。
如果更改的实现不成功，则会触发回滚计划，团队将返回到规划阶段，并重复该过程，直到成功。