从测试视角看DevOps：4大特性哪种最重要？

摘自PM圈子网—项目经理牛人聚集地

测试是DevOps转换的核心，如果DevOps是关于团队文化之间的差距，那么测试就是一个分界点，这是Dev和Ops团队的共同特征。

随着新技术和特性进入到应用程序的体系结构，在应用堆栈的各个级别都需要进行变革，比如代码重构、确保功能向后兼容、重新访问过去的核心设计决策，以及更改服务和数据模型。

DevOps是关于文化的，它需要一个健壮的测试实践和文化的改变，下面，我们就来看看可以追求的文化改变，以便更好地进行测试实践。

平衡速度和质量

每个DevOps转换的承购是以实现当前设置的工作方式开始，发布是高压力的事件，充满不可预测的失败，结果是创新慢下来，一旦你决定要解决问题的根源，DevOps就变成了一个明确的解决方案，更快的发布是组织采用DevOps的关键原因。

然而，通过关注开发管道，需要考虑整个产品生命周期的每一步，以实现更快的发布——只有这样才能有质量和可靠性，当在应用程序中限制新特性的数量和特性的复杂性时，这些特定需要在真实环境下持续使用，在如今支离破碎的移动生态系统中，实现这一目标更加困难。

致力于自动化

自动化是实现跨管道速度的关键，每个团队开发人员，测试和Ops都需要致力于尽可能地自动化，这意味着每个人的实际情况会有所不同，但这一承诺对于真正的工作来说是必要的，对于Dev来说，使用Jenkins构建自动化是自动化的第一步，同样，对于测试来说，自动化单元测试也是起点，对于Ops来说，能够根据模板创建和配置不同的环境是它开始的地方，自动化减少了手工错误，并将质量引入到流程的每一步中。

从触发-响应模型的角度考虑自动化是很重要的，在SDLC中，可以使用各种事件作为触发器来启动一个或多个响应，比如，每当开发人员提交代码时，该事件就充当Jenkins的触发器，以自动编译和构建代码，作为下一步，Jenkins可以集成测试工具来发起自动化单元测试，此外，在真实设备上的功能测试可以使用设备云实现自动化。

这样，团队就可以毫不费力地得到流程的各个步骤的反馈，并且可以在更高价值的任务上花费更多的时间，但最重要的是，自动化带来了一种速度，如果人类手动执行相同的任务，是不可能的，想象一下，每周购买一台新的Android设备，或者在每次测试运行前手动配置每一个设备又或确保所有设备都运行最新版本的操作系统和支持应用程序，自动化或将这些管道任务卸载到供应商可以在任何规模上带来速度和质量。

自动化的另一个机会是使用模板来简化环境的创建，如果您使用AWS进行基础设施，这意味着使用如何CloudFormation这样的工具，可以基于以前的配置或自行创建的模板来创建生产就绪的环境，将生产环境模拟为测试的目的是一项挑战，但通过对流程进行模板化，它就变得可管理，并为您提供更可靠的测试结果。

利用监控告警

在微服务应用程序中事情会进展的很快，而且经常中断，如果在一个稳定的未过滤的流中查看警报的数量会变得势不可挡，解决方案是使用一个路由逻辑，确保每个人和团队看到与他们工作相关的告警，当它们被用作自动化的触发器时，警报变得更有价值，例如，对于一个失败的服务的告警可以被用来自动在Jira中创建，通知相关的团队让每个人进行相应的处理。

关注全局

当自动化整个SDLC时，优化流程的每个部分会带来更大的速度，但是要将这个过程变得更高，应该考虑全局，随着自动化的成熟，需要考虑如何做出影响整个管道的更改，如Spinnaker这样的工具，由Netflix创建，AWS代码管道可以让用户以视图的方式进行。

从整体上看，这条管道可以帮助致力于实现自动化的所有人员，这不仅仅抛出了一些新工具，更深入地考虑这些工具支持的过程，更深层的是，它着眼于团队如何一起工作，以及他们使用的工具和过程是否受到限制或授权。跨开发、测试和运维的自动化文化对于实现DevOps转换承诺的速度至关重要。

总结

“质量”在SDLC中构建的每一步骤都是非常重要的，它需要来自每个团队的努力，并要求实现对自动化的承诺，需要知道的是，当自动化是一件不仅要减少投入而且要加快速度、提高质量的时候，那么你就在正确的轨道上，当接受自动化的文化时，它必然会改变测试的工作，并导致高质量的应用程序被传送的更快。