LinkedIn:移动APP开发中的自动化测试与持续部署流水线

最近,有很多人问我关于“移动应用开发中的自动化测试如何做?持续集成和部署流水线从哪里开始?”的问题,觉得有必要写一写。恰好这个周末在家无意间看到Linkedin的做法,觉得非常有意思,尤其是截屏做对比测试的做法,在移动应用中比较少见, 在这里与大家分享。原文地址在这里

Continue reading LinkedIn:移动APP开发中的自动化测试与持续部署流水线

选择持续集成工具需要考虑的几个因素

目前,持续集成工具多达30种,每种工具都有自己的特点。在国内,软件企业很少为这类产品付费,所以国个目前最流行的包括Hudson(开源),CruiseControl(开源),TeamCity(商业版,买了IntellJ的License就能免费使用)。而在国外,还有两个比较流行的商业软件是AnthillPro和Go(原名为Cruise)。

根据目前软件发展的特点,在选择持续集成工具时需要考虑如下几个方面(不包括金钱投入):

  1. 版本控制工具的支持。在你的企业中,使用哪种版本控制工具(Git, Hg,SVN,ClearCase等等)。
  2. 每个构建是否可以支持指定多个代码源URLs。
  3. 是否支持构建产物管理库。
  4. 是否支持部署流水线,类似于一个或多个构建完成后触发另一个构建。
  5. 是否支持并行构建。
  6. 是否支持构建网格,以及对网格内机器管理的能力。即,能否将多个构建同时分配到多个构建机器上执行,以提高执行速度。
  7. 是否有良好的开放API,比如触发构建API、结果查询API、标准的Report接口等等。
  8. 对于安全性来说,是否支持企业所用的安全机制,如LDAP等等。
  9. 是否有良好的Dashboard。
  10. 与构建工具(如Maven,Make,Rake,Nant等)和测试工具的集成。

另外,“有良好的开放API”是任何工具选择的重要标准。因为,自动化是持续集成的关键。如果一个工具只能通过一个Web界面来操作的话,那简直就是一个噩梦。

详细的工具及特性列表见这里

 

配置与发布管理成熟度模型1.0版

在过去多年的持续集成咨询经历中,最常听到的一个问题是:如何来评估企业在配置与发布管理方面做得到底怎么样?还需要在哪些地方进行改进或提高?

两年前,CITCON的几个参与者给出了一个持续集成成熟度模型,聚焦于“持续集成实践”,而在《持续交付》一书中,Jez与Farley也结合ThoughtWorks在这方面的实践经验,总结了“配置与发布管理成熟度模型”,并在多个项目中进行了实际应用,效果不错。

由于这是通用模型,所以各等级中多为定性描述,在拿到具体企业使用时,可以根据实际情况,对其中一些定性描述进行量化,比如“提交不频繁”“定期沟通”等。

如何使用这个成熟度模型呢?

  1. 找出你所在团队在各维度上所处的级别。
  2. 找出你所在团队需要改进的维度,以及在该维度上的改进目标。
  3. 根据目标与现状,制定改进行动计划并实施。
  4. 重新评估,再制定下一个目标。

任何流程都是可以改进的,所以没有最好,只有更好。所以最高一级是“持续优化”。

模型内容可从以下地址下载:

http://download.csdn.net/source/3454593