持续集成与配置管理

（一）持续集成  

     持续集成的基础是版本控制、自动构建、自动测试、团队共识。“持续交付”一般把自动测试放到自动构建中，就是和Jenkins这种持续集成工具联系在一起，一旦版本变化触发自动构建，则自动运行代码分析、编译、自动化的单元测试和自动测试集、运行通过的会正式提交到版本库并部署、发布，否则回退。

        这当然只是一个理想型的过程，实际的软件研发过程中，对于敏捷团队要做的持续集成，必须保证频繁提交（以前觉得每日构建已经非常NB了）、全面的自动化测试套件、较短的构建和测试过程、对依赖的开发环境和第三方库文件和组件进行管理。从目前电商领域等互联网应用中，对持续交付的要求来看，持续集成已经是个必选项了。实际操作过程中，对于持续集成的基本要求就是：团队成员必须按照一定的规则办事，这些规则包括：

1. 提交前必须在本地运行所有的提交测试（或者在持续集成服务器有对应完成该项工作的分区） ： 建议在主干上，首先同步最新的版本，在此基础上来做本地测试，这要求有简明的集成到开发环境里的本地自动化单元测试环境。
2.  构建失败之后不要提交新代码，一般都要求构建失败立即解决问题
3. 必须要测试通过，当然，这就要求有自动化测试支撑，现在一般都会在本地运行静态代码分析和单元测试，到服务器去做冒烟测试和自动化基本业务测试 
4. 离开公司前，构建必须处于成功状态，不行的话，应该回滚到上一个成功状态
5. 时刻准备着回滚到上一个成功状态
6. 回滚前要规定一个最长的修复时间：不可能大家都在无休止地等待你解决问题
7. 谁提交，谁负责（保证构建成功）
8. 不允许将失败的测试注释掉
9. 为每个功能开发对应的覆盖测试用例：不然，无法检测到由于其他提交导致该项功能出错

     所以持续集成的基础可以进一步具体化：

•   版本控制（尽量维持一条主干，在主干上工作）
•   （依赖环境和库文件）配置管理（特指对第三方和环境的管理）
•   本地IDE集成的自动化代码检测（如Lint）和自动化单元测试（如JUnit）
•   自动构建环境支持（如Jenkins）
•   自动化测试（带覆盖完整的基本业务测试用例集）
•   当然，最重要的是团队共识（遵守以上原则来工作）
•   良好的基础设施（IDE、网络、机房、检测工具等，配得起良好团队的，一般不是问题，相比团队现在这些太便宜了）

（二）配置管理

     现在有很多版本控制工具支持配置管理，但管理活动不只是一个简单的系统。

    1、管理对象有哪些？  

• 大家都知道，需要的：   源代码、构建脚本、需求文档、设计文档（包括邮件、图片、讨论形成txt文件之类、接口共识）
• 软件转起来，其实很重要的东西：    测试脚本、测试文档、配置文件、数据文件等
• 第三方开发和测试环境：   开发、测试、运维用到的软件、工具，系统环境，第三方依赖库文件（库文件的变动带来的问题是贼多的）
• 过程记录，一般应该都信息化系统里面保留，不用特意做成文件放到固定地方了： 会议记录、问题解决记录、管理记录等
• 重要的外部交互文件（一般都是成文的）：合同、需求规格、提交件（给外部的PPT、公告、说明书、汇报材料）、会议纪要、邮件等等
• 正式发布的版本（一般配置库保留源代码和构建文件，二进制的以基线或光盘等形式单独保存）

   2、权限控制和提交控制

       知识产权保护，避免一个人撬走所有知识产品。

       提交的管理要求可参见上面持续集成。务必规定并且培训。例如：主干与分支处理；提交注释要求；时间间隔要求。

   3、选择合适的工具和管理人员。  

        选择分布式还是集中式VCS。

        根据团队规模和形式，确定是兼职或专职的配置管理员来控制或审计提交过程。