IMVU如何在实施持续部署的同时确保软件质量

本文是IMVU(一个社交网络公司)在32个月之前发表在他们的技术博客上。你可能会羡慕这种发布状态(每次代码修改在20分钟内就可以部署到生产线,而每天部署50次),以及他们如此强大的工具和基础设施。然而,你看到的只是结果,而背后却是他们坚持的理念——“持续交付、持续学习”的精益创业开发理念;以及在这一理念支持下,大量艰苦的工作。那么,这些工作都包括哪些内容呢?详情如下。

---------------------------------------

我们公司有时也会由于某个特性抢速度上线而对顾客造成一些负面影响,但是这些负面影响也是我们得到教训的一个来源。有时,我们做的特性对于顾客没有什么价值,有时也会在生产环境中引入一些回归问题或是新的缺陷。

然而,有的时候,对于我们小心翼翼做出来的一些特性,客户也并不买账——可这的确消耗了我们很多精力,因为我们要花了更多的时间来研究、学习和调整方向。举一个例子吧:我们曾用 一个月的时间开发完了一个叫做“更新”的特性——有点像Facebook的“Friend feed”(朋友新鲜事),而用户对这个特性的反应和我们预想的完全不同。这表明,我们花了很长时间却交付了一个没人要的功能,而导致的结果就是:这延迟了另一个更加重要的特性(群组特性)的交付。

问问用户他们想要什么,节省了内部产品开发讨论的时间,这让很多问题变得更容易解决,“我们应该做一些工具让用户把阿凡达装备分类,还是直接做一个搜索 工具,还是两个都做?”我们会在已有客户数据、竞争分析以及综合经验的基础上做一个尽量好的决定——然后尽快地做出一个功能,用客户来验证我们是否正确。

你是不是觉得:我们并不担心如何给客户提供高质量的特性,或是他们的用户体验会受到影响?我们担心得不得了。

首先,我们很重视自动测试。这种对于测试和其框架的重视是我们如何组织QA团队和其使用方法的核心。我们的前CTO,也是IMVU的联合创始人Eric Ries曾经详细地描述过我们用来支持持续部署的基础设施,这里概括一下:

  • 每一行提交代码都用一个持续集成服务器(Buildbot)运行监控自动测试
  • 为了确保出问题的时候不让新代码加入代码库需要运行一个源控制提交检查
  • 为了保障万无一失,我们编写了一个集群免疫系统来监测和对严重的回归问题发出警告,当发生错误时,自动回滚到上一个好的版本。
  • 如果错误不小心加入到了部署过程中,实时监控和警报会在第一时间通知团队
  • 根因分析(五个为什么)可以驱动部署和产品开发流程中的不断改善

想看全文,请点击这里,译文来自 @图灵社区。

Published by

乔梁

乔梁,百度项目管理部高级架构师

One thought on “IMVU如何在实施持续部署的同时确保软件质量”

Leave a Reply

Your email address will not be published. Required fields are marked *