10大准则令完美的开发/测试实验室成为可能

        英文原文：The Perfect Dev/Test Lab: 10 Principles that make it Possible

        你是否拥有一些实现超敏捷软件开发所必备的特质？创业公司 Ravello Systems 探讨了通过将云规范化，来构建梦寐以求的开发/测试实验室的关键准则。

        在这样一个竞争优势与业务敏捷度近乎画上等号的世界中，现实情况是，企业往往需要非常多的时间投入，来开发和测试驱动业务的种种软件。

        在软件开发中，超敏捷要求基础设施和自动化不仅与开发进程保持一致，而且还要对加速循环和改进整体质量产生实质性帮助。在开发/测试工作负荷具 有猝发性和短暂性本质的大前提下，要想打造一套理想的完全部署在本地的实验室，可以说在经济上是不可行的。然而现在借助将云规范化的新技术，对大多数企业 来说，与超敏捷开发和测试之间的距离正在被不断缩短。

        这里给出的 10 项准则，它们将有助于推动开发/测试实验室涅槃重生。尽管时至今日，依旧几乎不可能实现在打造这个“梦寐以求的实验室”的同时又不至于投入许多花费，然而 借助各种最新的技术，很容易构建这个理想的实验室：它不止能够提升软件质量、加快投放市场的步伐，还能够减少整体成本。

        1. 敏捷开发/测试具有猝发模式的特点，并且实际上要求无限的基础设施资源池

        典型的软件开发和测试现在都得到了自动化处理，但是由于资源方面的制约因素，并不是所有的测试都能够并行进行。对任何企业来说，让开发/QA 团队等待测试结果，需要付出极其高昂的代价——这不仅仅是一种低效行为，还会使得企业在业务竞争中输给更加敏捷的对手。在理想场景下，开发者应该无须等 待，就能够访问资源池，而且该资源池在他的角度看来是无穷无尽的——不论是公有、私有还是混合云，因此任意数量的测试都可以立即且并行地进行。

        2. 开发者应该享有基础设施的自服务渠道

        要想完全利用潜在的近乎无穷尽的资源，工程师需要能够：通过预先定义的许可，以按需、自服务的方式访问资源池，而不是等待 IT 为每个请求逐一配置资源并授权访问。

        3. 使用产品复制品进行测试的能力

        从 Ravello 针对开发/测试工程师、IT 管理员、自动化工程师和 DevOps 进行的调查来 看，多达 75% 的架构师和 IT 管理员都意识到了：创建开发/测试环境过于复杂且耗时，而且这些环境并不能代表产品。尽管每个人都能够认识到对速度的要求，但同时我们也不要忘记，软件质 量是另一个同等重要的方面。特别是在非常灵动地环境中，要想确保最终结果始终具有高质量，测试产品的复制品固然颇具挑战，但却是至关重要的事情。例如，如 果我们拥有一个本地 VMware 环境，并且想要在亚马逊 AWS 云服务上测试这些应用，那么两种类型的环境之间应该是完全无缝的。

        4. 基础设施应该在应用层面进行自动化

        基于单独的快照和副本，手动复制复杂的多虚拟机应用，是一件繁琐且容易出错的工作，而且当涉及到复杂的网络配置时更是如此。在理想情境中，应该能够通过简单的一次点击，就完整复制多虚拟机应用及其网络。

        5. 持续集成——从应用到基础设施

        通过持续集成，开发者在提交代码时，应该能够拥有应用的多个实例（产品复制品），并且在同一时间里运行一系列完整的集成测试。开发者需要即刻获 得反馈，以了解测试的功能在类生产环境（production like environment）中工作良好，或是出现了问题并需要修订。作为支持持续集成的绝佳工具，Jenkins 得到了广泛运用。然而要想成功使用，需要将它与底层基础设施设置紧密地整合，以用于无缝的端到端自动化——从代码到硬件。

        6. 身处各地的开发和测试团队能够便捷地协作

        设想一下，一位 QA 找出了某个 Bug，他不需要打断或推迟其他正在进行的测试工作，就能够邀请开发者检查或调试相同的应用实例——不论二者身在何方。这种快速访问和分享将加速开发/测试循环，并提高团队协作。

        7. 重现 Bug 的能力

        在复杂的多虚拟机应用中，跨应用元素的依赖和交互，使得重现 Bug 是一件非常困难的事情。在理想的配置中，整个复杂应用可用被打包成一套环境，从而能够简单地重现 Bug，例如识别出某个 Bug 时，就可以执行测试系统的一份复制品。

        8. 快速制作原型

        使用标准的预定义积木式部件（例如，标准的数据库集群）来快速制作应用原型，将显著加快开发/测试循环的速度。然而，理想中的积木式部件，应该不仅仅是使用标准应用组件的全新或现成的实例，而是对实际应用中存在的相同元素进行复制，从而更加贴近生产环境。

        9. 监控资源使用的能力

        考虑到开发/测试实验室在本质上来说非常不稳定——虚拟机被频繁的创建和销毁——因此，要想确保资源有效利用和未使用生产能力的恢复，监控开发/测试资源使用情况的能力至关重要

        10. 成本效益

        最后，但显然很重要的一点是，提供所有这些能力，都应该以业务能够承受的成本为前提条件。在之前提到的这份调查中，80% 的开发团队遇到了开发/测试基础设施短缺的问题，而 92% 的开发团队则拥有购买更多硬件设备以用于开发/测试项目的需求——然而增大采购并不总是一个划算的方法。特别是对于突发性的工作负荷——例如开发/测试 ——几乎不可能针对峰值容量预先设计好数据中心，因为那意味着在大部分时间里，让昂贵的基础设施资源闲置。在完美的实验室中，应该能够很容易地管理开发/ 测试实例，我们只要在用到的时候“打开”实例即可，而不是让所有实例保持7*24 运行——只需要为了消耗的资源按使用付费。

        11. 额外要点：极限测试

        实验室还应该具有这样的能力：通过简单 API 调用，来检查网络失败情景或是测试高可用性环境。这在概念上与 Chaos Monkey 有点类似，但是却有着更广泛的功能，并使得执行检查失败情景的复杂测试时，不再需要手动拉线或是停止 Tomcat。

        软件正在“蚕食”这个世界，但是企业中开发和测试基础设施的状态，却阻碍了企业开发者们真正拥抱敏捷的进程。DevOps 的兴起正是面对该差距的一种尝试。上面介绍的这些准则，在弥合开发者和基础设施管理员之间的鸿沟，以及为企业创建梦想中的实验室方面，还有很长的路要走。

        关于作者

        Rami Tamir在管理多类型软件开发方面，拥 有长达十五年的经验， 2011 年，Tamir 与他人一起创建了 Ravello Systems 并担任 CEO 的职位。在创办 Ravello Systems 前，Red Hat 收购 Qumranet（开发了 KVM 管理程序的公司，现在该技术已成为 Linux 中的标准虚拟化技术）时，Tamir 作为 Qumranet 的联合创始人和总裁出任了 Red Hat 的工程副总裁。再早些时候，Tamir 与他人创办了 Pentacom 并执掌软件部分，并随着被 Cisco 收购就任后者提供的高级秘钥管理职位。