持续交付学习札记——第三章持续集成

引言——为什么我们要做持续集成呢？这是为什么呢，为什么呢？因为这样做是有好处的！什么好处呢？自己找去，不过最重要的一点，增加工作量啦~~~~~~

 

实现持续集成

 

准备工作

版本控制——就是第二章的那些废话，把该加入到版本控制的东西都加入到版本控制中去吧！代码（rd & qa的）配置信息 组件 环境 and so on，一句说，只要不是构建中自动生成的东西都要加入版本控制，要做好这件事也要花大力气了呢~~~~~

 

自动化构建——在eclipse里按build，如果能build出应用来的话也算是自动化构建了，当然大牛说最好是能构在命令行里自动化构建，好处显而易见。成熟的团队这点要求不过分呢

 

团队共识——看看前段时间那位可怜的同事天天加班到那么晚，工作还推不下去，团队共识真心的重要，真心的难做啊！尤其是在一个qa的推动力明显不足，而rd又不求改变的团队里面！残念！……在一个有共识的团队里是一件多么幸福的事啊！

 

一个基本的持续集成系统——我们可以不要持续集成软件就能做持续集成，因为持续集成是一种实践，而不是一种工具；但是呢，妈的！有工具为什么我们不用呢，就好比有电视电脑我们为什么要去电影院呢！

有了工具，搭好平台，跑了自动构建那也还不算持续集成呢，因为持续集成是一种实践，而不是一种工具。那怎么算持续集成了呢，看完这章也许就算了，当然还要按书上说的去做！

书上说第一次在工具上执行构建是很重要的，是很好的学习机会，小黄书上说是独一无二的学习机会，显然嘛第一次总是很重要的！即然第一次这么重要，我们当然要认真，那么第一次应该做点什么呢？两件事，不是我说的，是书上说的，小黄书！

1） 把第一次你所做的一切都记录下来，并将其放入自己项目的知识共享库里！（为什么呢？我也不知道，H书是这样写的，我没主持过持续集成的工作，所以也不是很清楚为什么这样做，不过看上去没什么问题啦！当然我个人觉得既然加入了知识共享库里，就应该常看看，偶尔修改一下）

2） 将项目构建所依赖的所有软件和配置提交到版本控制系统里，然后把重建全新环境的整个活动自动化！换句话说，如果有一天我们的hudson平台的肉身挂了，我们能点一下鼠标，喝一杯咖啡然后原地复活……多么美妙的一件事啊，任何美丽的事物背后都有一个艰辛的积累过程。

 

那么有了第一次就会有第二次，而且第二次就不是一个人了（不要想偏噢！）。大家都要来使用持续集成的服务器，那么就应该遵守一些简单的&不简单的公约：

1） 查看是否有构建运行

2)  如果有构建运行，成功结束后更新自己本地代码，然后本地构建和测试，然后提交；如果没有构建那就直接提交自己的代码吧

3）喝杯咖啡，等自己的构建结果

4）如果构建失败，fix it & resubmit it；

过程没什么好说的，努力让大家养成习惯吧！另补两点：1. 本地构建和测试是可以让hudson来完成的，怎么做，想办法做！ 2. 构建的触发：rd和qa提交代码要触发，配置更改要触发，构建脚本更改要触发，资源变化也要触发，要自动触发噢，别和我说你的构建脚本还存放在hudson的肉身上，版本控制啊版本控制！

这部分就是持续集成这章学习的上部分了，学习一个简单的持续集成的流程，下部分是讲如何做好持续集成了。对比一下自己的项目，应该有好多连基本的流程都没有满足呢！不是针对某人，只是说我的感受哈！持续集成想要做好任重道远啊！