你是否拥有一些实现超敏捷软件开发所必备的特质？创业公司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的兴起正是面对该差距的一种尝试。上面介绍的这些准则，在弥合开发者和基础设施管理员之间的鸿沟，以及为企业创建梦想中的实验室方面，还有很长的路要走。