第二届中国持续交付大会参会报告

2014年5月25日下午,上海浦东软件园“汇智TEK”联合全球知名软件定制企业ThoughtWorks、上海TOP Geek技术社区共同举办了第二届中国持续交付大会。会议邀请到业界知名企业包括支付宝平台、盛付通在线支付平台及ThoughtWorks的专家展开探讨,共吸引到园区内外两百余名爱好者参会。

中国持续交付大会,汇聚国内持续交付领域的各路专家,旨在帮助软件企业在愈发激烈的竞争,以及客户对软件产品要求越来越高的环境下,从既有的持续集成理念迈向快速、高效、可靠的持续交付。

什么是持续交付?

持续交付是一种软件交付方法, 关注与持续将增量的修改交付给用户, 并为此持续改善交付的成本、时间和风险.

对于很多需要几个月时间才能发布新版本的公司来说, 在一天之内发布数次似乎是天方夜谭. 然而, 遵循《持续交付》一书中的原则与实践, 一些原来一年才能发布几次新版本的公司, 也已经能在一个月内发布数次, 或者更频繁了. 这是一种巨大的竞争优势, 而且意味着, 在时间和精力方面减少了大量的浪费.

为什么持续交付?

1. 它让你能更快地验证新业务方案的结果, 并根据真实的用户反馈进行调整. 尤其是当业务方案有根本性缺陷时, 你一定希望能尽早地发现, 而不是花数月或数年的时间和大量的金钱来实施计划后, 才知道存在问题.

2. 与项目结束后的一次性大版本发布相比, 它能提供一种大幅降低交付风险的交付流程, 而且成本的投入也更加具有可预见性.

3. 项目经理们能看到项目的真实进度, 因为, 此时的“完成”是指: 运行于真实生产环境中的可工作的软件已经为用户带来价值.

4. 通过规律性增量发布, 大大减少了每次发布的风险.

如何持续交付?

为了能够成功实现持续交付,需要依赖于两个基础,一是技术基础,二是组织基础。而这两个基础有三大支柱:

1. 全面的配置管理
2. 敏捷测试
3.部署流水线

现实中的持续交付

1. 某电商网站的持续交付

平均部署间隔时间(工作日): 11.6 秒
单个小时最大部署次数: 1, 079 次
一次部署平均服务器数量: 10, 000 台
一次部署最多服务器数量: 30, 000 台

2. 支付宝的持续交付——看大象如何跳舞

众所周知, 支付宝的软件相当庞大, 并且随时都面临着需求变更, 可能, 今天中国工商银行会通知支付宝调整支付上限, 因此支付宝必须快速应对如此的需求变更, 这就是支付宝采用持续交付的原因.

为了采用持续交付, 支付宝采用三种发布方式: 机动发布, 独立发布和日常大发布. 在此之前, 他们会对软件项目中的代码进行解耦——不具有耦合性的代码给独立出来, 以便进行机动发布, 对于耦合性较高的代码, 他们进行日常大发布(即每天发布一个新版本).

持续交付中一个很重要的基础便是开发和部署分离. 为此, 支付宝具有一个完善的部署体系和回滚体系——若新版本中存在缺陷, 则回滚至前一个版本.  为了完成这个工作, 支付宝使用SIT部署测试环境, SIT是一个支付宝内部使用的系统, 它可以通过简单的配置项(ARS, 标准配置管理)以配置测试环境(如使用的JDK版本等).

持续集成与持续交付是分不开的. 当代码提交至仓库时(支付宝使用Git管理前端代码, 使用SVN管理后端代码), 持续集成系统便开始工作. 支付宝有一个看板机制, 它们将持续集成的结果显示在看板上, 并约定持续集成中暴露的缺陷必须当天解决.

此外, 支付宝团队还开发了Eclipse插件, 以进行代码评审. 当代码存在缺陷时, 评审者可以使用该插件将代码缺陷上传至服务器, 服务器会提醒开发者代码中的缺陷.

随着敏捷开发, 持续集成的流行, 传统的软件企业面临着企业转型的挑战. 在Cisco Webex, 据说从新版本开发完成, 到版本最终上线, 这其中(使用自动化部署)需要1个月的时间. 我们把这1个月称之为尾巴时间(Tail Time), 持续交付就是尽量将尾巴时间缩减至0. 但在对软件质量要求较高的企业或是软件规模较庞大的传统企业, 应该更好的转型进行持续交付, 这又是一个值得研究和实践的问题.

anyShare分享到:
This entry was posted in 新闻动态 and tagged , , . Bookmark the permalink.

发表评论