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

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

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

持续集成案例分析系列(1)——大规模项目团队持续集成历程

这篇文章是我在两年前写的,记录了一个150+人的软件团队(最多时近200人)如何在一个庞大的遗留系统上,通过逐步建立一个持续交付部署流水线,从而达到频繁发布的状态。最终在该团队的持续交付基础设施中,共有260台服务器用于构建、测试和部署(几乎全部是虚拟机)。而这个产品也可以每六周发布一次

Continue reading 持续集成案例分析系列(1)——大规模项目团队持续集成历程

持续交付成熟度模型更新,新版本v1.2发布

《持续交付》一书中提供的“持续交付成熟度模型”是1.0版本。

这是经过再次调整的改进版,更具有指导性和可操作性。

使用说明:

建议使用该模型进行现状分析,发现改进点,不建议将其作为绩效衡量的标准。

一、七个维度

它们分别是:

1. 持续集成(Continuous Integration)

2. 环境与部署(Environments and Deployments)

3. 可视化与可追踪性(Visibility and Traceability)

4. 测试(Testing)

5. 数据管理(Data Management)

6. 配置管理(Configuration Management)

7. 组织协调性(Organisational Alignment)

二、每个维度又分成五个级别,它们分别是:

一级:阻碍级(Regressive)

二级:可重复级(Repeatable)

三级:可定义级

四级:可定量级(Quantitatively managed)

五级:优化级(Optimizing)

其中,持续集成维度的五个级别分别是:

一级:阻碍级(Regressive)

1. 软件的构建过程是手工的。
2. 构建过程冗长,而且其中的主要步骤常常出错。

二级:可重复级(Repeatable)

1. 在开发人员的代码上进行定期的自动化构建和单元测试。
2. 利用自动化过程,能够从源控制中重新生成任意一个构建版本。
3. 开发人员的提交频率是不定的。

三级:已定义级

1. 每次提交都会触发构建和各类测试。
2. 公共工具集中的脚本或工件得到重用。

四级:可定量级(Quantitatively managed)

1. 构建数据度量项被收集,高度可视化,并执行相应的改进活动。
2. 构建失败不会没人管。所有团队成员至少每天提交一次。
3. 尽可能在最后时刻(即将发布时)才拉发布分支。

五级:优化级(Optimizing)

1. 随时可以从主干上拿到已全面集成且生产环境可部署的构建版本。
2. 关注点是:随着对代码质量信心不断提交,能够进行更加频繁的提交。

环境与部署的五个级别分别是:

一级:阻碍级(Regressive)

1. 手工准备环境,无适当方法管理环境冲突。
2. 手工部署软件。

二级:可重复级(Repeatable)

1. 环境已被定义,并可自动化地准备和控制。
2. 部署操作是手工和自动化相结合才能完成。

三级:可定义级

1. 开发和测试环境是全面自动化且自服务的。
2. 已具备 “点击按钮即可向任意环境进行部署”的能力。
3. 为了完成自己的工作,每个人都有相应权限访问并操作相应的环境。

四级:可定量级(Quantitatively managed)

1. 协调的部署管理。
2. 发布计划自动产生。
3. 对所有的失败进行根因分析。
4. 回滚流程被脚本化,并被管理起来。
5. 建立了环境和系统健康状态指示板(Dashboard),其上显示的数据被监控和报告。

五级:优化级(Optimizing)

1. 环境的准备是全自动化的。
2. 已具备根据需求快速重建完整环境和基础设施的能力。
3. 端到端的业务度量项被监控。

这里可以下载全部