为软件发布过程带来结构

释放还是不释放？就是那个问题。但是，通常是根据直觉而不是具体数据做出决定。有权访问数据以及结构化的部署过程可以帮助避免发布故障软件。

坦白说：您的公司在发布软件更新时使用什么标准？如果您没有明确的答案，那么您并不孤单。太多的团队没有明确的标准来定义何时可以发布更新。但是在DevOps和CI / CD时代，开发人员和项目经理应该定义清晰的决策流程，并就统一的发布标准达成共识。如果没有明确的流程来决定何时发布软件版本，则公司可能会遇到生产中的严重错误。

流程因公司类型而异

各个公司的处理软件版本的方式差异很大。具有庞大用户群，几乎无限资源和基础架构的公司能够快速发布，并在必要时撤回发布。这样，可以以较高的频率向一小部分用户提供更新，并且系统会自动检测何时出现问题，以便可以使用以前的版本。这样的公司由于采用这种方法可能承担更多的风险，但它们也需要数量惊人的基础架构，DevOps托管和大量客户。另一方面，更多的传统公司倾向于规避风险，并遵循结构化的小规模流程进行质量保证。有产生很少的趋势，使用经典开发方法构建的全面且经过测试的发行版。但是，在竞争激烈的市场中保持竞争力所需的敏捷性受到了影响。

因此，规避风险和承担风险的方法均不适用于所有公司。因此，开发和工程团队必须全面建立结构化的部署流程，并优化发布流程。

测试范围

关于此优化，重点主要放在测试范围上。在这里，有必要权衡利弊：必须满足哪些先决条件才能确保产品或服务尽可能无差错？当然，特别重要的软件功能必须继续平稳运行，并且不得受到更新的负面影响。同时，必须根据时间和金钱来评估测试所需的资源。例如，单元测试通常仅单独检查几行代码，例如正确执行文本输入规范。在此之上的一个级别，集成测试用于测试网络中的多个组件。这些对于使副作用风险最小化很重要。而且在系统级别的测试甚至更加复杂且耗时。

但是，除了这些标准测试之外，包括其他测试类型也可能有用。例如，探索性测试，其中的功能不是在脚本之后进行测试，而是由试图“破坏”体验的测试人员进行。

通常建议在过程的早期进行尽可能广泛的测试。这减少了单个测试的运行时间，并且可以增加频率。但是，为了不仅从开发人员的角度进行测试，而且从不同的角度进行测试，也应使用代表实际用户的测试人员进行探索性测试。

构建部署流程的技巧

自动化和手动测试的混合使产品经理更难确定合适的发布时间。构建流程可以帮助节省时间和金钱。以下措施支持这一点：

质量门流程（QGP）：将项目分为多个阶段，并在每个阶段的末尾设置质量门。与里程碑相反，这些质量门始终设置统一，以确保在整个项目中始终保持相同的正式质量保证流程。要检查的方面记录在明确定义的检查表中，以确保一致性。根据评估结果，决定如何进一步进行：“执行” –过渡到下一阶段；“保持” –在阶段中需要改进，因为并非所有方面都得到满足；和“停止” –必须澄清是否必须中止该项目，或者是否有可能进行大量改进以维持该项目。

非自动化测试的时间限制：探索性测试至关重要，因为如果该错误是由客户在发布后发现的，那就太迟了。但是，为了使此类测试的范围保持在限制范围内，公司可以使用项目管理方法。例如，时间框定义了可以进行这种探索性测试的时间范围。目标是在给定的时间内进行尽可能多的测试，然后严格完成测试-无论您走了多远。如果明显的方面仍未解决，则必须将其移至下一阶段的时间框。

错误分类：无论您准备的多么充分，在一定程度上都是不可避免的错误。因此，应该定义一个可以进行错误评估的过程。“分类”（Triage）就是确定最重要的错误，然后立即修复它们-即作为修补程序。紧急程度较低的错误应根据它们对整体体验的重要性来权衡。但是，团队应始终保持最小的积压，以免日后出现回归错误。

基于数据的决策支持

开发团队承受着巨大的压力，因为管理层和外部利益相关者通常会推动敏捷，快速的软件开发以实现高质量。为了使项目经理决定“继续”发布，可以使用诸如掌声质量评分（AQS）之类的质量评分。基于历史数据和当前指标，可以使软件质量可衡量。此类指标包括例如测试范围和覆盖范围，错误频率和错误严重性。统一评分还可以提供较少的主观决策帮助，并可以进行基准测试，从而帮助团队更轻松地做出通过/不通过的决策。