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

日期: 2014-03-04 来源:TechTarget中国 英文

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

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

相关推荐