很长一段时间以来，DevOps 都在改变软件构建和部署的游戏规则。添加基础设施即代码 (IaC)、容器化以及高度自动化的云和内部活动等创新功能之后，您可能会觉得我们有添加这些功能，DevOps 显然会继续看到在未来会有更多的增强活动和新的方向。在不影响任何人的情况下，变更管理 DevOps 迅速成为热门话题。
在我们探究变更管理和 DevOps 之前，让我们来看看我们在谈论变更管理时所指的内容。请勿将该术语与配置管理相混淆。我们在谈论的不是软件版本控制，而是更大的一个方面。术语“变更管理”侧重于支持、跟踪和记录组织变更的方式和方法。在这篇博文中，我们不会讨论组织变更，而是将流程、系统或基础设施中的变更作为变更管理的一部分，其中也包括部署环境中的变更。在现代社会，组织必须按照市场变更、技术变更、新的法律法规和其他驱动变更需求的力量，经常修改其结构或基础设施。组织的规模越大，变更就变得更加具有挑战性。我们显然需要采用良好的做法和流程来支持成功作出变更。
要持续保护我们监管的系统，同时进行可靠的变更管理和 DevOps 是至关重要的，其中损失和冲击处于最小水平。然而，DevOps 变更管理的采用及其本身被设计成为一种“踩刹车”措施。就像任何配备移动部件的机器一样，关键是要适应这些变更。对于那些准备迎接挑战的人们而言，这是另一个机会，使变更管理过程成为对生产环境进行深思熟虑和良好沟通的变更的前进的又一步。
当我们谈论变更管理时，我们指的是什么？
变更管理不是一个新概念。有些人认为变更管理影响了软件开发团队的工作效率。这是因为团队需要实现可追溯性和方法，来显示影响生产环境的变更的审计跟踪。如果与现有的自动化和做法集成，实现 DevOps 变更管理便可以不那么棘手了。
针对现代企业或小型企业的这种类型的变更管理被公认为是 IT 服务管理（或 ITSM）。这种管理是一种用于控制与基础设施和生产配置相关的变更的所有方面的方法。一些 DevOps 团队可能不熟悉我们现在需要为进行审计而保留的信息量。这有时会防止因另外落实变更管理流程而尽可能快地产生微小变更。
变更管理如何来适应 DevOps 呢？
方法有很多！其中最重要的是，许多企业都需要进行变更管理。进行变更管理不仅是因为要进行内部审计，而是要实现合规和进行认证。要在全球开展业务，必须遵循数据标准。例如，《通用数据保护条例 (GDPR)》自 2018 年 5 月 25 日起生效。任何在欧盟境内外经营的人都必须遵守该地区与持续经营相关的这些标准，否则将面临经营困难的风险。这些类型的标准和法规是企业和规模较小公司都应该考虑 DevOps 变更管理的部分原因。
想想我们能够在经营过程中做出即时生效的改变。毕竟这是我们起初实现自动化的全部原因。虽然变更管理和 DevOps 可能看起来无法结合，但正确的 DevOps 理念和工具都将显示这实际上是一种保险的做法。在某种意义上，由于进行了额外的沟通并通过尽职调查最终敲定流程，这种做法能够保护 DevOps 工程师。
简单地说，变更管理和 DevOps 不仅是作为独立方法而且具有相关性。从在有机会的情况下可以结合二者这方面来看，二者都具有相关性和必要性。引入自动化工具，通过使用现有 CI/CD 工具的更快迭代来促进变更管理，是实现这二者的结合而迈出的坚实的一步。
变更管理和 DevOps 的利益相关者有哪些？
如果您在几年前问这个问题，您可能会得到关于实现 DevOps 变更管理的方面的较小计数。实现 DevOps 变更管理的规模和范围取决于很多因素。随着前述法规的采用和对网络安全的关注，了解面向客户的系统的演变的需求已经超出了 IT 或软件团队。
必须承担责任的任何人采用方法来展示或防止对生产环境作出的某些变更是明智的做法。这种做法会很容易被认为是一种“C.Y.A.”，但它实际上是为了更多地关注提议作出的变更，也是向他人说明整体经营状况的一种方式。保持平静的心态有助于让一台运转正常的机器保持运转。
因手边任务的不同，肯定会出现例外情况。例如，如果我们开发工程师要针对每项访问请求都一份编制变更管理工作流程，便不能有效率地完成工作。另一种可能发生的情形是会有故障排除性能或者生产错误。在生产环境中执行的这些操作和其他操作属于低接触操作，通常被认为可以在未获得变更管理委员会的批准情况下予以完成。
DevOps 保持变更管理的方式有哪些？
从一开始，DevOps 理念有助于帮助通过采用旨在保护主要代码库的分支策略来跟踪变更内容。这是一个在敏捷的工作流程中使变更与任务保持一致的切入点。变更包括在生产环境中发布新版本，或者改变这种资源的配置情况吗？对于软件更新方面，最初通过分支来跟踪变更仅有助于工程师排查、恢复或修复这些变更。
在前文中，我们提到了如今关注的是网络安全和合规方面。DevOps 已经在许多方面通过 DevSecOps 和 “左移”软件开发方法包含了这两方面。在问题发展成为实际问题之前发现这些问题，可以防止在变更管理的过程中浪费大量时间。
让我们一起来看看简单的 CM 工作流程：
- 提出请求，且初步分析确定是批准或是驳回变更。虽然这听起来简单，但分析不仅包括产品如何受到影响这方面。同样清楚的是进行变更可能如何影响安全性、稳定性和可追溯性这三方面。
- 由实施团队进行规划，并通过发布核查表等文档向变更管理委员会作出演示。
- 委员会及其涉及变更的其他成员进行评估，并批准往下进行。
- 按计划进行变更，并在下一个版本中记录任何偏差情况。
- 已审核变更，并向团队报告相关状况。可以讨论和记录关于成败的信息以及任何其他相关的细节。
- 在完成之前的所有步骤之后，可以关闭变更。
随着我们进行的每一次冲刺，成功进行变更管理的主要公司的名单也在扩大范围。例如，谷歌是实现了该过程的大型公司，这并不出人意料。除谷歌外，还有一些其他知名企业包括网飞、乐高和可口可乐等。您可以点击此处更多地了解成功进行变更管理的公司和其他真实示例。
变更管理和 DevOps 工具
我们还谈论了一些目前使用的技术，这些技术正在被集成到变更管理中。团队在工作流程中使用 Git，这是精明团队为进行审计或根本原因分析而开始整合可追踪数据的一种方式。但 DevOps 团队可能会使用哪些其他工具来协助进行变更管理呢？
通常用于显示完整流程的一种简单工具为流程图。流程图和流程映射可以可视化地表示所需变更。在查看变更是否遵循特定的操作顺序时也可以参考流程图。同样地，在项目规划中倾向于使用甘特图。甘特图同样实现了可视化表示，以帮助更好地查看项目。
还有一些软件包旨在帮助实现工作流程的自动化，从而简化变更管理流程。ChangeGear 承诺帮助实现自动化，以支持复杂的变更和业务流程。Freshservice 还通过帮助计划所有方面，来帮助进行基于云的变更管理。这些工具承诺通过必要的批准，帮助组织简化规划过程。
在软件开发领域，通常通过敏捷流程来完成任务特性请求或错误修复。敏捷方法部分涉及会议、规划和架构信息，这些信息通常包含在任何正在使用的任务系统的票证中。在开发过程中使用标记有助于开始通过变更管理和 DevOps 实现自动化方面的合规。
由于在软件开发行业中可以使用设计用于寻找特定项目的工具，因此对安全问题和合规性的核查变得更加容易。这些项目是以当前的行业安全标准以及可以为团队创建特定用途的规则为基础的。这些项目还可以与某个行业相关联，或者以特定的合规法规为基础。
尽管如此，可以在针对许多 DevOps 工程师和方法的变更管理过程中使用更多的工具。工程师可以通过基础设施即代码 (IaS) 以一种可以纳入到变更管理过程中的方式，在现有环境中设计、验证和实施新的变更。通过 Terraform、Azure ARM 模板和 Kubernetes 清单等工具，其他人可以审核并决定是否应批准该变更。
结合现有工具开展协作是变更管理和 DevOps 共同实现自动化合规的方式。虽然并不是完全不干涉，但我们可以通过现有工具查找我们通常会在进行变更之前检查的许多事项。
最后，我们现在只是看看自动化是如何在变更管理等流程中发挥作用的。要找到更多关于结合变更管理和 DevOps 的解决方案，可以寻找使用工具的新方法，并邀请社区参与进来。并非所有流程都适合您的团队。您可以侧重于适合您的环境的部分，并努力不断改进方法，以便通过 DevOps 支持变更管理。
