当前课程知识点：软件工程与软件自动化 > 第六章 CI/CD与DevOps > 6.1 持续集成 > 持续集成视频1/2
大家好
今天我们开始讨论持续集成
首先我们来看一张版本号的截图
这个截图来自于我们常用的办公软件PowerPoint
平常我们一般说PowerPoint2007，2010，2013
这里显示的是PowerPoint2010，它的真正版本号
是14
我们把14叫作主版本号，后面的0是子版本号
4760是编译版本号，再往后1000是修正版本号
一般来说，前面数字变动了，说明软件的改动很
大
而后面的数字变动则说明软件的变化很小
从上面的数字来看，PowerPoint这个软件
至少发生了几千次的小版本变化
这些数字说明微软公司的软件开发过程
它的自动化程度是非常高的
那我们一般的开发团队，小公司
能不能提高软件开发自动化的程度呢
让我们来回顾一下软件开发的一般过程
一开始开发者把软件系统分成模块
然后等所有的代码都开发完成之后再集成到一起
进行测试
随着软件技术的发展，各种软件方法百花齐放
软件规模也在扩大，软件需求越来越复杂
由于很多 bug 在项目的初期已经存在了
只是到了后来集成的时候才暴露出来
开发者需要在集成阶段花费大量的时间来寻找
bug 的根源
加上软件的复杂性，问题的根源很难定位
甚至出现了不得不调整底层架构的情况
在这个阶段，除虫会议特别多
会议的内容基本上都是讨论 bug 是怎么产生的
最后往往发展成为不同模块的负责人之间互相推
诿的情况
后来人们开发了一些脚本把相关的开发工作连接
起来
从而形成了早期的软件自动化
早期的自动化叫Daily Build
顾名思义就是每天跑一次集成
后来人们发现这种自动化的集成最好是晚上来做
这样可以避开白天的开发高峰
所有又改名叫Nightly Build
随着构建的频率越来越高
Daily Build和Nightly Build都无法表达
这种一天超过一次的构建频率
于是就改为持续构建，但持续构建这个词动作过
于单一
因为构建这个词没有办法涵盖整个软件项目的开
发过程和目的
最后就改为持续集成
当然这个词也不是很完美
持续的意思很容易让人误解
也就是说这个集成的动作是一直做下去没有停止
的
当然它的实际的意思是经常的，频繁的进行集成
的动作
说到持续集成，我们来看一下Martin Fowler
给持续集成下的那个最原始的定义
他强调团队开发成员要经常集成他们的工作
通过每个成员每天至少集成一次
也就是意味着每天会发生很多次的集成
每次集成都通过自动化的构建来验证
从而尽早地发现集成错误
这里他特意强调构建包括了编译，发布和自动化
测试等动作
持续集成最明显的好处就是可以避免
传统的开发模式那种集成阶段的除虫会议
通过持续集成，绝大多数的Bug
都可以在引入的同一天被发现
由于一天当中程序员改动的代码并不多
所以可以很快的找到出错的位置，并消除bug
总之，持续集成可以减少集成阶段"捉虫子"所消
耗的时间
可以加快发布新版本的频率
从而最终提高生产力和软件质量
下面我们看一看，一个典型的持续集成流程是如
何进行的
首先，开发人员在完成了代码编写之后
向版本控制库提交代码
在提交代码之前，需要在本地机器上执行一次私
有构建
来确保自己的代码修改是正确的
同时，集成服务器会不停的轮询检查
版本控制库中的代码变更
一旦检测到有代码变动
CI服务器就会从版本控制库中拉取最新的代码
到集成服务器上去
然后执行构建脚本，对软件进行编译
单元测试和代码规范检查
甚至包括自动化文档生成等一系列的动作
完成了所有的工作之后，CI服务器根据构建结果
向特定的项目成员发送电子邮件，反馈持续集成
的结果
比如向项目经理发送集成的摘要信息
向发现了Bug的源代码的作者发送bug信息等等
然后CI服务器继续监控版本控制库中的代码变更
等待进入下一次持续集成
从这个典型的持续集成流程中大家可以看出
任何一个集成环境都应该具备四个特征
与版本控制系统的连接，构建脚本，反馈机制
以及集成源代码变更的过程
在公司实行持续集成不是一件容易的事情
那么是什么吸引着我们去做持续集成呢？
这就需要提到持续集成能够带来的价值
首先是减少风险
如果我们可以一天进行多次构建
就可以有效的减少项目的风险
因为CI每天进行多次集成并执行了测试和审查
所以在缺陷引入的时候就很有可能发现它们
同时通过收集项目的信息
就可以对项目进行接近实时的追踪
也就是说，持续集成提供了一张安全网
降低了缺陷进入代码的风险
其次是减少重复过程
减少重复过程可以节约时间，费用和工作量
让人们有时间去做那些需要动脑筋的
更具有价值的工作
第三，可以生成可部署的软件
对于客户来说，他们其实并不真正的关心
我们团队内部是如何做的
他们更关心的是能不能可以看到实际跑的软件产
品
不采用CI的项目可能需要等到交付之前
才能对软件进行集中的测试和集成
这可能会延迟产品的发布，甚至会导致项目的失
败
CI的第四个价值就是增强项目的可视性
我们前面说过，未知会引起恐惧
如果我们能够通过CI获取当前的构建状态和品质
指标
获取软件当前的缺陷率和功能完成情况的统计
就有助于管理者和客户了解软件产品的开发进展
从而做出更有效的决策
并能够及时对项目的发展趋势做出正确的判断
最后，成功的CI可以给软件开发团队带来更大的
信心
每一次成功的构建都会告诉我们的团队成员
他们的工作通过了测试和验证
他们的代码符合了项目编码标准和设计标准
他们距离成功又近了一步
如果我们的团队要实施持续集成
应该注意以下这些CI实践
CI的核心原则是“早集成，常集成”
所以我们要提倡开发者更加频繁的提交代码
把任务分解成更小的工作
每个任务完成之后马上提交代码
避免在下班前集中提交，从而避免引起更多的构
建错误
开发者在提交代码前，要确保自己在本机上完成
了私有构建
并且完成了所有必需的单元测试，通过了代码覆
盖率检查
代码编写规范检查等等
在CI环境下，每个错误都是以增量的方式被发现
的
因此很可能是个小的错误，很容易被修复
而且在团队中要求大家把修复构建错误
作为优先级最高的事情来做
以避免影响团队中其他成员的工作进度
特别需要注意的是，当构建失败的时候
不要从版本控制库中签出新的代码
否则，你就无法编译和测试你自己的代码
而别人的错误你又无法解决，只能想办法绕过去
实际上，引起构建失败的开发者可能正在紧锣密
鼓的
修复他们自己的代码，或者正打算将修复好的代
码
提交到版本控制库
所以，虽然构建失败可能会导致开发者的工作有
一个短暂的停滞
但是总比签出带有错误的代码而无法继续工作要
好一些
-1.1 软件工程的前生今世
--开篇阅读
--授课视频
-第一章 软件工程基础--1.1 软件工程的前生今世
-1.2 万变不离其宗
--授课视频1/3
--授课视频2/3
--授课视频3/3
-第一章 软件工程基础--1.2 万变不离其宗
-1.3 唯一不变的是变化
--授课视频1/3
--授课视频2/3
--授课视频3/3
--外部链接
-第一章 软件工程基础--1.3 唯一不变的是变化
-1.4 亡羊补牢为时不晚
--授课视频1/2
--授课视频2/2
-第一章 软件工程基础--1.4 亡羊补牢为时不晚
-扩展阅读与话题讨论
--扩展阅读
--话题讨论
-2.1 方法论来源于恐惧
--授课视频
-第二章 敏捷开发--2.1 方法论来源于恐惧
-2.2 敏捷是什么
--授课视频
-第二章 敏捷开发--2.2 敏捷是什么
-2.3 典型敏捷开发方法
--XP敏捷开发方法
-第二章 敏捷开发--2.3 典型敏捷开发方法
-2.4 敏捷不是万能药
--授课视频
-第二章 敏捷开发--2.4 敏捷不是万能药
-专家谈敏捷
-扩展阅读与话题讨论
--外部链接
--话题讨论
-3.1 面向对象核心概念和基本特性
-第三章 OO与UML--3.1 面向对象核心概念和基本特性
-3.2 面向对象设计基本原则
-第三章 OO与UML--3.2 面向对象设计基本原则
-3.3 通用职责分配模式(GRASP)
--通用职责分配模式
-3.3 通用职责分配模式(GRASP)--作业
-3.4 从重构到模式
--模式和设计模式
-第三章 OO与UML--3.4 从重构到模式
-3.5 使用UML设计面向对象系统
--UML综述
-第三章 OO与UML--3.5 使用UML设计面向对象系统
-3.6 主要UML模型图绘制技巧
--UML用例图
--UML类图
-第三章 OO与UML--3.6 主要UML模型图绘制技巧
-扩展阅读与话题讨论
--设计模式有毒么？
--话题讨论
-4.1 案例简介
--书籍参考
--案例说明
-4.2 对象模型之一
--授课视频1/2
--授课视频2/2
-第四章 对象模型分析--4.2 对象模型之一
-4.3 对象模型之二
--授课视频1/2
--授课视频2/2
-第四章 对象模型分析--4.3 对象模型之二
-4.4 对象模型之交互
--授课视频
-第四章 对象模型分析--4.4 对象模型之交互
-扩展阅读与话题讨论
--图书推荐
--话题讨论
-5.1 软件自动化概述
--软件自动化概述
-第五章 软件自动化技术--5.1 软件自动化概述
-5.2 典型自动化方法和工具
-第五章 软件自动化技术--5.2 典型自动化方法和工具
-5.3 文档自动化
--文档自动化视频
-第五章 软件自动化技术--5.3 文档自动化
-5.4 测试自动化
--测试自动化视频
-第五章 软件自动化技术--5.4 测试自动化
-专家访谈
-扩展阅读与话题讨论
--话题讨论
-6.1 持续集成
-第六章 CI/CD与DevOps--6.1 持续集成
-6.2 持续交付和部署
-第六章 CI/CD与DevOps--6.2 持续交付和部署
-6.3 DevOps
-第六章 CI/CD与DevOps--6.3 DevOps
-专家访谈
-扩展阅读与话题讨论
--DevOps专题
--话题讨论
-7.1 质量和质量保证
--授课视频
-第七章 软件质量保证--7.1 质量和质量保证
-7.2 软件质量模型
--授课视频
-第七章 软件质量保证--7.2 软件质量模型
-7.3 SQA组织与职责
--授课视频
-第七章 软件质量保证--7.3 SQA组织与职责
-7.4 全面软件质量管理
--授课视频
-第七章 软件质量保证--7.4 全面软件质量管理
-专家访谈
--专家访谈
-扩展阅读与话题讨论
--外部链接
--话题讨论
-8.1 软件过程综述
--授课视频
-第八章 软件过程改进--8.1 软件过程综述
-8.2 软件过程改进
--授课视频
-第八章 软件过程改进--8.2 软件过程改进
-8.3 能力成熟度模型
--授课视频
-第八章 软件过程改进--8.3 能力成熟度模型
-8.4 过程改进标准框架
--授课视频
-第八章 软件过程改进--8.4 过程改进标准框架
-扩展阅读与话题讨论
--话题讨论
-9.1软件复用综述
--授课视频
-第九章 软件复用--9.1软件复用综述
-9.2 软件构件技术
--授课视频
-第九章 软件复用--9.2 软件构件技术
-9.3 软件复用实施
--授课视频
-第九章 软件复用--9.3 软件复用实施
-9.4 微服务架构
--授课视频
-第九章 软件复用--9.4 微服务架构
-扩展阅读与话题讨论
--微服务扩展
--话题讨论
-文档提交处--文档提交
