从测试角度看DevOps

Posted 2021-04-16 DevOps与运维

DevOps这个词已经变得越来越流行，逐渐成为一种趋势。它将运维和开发的单词结合起来，一个人谈到“DevOps文化”也许是因为它更与人们和他们的工作方式有关，而不仅仅是技术，它是关于将两件历史上独立的事情结合在一起：开发和运维，并且在此过程中，它还设计到将更多的不同的东西组合在一起。

DevOps文化

DevOps文化建议在不同的层次上学习、交流以及反馈，这不仅仅是技术上的问题，更不是一种职业工种，若某个人说他是一个DevOps，其实是不对的。

通常，这样的事情发生了：有一个想法、变更、需求等等，开发人员在编写代码，他们将一个被传递给运维的包放在一起，将其投入到生产中，然后再传递给用户，在此之后，负责管理的是运维人员，其负责所有生产方面的事情，在开发和运维之间有种典型的利益冲突，通常会有一些阻碍和延迟：

• 开发人员希望尽快地给用户提供产品（在敏捷方法中，更有可能的目标是将变更投入到生产中，通常是一周一次）。

  
  

• 运维不希望在生产中添加可能会导致问题的东西，然后回退恢复备份，因为最后的更改破坏了数据库或让系统崩溃。

这表明开发和运维之间存在着巨大的摩擦，将会影响业务，DevOps的文化，不仅是处理技术部件，而且与人工组件和流程有很大的联系，为了克服可能发生的摩擦，沟通是最基本的方法，同时叫也是必不可少的一部分，职责黄粉和共享的方式意味着敏捷方法不仅涉及到开发人员，而且涉及到运维团队。

这里有一项研究可以表明：

使用DevOps的团队频率要增加30倍，失败的次数要少60倍，速度快160倍。

下面这篇文章展示了开发过程的所有阶段，包括持续的反馈和集成，所有的都被实时的交流所包围。

从测试角度看DevOps

根据三组不同的数据可以发现，测试人员和开发应用的其他人之间的关系从瀑布式到敏捷开发到DevOps的整个过程都发生了变化。

在瀑布式开发中，测试人员与不同的较色进行交互，但是由于测试人员是独立的，与其他人员产生了隔阂。

在敏捷卡法中，只有一个更横向的组织结构团队，所有人的职责都对质量负责，而无需区分所有不同的角色。

但在这里，正如在敏捷中所看到的，当“包”被传递到运维，然后被释放到生产中时，开发的任务就结束了，在团队的看板中，可以看到Done的概念意味着代码已经准备好，但它仍然不是在客户端，敏捷总是称赞“团队”，但它并不包括运维团队成员和测试团队成员。

这些很明显的，DevOps强调在合适的时间，在不同的团队之间进行正确的对话，以达到最大的效果。

推荐阅读：

---

— DevOps与运维 —

分享业内

DevOps与运维知识、最佳实践