<转>聊聊持续集成

从别处看到了一篇关于持续集成的文章，我的感受蛮不错的，分享给你们。。。

原文连接：对于持续集成实践的常见问题解答

 

一、什么是持续集成？

集成，就是一些孤立的事物或元素经过某种方式集中在一块儿，产生联系，从而构成一个有机总体的过程。知识经济的社会，集成已经成了很重要的一个名词。各行各业基本都会用到集成。

而在软件行业中，集成并非一个简单的“搬箱子”的过程。由于软件工业是一个知识生产活动，其内在逻辑很是复杂，需求又很难一次性肯定，完成的产品与最初的设计每每相差很远。

敏捷宣言中就有一条是说响应变化重于遵循计划。并且因为软件行业的迅猛发展，软件变的愈来愈复杂，单靠我的是根本没法完成。

大型软件为了重用及解耦，每每还须要分红好几个模块，这样集成就成了软件开发中不可或缺的一部分。

持续集成这个词语最先是由大名鼎鼎的Martin Fowler提出的。他在早期进行软件行业实习的时候就发现一个问题,即集成是项目中的一个大难题。

他在英国一家软件公司实习时，项目经理亲口告诉他一个项目已经开发了好几年了，如今正在作集成，集成已经进行了好几个月了，每一个人都很疲惫，并不知道集成何时才能结束。

其中一个很重要的缘由就是项目集成发生的频率过低，致使你们对项目很没有信心。

在《持续集成》一书中，对持续集成的定义是这样的：持续集成是一种软件开发实践。

在持续集成中，团队成员频繁集成他们的工做成果，通常每人天天至少集成一次,也能够屡次。每次集成会通过自动构建(包括自动测试)的检验，以尽快发现集成错误。

自从在团队中引入这样的实践以后，Martin Fowler发现这种方法能够显著减小集成引发的问题，并能够加快团队合做软件开发的速度。

 

二、持续集成能给团队带来什么好处？

若是想要谈持续集成的好处，那么咱们应该先谈谈没有采纳持续集成，项目会出现什么问题。

整体来讲，没有采用持续集成的项目通常会面临下面四个问题：

①、没有一致的可部署的软件。只有在完成集成测试、系统测试后，才能获得可用的软件，整个过程当中只有最后时刻才能拿到可运行软件。集成活动不必定在一个标准的构建机器上生成，

   而是在某个开发人员的机器上构建的，那么可能存在在其余机器上没法运行的问题。

②、很晚才发现缺陷，而且难以修复。实践证实，缺陷发现的越晚，须要修复的时间和精力也就越大。从上一个可工做的软件到发现缺陷之间可能存在不少次提交，

   而要从这些提交中找出问题并修复的成本会很大，由于开发人员须要回忆每一个提交的上下文来评估影响点。

③、低品质的软件。 因为集成时每次包含的代码不少，因此你们的关注点主要都是如何保证编译经过、自动化测试经过，而每每很容易忽略代码是否遵照了编码规范、是否包含有重复代码、

   是否有重构的空间等问题。而这些问题又反过来会影响从此的开发和集成，长此以往集成变得愈来愈困难，软件的质量可想而知。

④、项目缺乏可见性。

而经过持续集成的活动，能够实现如下价值：

①、减小风险。缺陷的检测和修复变得更快。软件的健康程度能够测量；

②、减小重复过程。让人们有时间作更多的须要动脑筋的、更高价值的工做。经过对重要过程自动化，克服项目中某些成员对实现改进的抵制；

③、在任什么时候间、任何地点生成可部署的软件。对客户来讲，能够部署的软件是最实际的资产；

④、加强项目的可见性。集成就像咱们项目的一面镜子，经过这面镜子可以快速的了解项目目前的情况、存在的问题；

⑤、对开发团队的软件产品创建起更强大的信心。它可以帮咱们有效的决策，注意到项目进展的趋势；

 

三、持续集成都包括哪些要素？

一个最小化的持续集成系统须要包含如下几个要素：

①、版本管理系统：项目的源代码须要托管到适合的版本管理系统中，通常咱们使用git做为版本控制库，版本管理软件可使用github、gitlab、stash等。

②、构建脚本：每一个项目都须要有构建脚原本实现对整个项目的自动化构建。好比Java的项目就可使用gradle做为构建工具。

    经过构建工具实现对编译、静态扫描、运行测试、样式检查、打包、发布等活动串起来，能够经过命令行自动执行。

③、CI服务器：CI服务器能够检测项目中的代码变更，并及时的经过构建机器运行构建脚本，并将集成结果经过某种方式反馈给团队成员。

 

四、持续集成的全景图是什么样子的？

如下是持续集成的一个全景图。从中能够看到咱们须要版本管理系统、构建脚本、CI服务器、CI构建机器、反馈机制。

 

五、持续集成通常都包含哪些任务？

持续集成并非说只要代码能编译经过就是集成成功，咱们已经把每次集成都看作一次完整的测试。任何迁入到代码库中的代码都应该是能够部署到产品环境的。

拿一个Java项目为例，持续集成通常执行的任务有：

①、代码静态扫描：经过静态扫描肯定代码的一些潜在bug，好比未被使用的变量等。

②、代码样式检查：团队一致定义出须要遵循的编码规范，并经过一些插件对迁入的代码进行样式合规性检查，防止不守规范的代码进入版本库。

    好比方法名首字母小写、类的首字母大写、if关键字后面须要加空格等问题均可以归入到样式检查中。

③、单元测试、集成测试、系统测试：经过运行自动化的单元测试、集成测试、系统测试能够有效的保证迁入代码的质量。一旦有测试失败，开发人员就须要快速反应进行修复。

④、测试覆盖率检查：通常项目会有个测试覆盖率指标（好比80%），若是代码达不到这样的测试覆盖率，就不容许代码迁入。这样能够保证开发人员在新增功能时也要为新加入的功能编写自动化测试。

⑤、编译打包：确保没有任何语法错误，生成构建产出物。

⑥、发布: 将经过完整构建的产出物放置到产出物仓库，以便进行后续部署。

这些任务都必须是能经过命令行自动完成的，不一样类型的项目任务略有不一样。

 

六、持续集成这些任务应该遵循什么顺序？

其中有一个重要的原则就是fail fast，即快速失败。通常会把运行时间短的、价值大的任务放在前面，而运行时间长的任务放置到后面。

由于构建成功的标准是全部的验证都可以经过，那么执行时间短的任务放在前面能更快的获得反馈。

 

七、为何咱们组搭建了持续集成服务器，而且还派专人看守CI，可是感受项目并无明显的改善？

并非说搭建了持续集成服务器就说明团队能成功运行持续集成了。持续集成是一个实践，因此你们要遵循一些原则。

你们能够先思考一下问题：

①、在CI服务器上多久会看到一次集成？

②、CI服务器的集成结果是绿色居多（指构建成功）仍是红色居多（指构建失败）？

③、当构建失败后，团队成员有没有第一时间修复构建，有没有在构建失败的状况下依然在提交代码，在提交代码以前有没有进行本地的私有构建？

从这些问题能够引伸出持续集成中须要遵循的一些原则：

①、常常提交代码

②、不要提交没法构建的代码

③、当即修复没法集成的构建

④、编写自动化的开发者测试

⑤、必须经过全部测试和审查

⑥、执行私有构建

⑦、避免迁出没法构建的代码

 

八、本地提交代码应该通过哪些步骤？

本地提交能够采用经典的七步提交法。