今天听了老徐讲了下持续集成 结合网上找的资料 做了如下整理
一.持续集成的过程如下：
比如说一家公司 代码仓库（比如说git）有3个分支：dev（开发分支） master（主干分支） release（预发布分支） 有5个程序员 分别开发如下5个模块：主页 微淘 社区 购物车 我的淘宝
6/17日报——持续集成理解
1.提交
假设a程序员开发完淘宝主页后 将自己模块的代码提交到git的dev分支上 接下来4个程序员也会提交到这个分支上
2.单元测试（第一轮）
a程序员提交到git后 会进行一遍单元测试（就是针对自己模块的测试 比如测试函数 某个for循环等）接下来的4个程序员也需要对自己负责的模块进行单元测试
3.构建
所有模块的单元测试没问题之后 这5个开发就可以把自己负责的模块合并到master主干 接下来需要构建这些模块代码的运行环境 比如说安装依赖 配置各种资源（css表 js脚本 图片等） 接下来各个测试需要把个字模块的代码与其他开发的模块的代码进行整合并进行联调测试（即前台和后台的整合测试）
4.功能测试（第二轮）
在开发联调完毕后 就可以交付给测试组进行功能测试了 需要强调的是 新版本的每一个更新点都必须测试到 如果测试的覆盖率不高 进入后面的部署阶段后 很可能会出现严重的问题
5.部署
测试通过后 则将master分支合并到release分支 然后部署服务器会将最新预发布的代码打包成当前版本 推送至生产服务器 如果该版本有问题 则回滚至上一个版本
例子：
1.开发a今天忘记写搜索功能和精选好物模块 9点写完之后 可以把含有这部分新增的代码提交到git上再进行构建 然后再根据实际情况决定要不要测试以及部署到生产环境上
二.持续集成的2个关键过程
1.持续交付
就是开发每完成一次构建 就要交付给测试执行功能测试 这个过程需要频繁（持续）进行
例子：在功能测试工程中发现登录文本框的密码输入框没有加密文 可以告诉开发 开发修改完这一方面的代码后 提交代码到测试环境 测试再继续测
2.持续部署
测试测过没问题之后 自动部署到生产环境 这个阶段的目标是代码可以在任意时间部署到生产环境上
例子：比如说测试漏测了 导致先杀环境出现bug 开发修改后 直接部署到生产服务器上
三.持续集成的好处
拿上面的例子举例
1.开发a更新完某一部分代码 提交到git后 测试通过询问开发拿到git路径后通过git -clone部署到测试环境上 测试发现某一部分有错误 告诉开发 开发修改完代码后 再把这部分代码更新到测试环境上 测试可以继续测试还有什么问题 即每完成一点更新（包括修改bug）就集成到主干 可以快速发现错误 定位错误也比较容易
2.能帮助项目在短时间内安全的发布新特性 而不用等上几个月甚至几年
四.持续集成的目的
1.让产品可以快速迭代 的同时保质保量
举个生活中的例子来理解下持续集成
有个产品 说要做一个人体雕塑（请不要想歪 谢谢）并卖给某个客户 开发就开始捏雕塑了 a开发捏好手臂 b开发捏好腿脚 c开发捏好头 d开发捏好上半身 都捏好之后 需要各自测试自己的那部分有没有问题 没问题之后把所有部分拼接起来 然后交给测试进行测试 测试发现手缺了个手指 开发a捏好之后再拼接到原来的手上再给测试进行测试 好了 没问题了 接着测试又发现这个雕塑的五官不够帅 c开发过来把鼻子捏的立体一点 把脸型捏的瓜子脸一点 测试看了下 好了 没问题了（持续交付的过程） 测试认为这个雕塑整体都没问题后 开始在街边一个小小的地方摆摊（来买的都是自己人的亲戚） 看看客人评价如何（预发布） 没问题之后 再发到市场上卖（部署）
过了一小时 客人纷纷反映雕塑没衣服不雅观 接着产品就发需求了：加衣服 开发d完成之后 交给测试测了没问题 再模拟摆摊 再发到市场 接下来又有客人反映应该戴副墨镜 应该穿个鞋子 接着又重复刚刚的步骤发到市场上（持续部署）
关于git跟jenkins的关系 git是一个代码仓库 负责存储代码的 是开发提交代码的那个步骤 所以只属于jenkins流程中的一部分
关于git分支的概念：
https://git-scm.com/book/zh/v1/Git-%E5%88%86%E6%94%AF-%E4%BD%95%E8%B0%93%E5%88%86%E6%94%AF
以上文章参考自：
1.
http://www.tuicool.com/articles/AzMVFjN
2.
http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html
——来自打字从不加逗句号的逗比
这算写完了 睡觉zzz
网友评论