计划‘三步走’通往持续交付

日前结合公司的实际情况，与测试、开发团队的同事讨论出以下‘三步走’的计划来实现持续交付：

 

第一步、实现持续构建，在CI服务器上进行几步简单的配置（选择源代码库路径、设定构建命令和构建频率、输入相关邮件列表）即可实现自动构建：当有代码check-in 到SVN/Git 时就触发一次编译，如果编译出错的话进行邮件和IM通知开发团队。同时对于服务器端的Java代码加入了静态代码检查功能(使用Check Style工具），对前端的flash代码页加入了使用PMD工具进行代码静态检查，当出现新的严重警告时理解让构建失败并邮件、IM通知开发团队。目前这一步骤在部门的所有新项目中开始执行。

 

第二步、实现自动测试，显然软件的发布不能仅仅建立在“编译通过”的条件上，还需要有相应的自动化测试来检查程序是否实现了预定的需求。目前这一步骤已经在一个项目中开始执行，其详细步骤是：

• 开发和测试同事一起讨论确定哪些代码需要写单元测试（如后台的购买流程），由开发负责UT编写但是测试同事需要review UT的覆盖程度和逻辑结构；
• 测试同事负责编写接口测试用例；
• 测试同事负责写UI回归测试用例；（目前暂时没有考虑些性能测试用例，因为网站的访问量比较低并公司的负载均衡做得不错）

 

第三步、实现零停机发布或自动发布，目前网站的更新发布仍然是需要停服一段时间，通过一个自动脚本把相关的修改更新到服务器上，随着业务量的增加和后续发布的频繁度增加，希望后续做到零停机发布/自动发布（一旦通过前面的自动化测试即可达到上线的要求）。持续的提高系统可用性以满足业务部门需求。

 

由于以上步骤、方法只是在笔者所处的环境中讨论出来的，目前只是刚刚起步，还没有数据来证明这些步骤是否100%的正确可行，希望一两个月后收集到一定数据后再继续优化这些方法。