持续集成

什么是持续集成

　　持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建包括编译，发布，自动化测试来验证，从而尽早地发现集成错误。让团队能够更快的开发内聚的软件。持续集成的作用有：

　　1、减少风险，一天中进行多次的集成，并做了相应的测试，这样有利于检查缺陷，了解软件的健康状况，减少假定；

　　2、增强项目的可见性，持续集成让我们能够注意到趋势并进行有效的决策；

　　3、建立团队对开发产品的信心，

持续集成的好处？

减少风险。可以节省时间、费用和工作量。持续集成可以让您在任何时间发布可以部署的软件。增强项目的可见性。建立团队对开发产品的信心。持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。减少风险一天中进行多次的集成，并做相应的测试，有利于检查缺陷，了解软件的健康状况，减少假定。减少重复过程减少重复过程可以节省时间、费用和工作量。说起来简单，做起来难。这些浪费时间的重复劳动可能在我们的项目活动的任何一个环节发生，包括代码编译、数据库集成、测试、审查、部署及馈。通过自动化的持续集成可以将这些重复的动作都变成自动化的，无需太多人工干预，让人们的时间更多地投入到动脑筋的、更高价值的事情上。任何时间、任何地点生成可部署的软件持续集成可以让您在任何时间发布可以部署的软件。从外界来看，这是持续集成最明显的好处，我们可以对改进软件品质和减少风险说起来滔滔不绝。但对于客户来说，可以部署的软件产品是最实际的资产。利用持续集成，您可以经常对源代码进行一些小改动，并将这些改动和其他的代码进行集成。如果出现问题，项目成员马上就会被通知到，问题会第一时间被修复。增强项目的可见性持续集成让我们能够注意到趋势并进行有效的决策。如果没有真实或最新的数据提供支持，项目就会遇到麻烦，每个人都会提出他最好的猜测。建立团队对开发产品的信心持续集成可以建立开发团队对开发产品的信心，因为他们清楚地知道每一次构建的结果，他们知道他们对软件的改动造成了哪些影响，结果怎么样。以上内容参考：百度百科 ——持续集成

什么是持续集成

集成是将更新的代码合并或者提交到主干源码仓库中。在这个合并或者提交的过程中，都伴随着执行一系列的质量保证活动如代码规范检查、单元测试、安全扫描等来确保代码的质量。持续集成是在版本控制的基础上，通过频繁的代码提交、自动化构建和单元测试加快集成周期和问题反馈速度，从而及时验证系统可用性。为了保证后续的系统质量，在持续集成过程中，还会加入代码规范扫描、安全漏洞扫描、集成测试等活动，用来保证代码形成过程符合质量要求。持续集成的频率达到每天多次、频繁的集成，可以提前发现问题尽早解决冲突，使后续的持续集成更顺畅。通常情况下，持续集成会与持续部署，持续交付一起被人们提及，其关系如下：

为什么要持续集成

在没有应用持续集成之前，传统的开发模式是项目一开始就划分模块，然后等所有的代码都开发完成之后再集成到一起进行测试，随着软件技术的发展，各种软件方法百花齐放，软件规模也在扩大，软件需求越来越复杂，软件已经不能简单地通过划分模块的方式来开发，需要项目内部互相合作，划 分模块这种传统的模式的弊端也越来越明显，由于很多 bug 在项目的早期就存在，到最后集成的时候才发现问题，开发者需要在集成阶段花费大量的时间来寻找 bug 的根源，加上软件的复杂性，问题的根源很难定位，甚至出现不得不调整底层架构的情况，在这个阶段的除虫会议（bug meetings）特别多，会议的内容基本上都是讨论 bug 是怎么产生的，最后往往发展成为不同模块的负责人互相推诿责任。
持续集成最大的优点是可以避免这种传统模式在集成阶段的除虫会议。持续集成主张项目的开发人员频繁的将他们对源码的修改提交(check in)到一个单一的源码库，并验证这些改变是否对项目带来了破坏，持续集成包括以下几大要点：
访问单一源码库，将所有的源代码保存在单一的地点（源码控制系统）， 让所有人都能从这里获取最新的源代码（以及以前的版本）。
支持自动化创建脚本，使 创建过程完全自动化，让任何人都可以只输入一条命令就完成系统的创建。
测试完全自动化，要求开发人员提供自测试的代码，让 任何人都可以只输入一条命令就运行一套完整的系统测试。
提供主创建，让任何人都可以只输入一条命令就可以开始主创建。
提倡开发人员频繁的提交（check in）修改过的代码。
持续集成的关键是完全的自动化，读取源代码、编译、连接、测试，整个创建过程都应该自动完成。对于一次成功的创建，要求在这个自动化过程中的每一步都不能出错，而最重要的一步是测试，只有最后通过测试的创建才是成功的创建。
在持续集成里面创建不再只是传统的编译和连接那么简单，创建还应该包括自测试，自测试的代码是开发人员提交源码的时候同时提交的，是针对源码的单元测试（源自 XP 的实践），将所有的这些自测试代码整合到一起形成测试集，在 所有的最新的源码通过编译和连接之后还必须通过这个测试集的测试才算是成功的创建。这 种测试的主要目的是为了验证创建的正确性，M cConnell 称之为冒烟测试，在 持续集成里面，这 叫做集成验收测试Build Verify Test，简称 BVT。BVT 测试是质量的基础，QA 小组不会感受到 BVT 的存在，他们只针对成功的
创建进行测试（如功能测试）。
BVT 测试应该尽量的详尽，详尽的测试才能发现更多的问题，而由此得到的反馈结果也更有参考意义，测试应该全部执行完毕，这样得到的反馈结果才是完整的，而不是遇到错误就放弃测试过程。
持续集成和日创建相比还有以下特点：
持续集成强调了集成频率，和日创建相比，持续集成显得更加频繁，目前推荐的最佳实践是每一个小时就集成一次。
持续集成强调及时反馈，日创建的目的是得到一个可以使用的稳定的发布版本，而持续集成强调的是集成失败之后向开发人员提供快速的反馈，当 然成功创建的结果也是得到稳定的版本。
日创建并没有强调开发人员提交（check in）源码的频率，而持续集成鼓励并支持开发人员尽快的提交对源码的修改并得到尽快的反馈。
从上面列出的续集成和日创建相比的特点来看，很明显， 频率和反馈这两个词出现的特别多，持 续集成有一个与直觉相悖的基本要点，那 就是 经常性的集成比偶尔集成要好。Martin Fowler 认为对于持续集成来说，集成越频繁，效果越好 ，如果你的集成不是经常进行的（少于每天一次），那么集成就是一件痛苦的事情，如果集成偶尔才进行一次（一周甚至一个月）， 等到集成阶段发现bug，然后找原因解决bug，会耗费你大量的时间与精力，而且这种方式有点象传统的集成模式，这违背了持续集成的初衷。
根据Martin Fowler 的观点，项目 bug 的增加和时间并不是线性增长的关系，而是和时间的平方成正比，两次集成间隔的时间越长，bug 增加的数量越超过你的预期，解决 bug 付出的工作量也越大，而你越觉得付出的工作量越大，你就越想推迟到以后去集成，企图到最后一次性解决问题，结果 bug 产生的就更多，导致下一次集成的工作量更大，你越感觉到集成的痛苦，就越将集成的时间推后，最后形成恶性循环。
因此如果集成的结果是让你感到痛苦，也许就说明你应该更频繁地进行集成。频繁的集成和及时的反馈鞭策着项目小组积极的面对问题，而 不是将问题推到最后来解决，如 果方法正确，更频繁的集成应该能减少你的痛苦，让你节约大量时间。
因为持续集成最终是通过测试来验证创建，所以你会发现对于持续集成的频率的要求跟Kent Beck 提出的测试驱动的开发方法里面测试第一的理念完全一致。需要注意的是从项目的一开始就引入持续集成可以尽早的发现 bug，但是并不代表持续集成可以帮你你抓到所有的 bug。持续集成的排错能力取决于测试技术，众所周知，无法证明已经经过测试的代码就已经找到了所有的错误。

