一十一
发表于 2018-03-14 15:50:03
摘要：
DevOps团队的职责是“无摩擦发展”。 这是对“速度需求”驱动的发展理念的一种渴望，以及有意识地去除从概念到客户的想法。 无摩擦的发展使产品团队能够专注于创新，而不是陷入经常任意的过程。 这种运动为质量保证工程师提出了一个有趣的问题，因为“对速度的需求”的思路让他们以更少的时间（主要是时间）做更多的事情，同步对话的双方面临的挑战往往是棘手的。
着眼于提高交付速度往往会使质量问题成为焦点。 怎么确保'速度需求'不仅仅是'快速'，而是效率？调整DevOps和TestOps团队是一种技术，可以加速产品发布并支持强大且可靠的以质量为核心的产品，这两个领域通常包含对方。
任何敏捷团队都会经常发布产品更新（在某些情况下会比每天更新）， DevOps团队通常是这一过程的焦点，为构建和部署环境创建工具，使团队能够按照自己的期望尽快完成工作。但在测试过程中，由于作为 质量保证。 这个过程产生了QA和测试速度是项目交付瓶颈的印象。这时候便有了一个新的概念'TestOps'，构建一个无缝部署的测试环境。
TestOps团队本质上集中于从功能测试到集成测试到更低级别的单元和API测试的所有级别测试所需的基础架构和平台的可用性。 这与传统的测试工程师角色有所不同，后者经常可以成为编写测试工具和维护测试框架的负责人。这有助于将质量责任（通过测试覆盖率和流程）转移到整个团队中（而不是传统的'测试'）。 如果与DevOps的“无摩擦发展”理念正确结合，可以实现非常强大的优化开发，测试和发布过程。
在DevOps团队专注于构建，配置和部署的过程中，TestOps团队可以与构建和配置阶段进行交互，以与该系统进行通信，提供测试反馈机制，这些机制在产品团队自己拥有的测试规范中定义。 这提供了一个无缝的，标准化的工作流程，可以减少开发过程中的瓶颈。 通过持续集成扩展了这种灵活性，可以避免几小时的人工干预，以设置测试环境，从而减少在客户面前获取高质量，经过测试的代码所需的时间。 这只有在DevOps和TestOps平台同步时才能成功，两个团队在产品和流程上紧密合作。
案例分析：
2010年初，Workiva拥有一支由30名开发工程师组成的团队和一支由5人组成的QA团队，他们都致力于Wdesk，这是一个基于云的应用程序，旨在帮助公司在美国证券交易委员会创建和存档账户，预发行文件和其他文件。
预发布验收是在手动探索的基础上完成的，只需手动测试即可覆盖应用程序的能力成为一个问题，从手动测试场景到自动化测试流程的毕业生成为一小组QA工程师的项目。
这个新团队的初始目标是自动测试覆盖率，以便QA团队在每次发布之前完成的800个手动测试场景（此时，Workiva的每周发布时间安排为每两周发布一次，每次发布最多2000次更新）。 这些测试方案主要包括从文档创建和编辑到格式转换的端到端测试，以确认文档内容和格式在转换为SEC为企业会计定义的格式时是正确的。
为了使测试人员能够轻松创建覆盖范围，我们创建了一个易于使用的拖放界面来创建使用业务语言驱动的测试装置构建的测试。 测试运行者和测试的这种分离意味着在获得我们产品的测试覆盖率时可能会发生快速进展，而无需测试人员编写代码或为测试完成产生大量的许可证成本。
在接下来的两年中，测试覆盖率从每个发布的800个测试中增加到最初的手动测试案例（项目的初始目标），达到7000个全堆栈测试。 这些测试现在每天24小时运行，发布候选版本全面运行，产品团队构建的定制组件以及小型小时烟雾测试版本。
随着时间的推移，支持基础架构也从对一个小型物理机器场的测试运行到40个Google App Engine服务器的虚拟化平台，400个亚马逊ec2机器复制用户，并且每月运行大约1,000,000个测试场景。 该框架在某个地方采用了“天网”这个名称。
图1 - 初始测试和发布过程
初始测试成功，未来扩展问题
提供测试覆盖率的最初目标已经得到满足，并且在发布之前已经发现了数百个错误（并继续存在），尽管这些工具很快变得明显，这些工具非常“专注于测试”。 尽管开发人员可以在将产品和功能放在一起的同时创建功能测试覆盖范围，但这样做的工具不在环境和存储库开发人员每天工作的范围之内。 随着组织机构迅速转向多个产品团队和服务模型，这些团队和服务将通过由DevOps倡导的简化版本基础架构独立发布，因此这种扩展性无法扩展。 其他耗时的问题出现在所需的人工干预（如图1所示）之间，在开发和质量保证后构建之间进行人工切换，发布管理也一样，发布质量保证结果审查，并且这些需要在未来进行缓解。
随着组织分拆成各自独立的团队，每个团队都在独立代码库之外提供自己的微服务，重要的是要重新评估整个产品团队的这个模型，以及新的DevOps交付模型。
TestOps团队
由于DevOps团队负责构建和部署架构，使工程组织能够按照其业务需求尽可能快地进行扩展，所以TestOps团队能够相应地进行交互并与DevOps一起发展非常重要。 如果测试基础架构不易维护且可用作灵活的构建和发布机制，则会导致软件发布的延迟，因为QA在检查其规定的测试活动的发布可信度方面得到备份。 随着敏捷团队更频繁地向客户发布较小版本，这种凝聚力变得更加重要。 反过来，许多基于云计算的供应商都可以为客户提供服务，即使能够以更高的频率更新应用程序，也必须保持质量。
DevOps团队将构建并支持新的架构和工作流程，使产品团队能够按照他们自己选择的时间和频率发布软件。 构建支持基于容器的应用程序部署（使用Docker）并创建支持产品团队最适合其产品/服务的所有技术的生态系统。
除了DevOps之外，测试工程团队（在被称为TestOps之前）已经是测试框架的所有者，并且该团队已经开始意识到目前正在使用的测试模型无法扩展，当然在组织中是 移动速度更快，并希望比以前更快地构建部署。
确保DevOps和TestOps团队与工具同步是一项挑战。所有这些都必须接近无缝，因为任何人工干预或延迟开发都会存在不可预期的后果，并成为流程中的瓶颈或薄弱环节。 因此，团队之间的依赖关系的沟通是在一开始就建立起来的，每个团队的架构师都要确保两个团队的愿景，同时集中在不同的领域导致看起来是相同的结果。
发布管理团队是另一个有趣的组成部分。 负责管理客户的每一次更新版本的每一部分，在新模型中，团队有权在任何时候自行发布，随时准备这样做。
发布管理重点转向自动化发布工具，来帮助更快地发布产品。提供一套工具，如测试覆盖率报告和自动发布过程检查等，并简化团队发布流程以使其更快地交付。
质量保证人员也应改变传统观点，将其从源码交付、版本构建到产品质量的整个交付过程作为质控的一部分。
至关重要的是，成熟的测试工程团队需要转向更加'TestOps'的前景，以确保我们能够提供工具和支持，以确保在质量方面维持高标准并保持规模，并且团队 现在对其整个发布流程负责，但与DevOps和整个工程所倡导的“无摩擦发展”路径保持同步。
持续集成（CI）系统是DevOps/TestOps成功的中坚力量。 一个好的CI系统可以快速反馈构建稳定性，更快地将工件制作成QA，并最终更快地生成代码。 通常，DevOps将拥有构建系统，部署工具（假设基于云/服务器的产品），生产监控系统（有时称为CloudOps），并经常发布一致性度量工具，如代码覆盖率报告。 TestOps还可以利用所有这些工具，部署测试版本，报告性能和一致性等，为产品团队提供与生产部署完全相同的基础架构的反馈，从而减少时间和成本，以便为部署设置和维护单独的测试资源 并给出更真实的世界反馈循环以释放信心。
 |
TestOps中文社区公众号 |
| 微信 : wonter | |
| QQ群 : 632418478 |