👉️URL: https://thenewstack.io/3-steps-for-automating-software-release-management/
Author: Wolfgang Heider
📝Description:
The speed of release cycles now results in a need to automate as much as possible, to ensure organizations can compete in this fast changing environment.
“发布还是不发布？” 是发布经理的日常工作。 这是许多开发或运维软件的人所面临的问题，并且与部署新软件版本的风险直接相关。 这是我个人在发布管理领域工作时每天都要处理的事情，作为一名产品所有者，我需要设置持续交付、实施 DevOps 范式并使其他公司变得更加敏捷。
发布经理的工作很艰巨，他们需要对不完整的数据做出决策–根据组织的不同，可能有多个角色（如首席软件工程师、基础架构运维，有时还有公司的法律权威）参与发布或不发布软件的决策，涉及的人员多达数十人或数百人。
现在，随着自动化的不断发展，这些角色都在发生变化。 没有时间手动收集决策所需的所有事实。 已经过渡到敏捷软件开发、DevOps、持续交付或测试自动化的组织都会强制执行任何决策的自动化 - 或者至少需要自动化来提供关于是否按下发布按钮的所有事实。 发布流程的自动化可以提高发布频率和渐进式交付策略，同时在预生产和生产阶段并行运行多个版本。
发布周期的增长速度导致了对尽可能多地自动化的需求，以确保组织能够在这个快速变化的动态环境中竞争。 根据今年发布的 云原生计算基金会调查 显示，每日、每周和临时发布的数量大幅增加：
对于大多数组织来说，软件产品生命周期涉及的工具链通常超过 10 种不同的工具，有助于实现自动化。 这不仅仅是工具的普及和自动化程度的提高; 每个版本的批准和决策过程的数量也会增加。 手动收集数据的工作成为了发布自动化和自动化软件生命周期的瓶颈和致命弱点。
自动化基于发布风险的任何决策制定不仅仅是规则集的实现和自动化工程师的一些脚本编写。 它还需要领域知识来考虑软件提供的服务、设置的法律服务级别协议（SLA）以及任何软件版本如何影响 SLA。
软件版本感知和影响分析的三个步骤
当评估新软件发布的风险时，会出现多个问题，并且会努力使此过程更加透明和可测量。 以下是我作为发布管理员使用的典型检查表：
第一步：我们是否有新版本？ 是否已通过 stage 环境？
- 我们目前有哪些新版本正在开发中？
- 我们的交付流程中的特定版本进展如何？
- 新发行版的变更日志是什么？
- 我们可以预期哪些已知的错误？
- 我们在测试结果和软件质量方面是否安全，或者我们是否有任何 block 点？
第二步：当前在生产中运行的软件的状态是什么？
- 当前版本在生产环境中提供了多少可用性？
- 当前版本在生产环境中的性能如何？
- 当前版本在生产中消耗多少资源？
- 我们在生产中是否有正在进行的发布和部署; 例如，是否有当前从以前版本重定向到新版本的负载？
- 新版本在可用性、性能和资源消耗方面的行为如何？
第三步：发布可能产生什么影响？
在进行任何影响分析之前，需要回答上述问题。有关新版本和当前生产状态的答案有助于告知以下内容：
- 新版本将对资源消耗产生什么影响？
- 新版本将对性能产生什么影响？
- 新版本将对可用性产生什么影响？
- 从营销的角度来看，这次发布会对我们的品牌产生负面影响吗？
定义发布的影响并尝试对其进行量化以确保公平和准确的决策是发布经理的全职工作。通常，发布压力会导致发布经理根据不完整的数据或在其无法控制的业务条件的胁迫下做出“发布 / 不发布”的决定。
定义和评估用于生产监控的 SLO
管理发布新软件版本的风险与生产中当前版本的可靠性密切相关。Google 发布的站点可靠性工程 （SRE） 资源 涵盖了有关软件服务可靠性的许多操作观点，包括 SLI 和 SLO。SLI 和 SLO 为 SLA 提供了基础。
SLO 定义示例
对于任何软件版本的方案，都会出现问题：
- 由于 SLO 故障而违反任一客户的 SLA 的风险是什么？
- 生产中任何 SLO 的当前状态如何？
- 在违反 SLO 之前，我还剩下多少错误预算，失败的请求，缓慢的加载时间或停机时间分钟数（或“错误预算”）？
- 新软件版本对我的 SLI/SLO 有何影响？
SLO 的评估不仅限于生产，还可以应用于预生产或任何部署场景中的质量门禁。Keptn 是发布自动化的开源项目，它已经提供了基于 SLO 定义的 自动化质量门禁 - 生成用于 SLO 的指标并根据任何目标目标进行评估。
在生产中的新软件到达客户之前对其进行 SLO 评估
在决定发布或不发布之前，必须回答有关生产中 SLO 的所有信息和所有问题，以及有关新软件版本在定义 SLO 方面的行为数据。同样重要的是要考虑发布的频率，以及因此手动收集数据以部署这些版本所需的工作量增加。
在不断变化的 DevOps 和持续交付世界中，如果自动化不应用于为任何数据收集和决策提供答案和建议，则发布管理以及发布经理的角色可能会变得繁琐，并成为软件产品生命周期中的瓶颈。评估新软件发布的风险作为任何发布决策的基础，涉及将有关生产中 SLO 的当前状态和对 SLO 结果的潜在发布影响的答案结合起来。了解新软件版本的状态、内容和进度、生产 SLO 状态以及新软件版本的 SLO 评估结果（无需为每个版本手动操作）使发布经理的工作更加轻松。
例如，如果生产中没有剩余的错误预算，那么一个简单的下一步可能是运维团队定义任何进一步发布的回退 - 当然可以自动化。但是，即使生产中还剩下一些错误预算，如果较新版本在 SLO 评估方面表现较差（例如，与当前在生产中运行的版本相比，性能相对下降，并且剩余错误预算最小），也应该自动停止发布。
需要评估在发布过程中 stage 环境的新软件版本以及已根据 SLO 评估进行测试的测试运行分析结果。为生产环境提供的 SLO 定义（例如，对于所有请求的 95%，特定服务请求需要在 600 毫秒内返回），可以在测试阶段进行评估，在测试阶段，可以及早发现性能下降。
因此，甚至可以在软件到达生产和客户之前检测到 SLO 违规，从而为新软件版本提供 SLO 违规的根原分析。在预生产中建立监控定义可以安全可靠地将版本从 stage 环境移动到生产阶段，同时对任何 SLO 产生负面影响的风险最小。
