百人团队敏捷转型日记 第二集 持续集成要一步步来

首先简单介绍下背景： 

博主所在软件公司的某产品线一个百人开发团队，自2015年至今，从传统的瀑布开发模式， 
成功转型敏捷开发管理（SCRUM+XP要素）。有效提高了客户需求响应速度、 
开发团队工作效率，给公司带来了新的活力，变革过程中也对敏捷方法做了改进。 
博主有幸在其中担任一个开发小组组长和版本管理组成员，此处将博主在整个转型过程中， 
看到的一些弯路、以及成功经验分享给大家。 
文章会涉及到 组织扁平化、持续集成、自动测试、自动部署、SRUM框架、结对编程等敏捷要素。 
以及敏捷倡导的价值观： 
个体与交互重于过程和工具、可用的软件重于完备的文档、客户协作重于合同谈判、响应变化重于遵循计划。 
这是一场带着温度、历历在目的思想碰撞，欢迎大家来和博主交流。 
*

第二集  持续集成要一步步来

本集我们将通过问答的形式来阐述我们在转型过程中所遇到的问题，以及解决方法。任何方法论在都要根据具体情况做出适应性的改变。

问题1   什么是持续集成？ 

  持续集成（Continuous Integration）这个术语源自 XP（极限编程）的一个最佳实践，持续集成就是及早地将开发人员的代码集成起来，通过各种工具来及时地发现代码中存在的问题，以确保代码质量的稳定性和准确性。
  持续集成要完成以下几个方面 自动编译、自动构建、自动部署、自动测试。

问题2  十几个项目组，如何自动编译？ 

  我们整个产品线有大小十几个项目，虽然各个项目的代码均部署在统一的源码库(SVN)中，但是要想每次集成时都整体进行重新编译，光编译时间都得六七个小时。也许你说可以用并行编译来缩短时间，但这不是关键问题。关键的是一旦某一个至要模块编译出错，可能后面的安装就很难进行。
  因此，我们采取的方法时，对于整个产品线来说，不进行自动编译过程，每个项目组自己进行编译，提供通过模块测试的、可安装的模块组建包。由版本管理组对整个产品线的项目进行自动集成。
  注意：产品线提供统一的编译环境、安装测试环境。

问题3 项目组反映版本管理组制定规范太多？

  要想实现自动集成、自动部署，就要求项目组提供的组建包符合各种规范。比如包名、安装脚本、配置文件，输出日志等，而因为之前也没有较多经验，版本管理组也是尝试着前进，在此过程中，也听到了一些项目反映规范太多、经常变动的声音。
  因此回过头来看，可以给大家以下建议：
1 在初期，只指定可能影响功能的规范，对于可有可无的，可以稍微放开。
  举例：对于一些日志格式等对功能没有影响的，就没必要设置太死的规范。

2 所有的规范都要以书面的形式正式发布、且描述无歧义。在制定前要充分测试。
  举例：发布前可邀请 测试人员、新人事先阅读理解。

3 要让项目组理解每条规范的作用，以达成共识。
  举例：对于一些看似无用的规范，比如版本号命名。但是从整个产品统一获取版本的角度来讲是很重要的。所以规范中最好说明，让项目组得以重视。

问题4  串行的安装并行安装

  刚开始阶段，系统安装是串行的，我们强调的是尽可能的把所有的组建包都自动化安装，但是带来的后果是，一些组建包安装需要很长的时间，甚至在安装过程中会卡住，而影响整体安装。
  并行安装就自然的被提上来。但是组建包之间存在依赖关系，对于有先后依赖关系的，不可并行。并行安装时提示信息要方便安装人员查看定位。
  另：经验之谈，因为产品线的自动安装脚本前后经过很多人维护，而随着功能需求的不断增加，脚本的负责度也不断增大，后期维护就有些吃力。这个时候就有必要进行重构。

问题5  自动化测试

  对于敏捷来说，TDD是较关键的部分，但是对于在迭代周期很短、需求较多的情况下，TDD往往很难实施。
我们采取了折中的方法：
1 对于需求不多的模块，先推进TDD的实施积累经验，培养习惯。

2 优先构建系统级别的自动化测试用例，对时间紧任务重的模块，单元测试可暂缓。

问题 6 持续集成带来哪些好处？

1 减少风险
  有利于提前发现问题，将隐患消灭在项目的前期。
2 减少重复劳动
  减少了多次手动编译、安装的过程，每次测试能够自动回溯以前的功能，避免新的改动影响以前的功能。这对快速迭代的产品特别重要。
3 信息更透明、及时
  持续集成可以让我们可以清楚的知道每一次修改都产生了哪些影响，并且每次的集成结果都会及时的发给各个团队成员。

敏捷转型日记 微信交流群：