持续集成的原则

1. 所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败。2. 开发人员每天至少向版本控制库中提交一次代码。3. 开发人员每天至少需要从版本控制库中更新一次代码到本地机器。4. 需要有专门的集成服务器来执行集成构建,每天要执行多次构建。5. 每次构建都要100%通过。6. 每次构建都可以生成可发布的产品。7. 修复失败的构建是优先级最高的事情。8. 测试是未来，未来是测试

你所熟知的CI/CD工具都是有哪些？

持续集成和持续交付可以帮助你自动化开发流程，同时确保跟踪所有内容。虽然持续集成(CI)和持续交付(CD)已成为DevOps的重要组成部分，但DevOps团队在选择最佳工具时往往会陷入困境。当今市场上广泛使用的CI/CD工具包括GitLab CI、Jenkins、Bamboo Server、TeamCity等等。
今天想提出来介绍一下的是我最近接触到的JFrog Pipelines。Pipelines 是下一代 DevOps 流水线自动化和编排解决方案，通过提供集中的命令和控制功能，来运用和提升流水线。 流水线使云原生应用程序交付更简单——具有用于基于容器版本的高级功能，并支持旧式和现代应用程序，确保一致的体验。维持现有的 CI/CD 投资，因为 JFrog Pipelines 可广泛集成各种常见的 CI/CD 工具和其他 DevOps 技术，大大包括代码存储库、测试工具，以及整个部署过程。 Pipelines 是管理 Jenkins 扩张的出色解决方案。
选择它基于这些优势：
1、与 Artifactory 原生集成：具有用于推送制品、执行构建、推送构建信息、镜像扫描和构建升级的内置指令。
2、简化和扩展您的流程：具备贯穿整个 CI/CD 流水线的灵活解决方案
3、通过集中解决方案：管理数千条流水线和用户
4、通过集中的精细权限划分和保密管理：兑现安全承诺
5、提高速度和效率：无需干预即可管理复杂流水线
6、支持本地部署、云、多云和混合公有云拓扑部署

持续集成的工具都有哪些

目前市场上主流的持续集成工具很多
例如 CruiseControL，hudson ，jenkins，还有apache的Continuum 等 开源的持续集成工具,
CruiseControl ：简称 CC ，持续集成工具，主要提供了基于版本管理工具 ( 如 CVS、VSS、SVN) 感知变化或每天定时的持续集成，并提供持续集成报告、 Email 、 Jabber 等等方式通知相关负责人，其要求是需要进行日构建的项目已编写好全自动的项目编译脚本 ( 可基于 Maven 或 Ant) 。由于该工具配置以及部署很麻烦 且版本很久没有更新
hudson 但是由于被oracle收购 很多以前开源的东西 以后很可能被ORACLE私有化
Hudson是Jenkins的前身，是基于Java开发的一种持续集成工具，用于监控程序重复的工作，包括：
1、持续的软件版本发布/测试项目。
2、监控外部调用执行的工作。