持续集成 订阅
持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。 展开全文
持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。
信息
外文名
Continuous integration
属    于
软件开发实践
过    程
敏捷开发
中文名
持续集成
学    科
电子工程
持续集成定义
大师Martin Fowler对持续集成是这样定义的:持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题,让团队能够更快的开发内聚的软件。持续集成的宗旨是避免集成问题,如同在极限编程(XP)方法学中描述的集成地狱。持续集成并非普遍接受是用来改善集成频率的方法,因此重要的是区分两者所带来的效益。在极限编程方法学,持续集成需要达到最佳成果,必须依靠着自动化集成单元测试并通过测试驱动开发。首先必须设想在上线运作之前,已在开发环境完成并通过所有的单元测试。这将帮助避免一个开发者的作业流程,导致其他开发者作业的中断。如果有需要,可以在完整上线运作之前进用部分已完成的功能,例如使用功能切换。接着进行CI服务器建置概念的阐述、自动化运行单元测试的周期与每次测试需要提交给开发者的报告。建置CI服务器的用途(不一定要运行单元测试) 已经开始在极限编程(XP)社群之外的团队练习。如今,许多企业组织已经开始采用持续性集成,而非采用完整的极限编程(XP)。除了自动化单元测试,组织在运用持续性集成(CI)一般会建置CI服务器来维护持续性套用质量控制的程序-小部分的影响,并且经常性使用。除了运行单元与集成测试之外,还有额外的静态与动态测试,量测与描述性能,从程序来源码摘录与文件格式与促成手动质量保证(QA)程序。持续性质量控制应用程序用意在提升软件质量以及减少交付的时间,在完成所有开发后,取代传统软件上线质量控制机制。此非常相似进行频繁集成的最初概念让集成得以在QA程序上更容易地达成。同样的道理,持续性交付的最佳实践进一步扩展了持续性集成(CI),以确保软件检核在主要程序上并且能够布署到用户以确保实际的布署流程可以非常快速。 [1] 
收起全文
精华内容
参与话题
问答
  • 持续集成是什么?

    2016-05-12 00:53:01
    互联网软件的开发和发布,已经形成了一套标准流程,最重要的组成部分就是持续集成(Continuous integration,简称CI)。 本文简要介绍持续集成的概念和做法。 一、概念 持续集成指的是,频繁地(一天多次)将代码...
    互联网软件的开发和发布,已经形成了一套标准流程,最重要的组成部分就是持续集成(Continuous integration,简称CI)。

    本文简要介绍持续集成的概念和做法。

    一、概念

    持续集成指的是,频繁地(一天多次)将代码集成到主干。

    它的好处主要有两个。

    (1)快速发现错误。每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易。

    (2)防止分支大幅偏离主干。如果不是经常集成,主干又在不断更新,会导致以后集成的难度变大,甚至难以集成。

    持续集成的目的,就是让产品可以快速迭代,同时还能保持高质量。它的核心措施是,代码集成到主干之前,必须通过自动化测试。只要有一个测试用例失败,就不能集成。

    Martin Fowler说过,"持续集成并不能消除Bug,而是让它们非常容易发现和改正。"

    与持续集成相关的,还有两个概念,分别是持续交付和持续部署。

    二、持续交付

    持续交付(Continuous delivery)指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。

    持续交付可以看作持续集成的下一步。它强调的是,不管怎么更新,软件是随时随地可以交付的。

    三、持续部署

    持续部署(continuous deployment)是持续交付的下一步,指的是代码通过评审以后,自动部署到生产环境。

    持续部署的目标是,代码在任何时刻都是可部署的,可以进入生产阶段。

    持续部署的前提是能自动化完成测试、构建、部署等步骤。它与持续交付的区别,可以参考下图。

    图片来源

    四、流程

    根据持续集成的设计,代码从提交到生产,整个过程有以下几步。

    4.1 提交

    流程的第一步,是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交(commit)。

    4.2 测试(第一轮)

    代码仓库对commit操作配置了钩子(hook),只要提交代码或者合并进主干,就会跑自动化测试。

    测试有好几种。

    • 单元测试:针对函数或模块的测试
    • 集成测试:针对整体产品的某个功能的测试,又称功能测试
    • 端对端测试:从用户界面直达数据库的全链路测试

    第一轮至少要跑单元测试。

    4.3 构建

    通过第一轮测试,代码就可以合并进主干,就算可以交付了。

    交付后,就先进行构建(build),再进入第二轮测试。所谓构建,指的是将源码转换为可以运行的实际代码,比如安装依赖,配置各种资源(样式表、JS脚本、图片)等等。

    常用的构建工具如下。

    Jenkins和Strider是开源软件,Travis和Codeship对于开源项目可以免费使用。它们都会将构建和测试,在一次运行中执行完成。

    4.4 测试(第二轮)

    构建完成,就要进行第二轮测试。如果第一轮已经涵盖了所有测试内容,第二轮可以省略,当然,这时构建步骤也要移到第一轮测试前面。

    第二轮是全面测试,单元测试和集成测试都会跑,有条件的话,也要做端对端测试。所有测试以自动化为主,少数无法自动化的测试用例,就要人工跑。

    需要强调的是,新版本的每一个更新点都必须测试到。如果测试的覆盖率不高,进入后面的部署阶段后,很可能会出现严重的问题。

    4.5 部署

    通过了第二轮测试,当前代码就是一个可以直接部署的版本(artifact)。将这个版本的所有文件打包( tar filename.tar * )存档,发到生产服务器。

    生产服务器将打包文件,解包成本地的一个目录,再将运行路径的符号链接(symlink)指向这个目录,然后重新启动应用。这方面的部署工具有AnsibleChefPuppet等。

    4.6 回滚

    一旦当前版本发生问题,就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接,指向上一个版本的目录。

    五、参考链接





    文章转载:http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html
    展开全文
  • 持续集成、持续交付、持续部署(CI/CD)简介 概述: 软件开发周期中需要一些可以帮助开发者提升速度的自动化工具。其中工具最重要的目的是促进软件项目的持续集成与交付。通过CI/CD工具,开发团队可以保持...

    概述:

    软件开发周期中需要一些可以帮助开发者提升速度的自动化工具。其中工具最重要的目的是促进软件项目的持续集成与交付。通过CI/CD工具,开发团队可以保持软件更新并将其迅速的投入实践中。CI/CD也被认为是敏捷开发的最重要实践之一。


    一 、持续集成

    从上图可以看到,持续集成应该至少包括以下几部分:

    • 自动化构建Continuous Build
    • 自动化测试Continuous Test
    • 自动化集成Continuous Intergration
    1. 自动化构建

    包括以下过程:

    • 将源码编译成为二进制码
    • 打包二进制码
    • 运行自动化测试
    • 生成文档
    • 生成分发媒体(例如:Debian DEB、Red Hat RPM或者Windows MSI文件)

    所以,自动化构建,从功能角度分,最关键的是三部分:版本控制工具、构建工具、CI服务器。而其中最核心的又是构建工具。其他开源的、与持续集成相关的工具也有很多,但大多数是辅助性的工具。

    (1)版本控制工具

    有时,版本控制又称为配置管理(SCM),所以版本控制工具同时也是配置管理工具。在各类版本控制的开源软件中,最著名的莫过于CVS、SVN(Subversion)、GIT三个了。
    这三个工具各有千秋。其中,GIT支持离线工作,更适合开源软件或者开发人员不能集中办公情况下的版本管理工作。同时,SVN和GIT可以配合使用。

    (2)构建工具

    构建工具是持续集成的核心,它对源代码进行自动化编译、测试、代码检查,以及打包程序、部署(发布)到应用服务器上。从配置管理工具上下载最新源代码后,所有的后续工作几乎都可以通过构建工具完成。
    在java开发中,比较有名的构建工具就是Ant、Maven、Gradle。在PHP开发中,Phing(基于Ant)也比较有名。同样的,Maven也可通过相关的PHP-Maven插件完成对PHP开发构建的支持。

    (3)CI服务器

    CI服务器的主要作用就是提供一个平台,用于整合版本控制和构建工作,并管理、控制自动化的持续集成。
    开源软件中,比较有名的CI服务器包括Jenkins、CruiseControl、Continuum。而比较有名的商业化CI服务器是TeamCity、Bamboo、Pulse等。

    (4)其他工具

    很多工具可以通过与构建工具、CI工具相结合(当然,其中有很多工具也可以单独工作),来完成更多的自动测试、报告生成等工作。根据工具不同,其具体的结合方法也不同,但大体都是通过插件形式进行结合的。例如:

    • Maven中通过依赖和plugin方式引入第三方工具
    • Jenkins主要通过各类插件引入第三方工具

    这些工具种类实在太多,可以根据实际工作需要进行选择。

    2.自动化测试

    自动化测试是持续集成必不可少的一部分,基本上,没有自动化测试的持续集成,都很难称之为真正的持续集成。我们希望持续集成能够尽早的暴露问题,但这远非配置一个 Hudson/Jenkins服务器那么简单,只有真正用心编写了较为完整的测试用例,并一直维护它们,持续集成才能孜孜不倦地运行测试并第一时间报告问题。

    测试自动化是使用特定的软件(独立于被测试的软件)来控制测试的执行以及比较实际输出与预期输出。测试自动化可以将某些重复但必要的任务自动化,或者执行某些难以手动执行的额外测试。

    自动化测试还包括单元测试、集成测试、系统测试、验收测试、性能测试等,在不同的场景下,它们都能为软件开发带来极大的价值。


    二、持续交付

    持续交付(Continuous Delivery, CD)是一种软件工程的手段,让软件在短周期内产出,确保软件随时可以被可靠地发布。其目的在于更快、更频繁地构建、测试以及发布软件。通过加强对生产环境的应用进行渐进式更新,这种手段可以降低交付变更的成本与风险。一个简单直观的与可重复的部署过程对于持续交付来说是很重要的。

     持续交付流水线示意图


    三、持续部署

    如图所示,持续部署与持续交付之间的差异就是前者将部署自动化了。
    在持续交付的实践中,交付的目标是QA,但是实际上,软件最终是要交付到客户手上的。在SaaS领域里,持续部署采用得比较广泛,因为服务比较容易做到静默升级。
    采用持续部署的前提是自动化测试的覆盖率足够高。
    采用持续部署的好处是能减少运维的工作量,缩短新特性从开发到实际交付的周期。


    四、CI/CD具体实现

    常见CI/CD工具及其比较:

    这里的支持,意思应该是直接的支持,例如Jenkins,其实和git结合也很简单,通过脚本就可以实现。


    五、持续集成工具集之 Jenkins简介

    Jenkins 是一个可扩展的持续集成引擎。

    1.主要用于:

    • 持续、自动地构建/测试软件项目。
    • 监控一些定时执行的任务。Jenkins拥有的特性包括:

    2.Jenkins拥有的特性包括:

    • 易于安装-只要把jenkins.war部署到servlet容器,不需要数据库支持。
    • 易于配置-所有配置都是通过其提供的web界面实现。
    • 集成RSS/E-mail通过RSS发布构建结果或当构建完成时通过e-mail通知。
    • 生成JUnit/TestNG测试报告
    • 分布式构建支持Jenkins能够让多台计算机一起构建/测试。
    • 文件识别:Jenkins能够跟踪哪次构建生成哪些jar,哪次构建使用哪个版本的jar等。
    • 插件支持:支持扩展插件,你可以开发适合自己团队使用的工具。

    3.Jenkins的出现

    目前持续集成(CI)已成为当前许多软件开发团队在整个软件开发生命周期内侧重于保证代码质量的常见做法。它是一种实践,旨在缓和和稳固软件的构建过程。并且能够帮助您的开发团队应对如下挑战:

    • 软件构建自动化 :配置完成后,CI系统会依照预先制定的时间表,或者针对某特定事件,对目标软件进行构建。
    • 构建可持续的自动化检查 :CI系统能持续地获取新增或修改后签入的源代码,也就是说,当软件开发团队需要周期性的检查新增或修改后的代码时,CI系统会不断确认这些新代码是否破坏了原有软件的成功构建。这减少了开发者们在检查彼此相互依存的代码中变化情况需要花费的时间和精力。
    • 构建可持续的自动化测试 :构建检查的扩展部分,构建后执行预先制定的一套测试规则,完成后触发通知(Email,RSS等等)给相关的当事人。
    • 生成后后续过程的自动化 :当自动化检查和测试成功完成,软件构建的周期中可能也需要一些额外的任务,诸如生成文档、打包软件、部署构件到一个运行环境或者软件仓库。这样,构件才能更迅速地提供给用户使用。

    部署一个CI系统需要的最低要求是,一个可获取的源代码的仓库,一个包含构建脚本的项目。

    下图概括了CI系统的基本结构:
    4.使用Jenkins的一些理由:

    该系统的各个组成部分是按如下顺序来发挥作用的:

    • 开发者检入代码到源代码仓库。
    • CI系统会为每一个项目创建了一个单独的工作区。当预设或请求一次新的构建时,它将把源代码仓库的源码存放到对应的工作区。
    • CI系统会在对应的工作区内执行构建过程。
    • (配置如果存在)构建完成后,CI系统会在一个新的构件中执行定义的一套测试。完成后触发通知(Email,RSS等等)给相关的当事人。
    • (配置如果存在)如果构建成功,这个构件会被打包并转移到一个部署目标(如应用服务器)或存储为软件仓库中的一个新版本。软件仓库可以是CI系统的一部分,也可以是一个外部的仓库,诸如一个文件服务器或者像Java.NET、 SourceForge之类的网站。
    • CI系统通常会根据请求发起相应的操作,诸如即时构建、生成报告,或者检索一些构建好的构件。

    Jenkins就是这么一个CI系统。之前叫做Hudson。

    • 是所有CI产品中在安装和配置上最简单
    • 基于Web访问,用户界面非常友好、直观和灵活,在许多情况下,还提供了AJAX的即时反馈。
    • Jenkins是基于Java开发的(如果你是一个Java开发人员,这是非常有用的),但它不仅限于构建基于Java的软件。
    • Jenkins拥有大量的插件。这些插件极大的扩展了Jenkins的功能;它们都是开源的,而且它们可以直接通过web界面来进行安装与管理。

    5.Jenkins的目标

    Jenkins的主要目标是监控软件开发流程,快速显示问题。所以能保证开发人员以及相关人员省时省力提高开发效率。

    CI系统在整个开发过程中的主要作用是控制:当系统在代码存储库中探测到修改时,它将运行构建的任务委托给构建过程本身。如果构建失败了,那么CI系统将通知相关人员,然后继续监视存储库。它的角色看起来是被动的;但它确能快速反映问题。

    特别是它具有以下优点:

    • Jenkins一切配置都可以在web界面上完成。有些配置如MAVEN_HOME和Email,只需要配置一次,所有的项目就都能用。当然也可以通过修改XML进行配置。
    • 支持Maven的模块(Module),Jenkins对Maven做了优化,因此它能自动识别Module,每个Module可以配置成一个job。相当灵活。
    • 测试报告聚合,所有模块的测试报告都被聚合在一起,结果一目了然,使用其他CI,这几乎是件不可能完成的任务。
    • 构件指纹(artifact fingerprint),每次build的结果构件都被很好的自动管理,无需任何配置就可以方便的浏览下载。
    展开全文
  • 一、持续集成是什么? 持续集成是一种软件开发的实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化...

    一、持续集成是什么?

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

    持续集成指的是,频繁地(一天多次)将代码集成到主干,通过持续集成流程的进行自动化方式的构建,编译和测试,提供可以部署发布的单元包

    持续集成的目的,就是让产品可以快速迭代,同时还能保持高质量。

    它的核心措施是,代码集成到主干之前,必须通过自动化测试。

    只要有一个测试用例失败,就不能集成。

    Martin Fowler说过,"持续集成并不能消除Bug,而是让它们非常容易发现和改正。与持续集成相关的,还有两个概念,分别是持续交付和持续部署。

    二 持续集成的价值是什么?

    1、降低风险,由于持续集成不断去构建,编译和测试,可以很早期发现问题,所以修复的代价就少;

    2、对系统健康持续检查,减少发布风险带来的问题;

    3、减少重复性工作;

    4、持续部署,提供可部署单元包;

    5、持续交付可供使用的版本;

    6、增强团队信心;

    三、持续集成流程

    持续集成一般的做法: 通过svn或其他工具拉取代码->自动化构建->自动化编译->自动化测试->自动化部署->自动化发布->邮件发送通知;

    四、持续交付

    持续交付(Continuous delivery)指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。

    持续交付可以看作持续集成的下一步。它强调的是,不管怎么更新,软件是随时随地可以交付的。

    五、持续部署

    持续部署(continuous deployment)是持续交付的下一步,指的是代码通过评审以后,自动部署到生产环境。

    持续部署的目标是,代码在任何时刻都是可部署的,可以进入生产阶段。

    持续部署的前提是能自动化完成测试、构建、部署等步骤。

    测试是持续集成流程中重要的一环,也是区别去传统的软件开发流程中的一个重要的标志。为什么要有持续集成测试呢?

    1、可以早点发现bug,这就是fix bug代价比较小

    2、可以平滑产品,提高产品质量

    3、可以让团队的每个人了解产品的质量状态

    4、每天都有持续集成测试的报告发布

    5、开发者对自己提交的代码测试情况有比较清晰的了解

    6、可以有效地解决在QA人手不足的情况

    7、尽可能地把测试自动化,让持续集成测试系统去执行这些自动化测试的case


    以前团队工作方式

    1、打包,等待maven编译打包
    2、发布测试环境,手动重启服务
    3、通知测试组测试(邮件、用嘴巴喊等等方式…)
    4、一顿grep查Exception,修复BUG,然后重复1、2、3、4
    5、到达特殊的日子时,配合运维部署团队到测试环境手动copy最新版WAR包到生产环境,23点的一瞬间执行一个脚本,时刻盯住脚本运行结果,最后验证
    在这里插入图片描述

    我们可以发现很多问题:
    1,编译打包的过程浪费开发资源,一次测试部署正常10到20分钟,那出现问题的情况…

    2,测试长时间怠工,资源利用不充分,处于一人干活多人旁观低绩效状态

    3,研发与测试的沟通方式高成本低效率

    4,BUG反馈方式低效

    5,生产环境得不到有效的管控以及安全保障,人工浪费如果产品或者销售想要给客户演示测试环境,得到的结果可能是测试暂时不可用或者稍微等15到20分钟,是否能计算出他们的心理阴影面积?

    DevOps的中心思想在于提高产品各个阶段的产出效率减少或者避开团队间的沟通障碍,推动产品的快速迭代,“快速失败”,从而实现持续交付、持续部署。而持续集成只是DevOps中的一个环节,下图清晰描述了CI各个周期活动。
    在这里插入图片描述
    我们可以发现较多优点:
    1、流程全自动化,减少重复性的手工操作
    2、持续发布测试,时刻保持可发布的产品
    3、团队、高层对项目、产品的进展清晰可见,把控风险
    4、资源效率有效利用,流动效率更快

    因此,我们要做到持续集成,我们需要:

    1、一套持续集成工具,大体可分为云集成与本地化集成系统,云集成比如Travis CI、cloudbees的云集成等,本地化集成主要是开源Jenkins的搭建,如果需要大规模部署Jenkins且有预算可使用Jenkins商业版

    2、自动化测试工具、良好的测试用例编写

    3、版本控制系统,git、gerrit推荐

    4、构建、测试失败反馈机制,邮件、自动化运维(AI…)、日志收集分析系统

    5、一套需求、产品、开发、测试、部署、运维共同使用的敏捷研发管理系统,市场上有阿里云效、腾讯的TAPD等


    流程(A)

    根据持续集成的设计,代码从提交到生产,整个过程有以下几步。

    1 提交

    流程的第一步,是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交(commit)。

    2 测试(第一轮)

    代码仓库对 commit 操作配置了钩子(hook),只要提交代码或者合并进主干,就会跑自动化测试。

    测试有好几种。

    单元测试:针对函数或模块的测试
    集成测试:针对整体产品的某个功能的测试,又称功能测试
    端对端测试:从用户界面直达数据库的全链路测试
    第一轮至少要跑单元测试。

    3 构建

    通过第一轮测试,代码就可以合并进主干,就算可以交付了。

    交付后,就先进行构建(build),再进入第二轮测试。所谓构建,指的是将源码转换为可以运行的实际代码,比如安装依赖,配置各种资源(样式表、JS 脚本、图片)等等。

    常用的构建工具如下。

    Jenkins
    Travis
    Codeship
    Strider
    Jenkins 和 Strider 是开源软件,Travis 和 Codeship 对于开源项目可以免费使用。它们都会将构建和测试,在一次运行中执行完成。

    4 测试(第二轮)

    构建完成,就要进行第二轮测试。如果第一轮已经涵盖了所有测试内容,第二轮可以省略,当然,这时构建步骤也要移到第一轮测试前面。

    第二轮是全面测试,单元测试和集成测试都会跑,有条件的话,也要做端对端测试。所有测试以自动化为主,少数无法自动化的测试用例,就要人工跑。

    需要强调的是,新版本的每一个更新点都必须测试到。如果测试的覆盖率不高,进入后面的部署阶段后,很可能会出现严重的问题。

    5 部署

    通过了第二轮测试,当前代码就是一个可以直接部署的版本(artifact)。将这个版本的所有文件打包( tar filename.tar * )存档,发到生产服务器。

    生产服务器将打包文件,解包成本地的一个目录,再将运行路径的符号链接(symlink)指向这个目录,然后重新启动应用。这方面的部署工具有 Ansible,Chef,Puppet等。

    6 回滚

    一旦当前版本发生问题,就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接,指向上一个版本的目录。


    流程(B)

    实现持续集成,一般需要以下内容:

    1. 具有版本控制功能的代码库

    例如:SVN, Git。相信现在的项目没有不对代码进行版本管理的,所以这方面内容大家也应该非常熟悉。在这里不再详述。

    2. 构建工具

    在持续集成的过程中,需要对已存在的或者新提交的代码进行编译、打包等操作。这样,就需要构建工具帮助构建一个编译环境,并对代码进行编译、集成、打包等操作。而构建的方式越简单越好,最好是一句命令就可以启动构建。现在,各种语言都有自己的构建工具,例如Java中的Maven、Gradle、Ant,前端中的Grunt、Gulp等等,好好利用这些工具,就能帮你完成这部分工作。

    3. 测试

    测试是持续集成中重要的一环。代码提交前,需要在本地运行单元测试,通过测试后再提交代码。构建完成后,需要运行全部测试(单元测试,功能测试,端到端测试)以确保产品质量。如果有一个测试没有通过,那么这次提交的代码不能进入主干;或者这次构建的产物是一个失败的构建品,不能用于发布。另外,由于持续集成依赖于这些测试去保证产品质量,所以测试的覆盖率要尽可能高。测试覆盖率不够高(包含代码覆盖率和功能覆盖率),就无法充分反映代码的变动是否对系统带来影响。而低覆盖率的测试,压根就无法保证产品质量。当上线的时候才发现问题就太迟了。

    4. CI工具

    CI工具的作用是将整个CI过程管理起来并自动化,结果可视化。部分工具还结合了CD(持续交付)的功能。现在已经有很多CI工具去满足你不同的需求,例如Jenkins,专为Github开源项目提供的Travis,.Net用的CruiseControl.Net。他们各有特色,根据自己的需求选择适合自己的工具即可。

    好了,当集齐以上内容后。我们用一个例子来介绍一下一个典型流程是怎样的。

    例子背景描述

    假设我们现在有一个产品P,以war包形式发布,由三个模块module A, module B, module C构建而成。三个模块的关系为:A和B为独立模块提供不同功能。C依赖A和B,然后构成产品P。我们使用了Git作为我们代码库的版本管理工具,用Java进行开发,maven作为我们的构建工具。在每个模块里,有我们基于JUnit写的单元测试代码。独立于三个模块外,有一块代码,也是基于JUnit写的,作为我们的功能测试代码(集成测试)。

    集成代码

    当我们完成开发工作,需要提交代码到代码库前,我们至少需要在本地跑一次单元测试,在保证全部测试通过后,才可以将代码提交至我们的代码库Git上面去。例如,在我们上面描术的项目中,我对module A的代码进行了修改,那我最起码得在本地运行一次mvn test(执行Maven命令,test代表将会执行到maven default生命周期中从validate到test阶段), 执行成功后,我才会将代码commit and push到远程Git库上去。要做到这样效果的话,就需要保证单元测试代码也同步完成。而在极限编程中(XP),人们比较倾向于测试驱动开发(TDD, Test-driven Development)的实践,通过提前写好自动化的单元测试,保证好每一步功能开发的质量。

    自动构建

    通过CI工具,可以设置一个勾子,当代码提交后触发相应构建。例如,我们提交了module A的代码时,Jenkins会扫描到我们这次提交,勾子触发module A的构建。这个过程会做如下操作:

    1,Jenkins调用Git插件,从Git库上下载最新代码;

    2,Jenkins调用Maven插件,执行Maven命令(一般为mvn install,如果需要上传至远端Maven库,也可以执行mvn deploy)对该模块进行构建。经过编译、通过单元测试后,便可以打包并安装到本地Maven库,以供其它依赖所用。这次构建成功,意味module A在模块自身的单元测试范围内是正常的。

    3,因为module A是包含在产品P里面,所以,也需要回归一产品功能测试。由于module C依赖A,并构建成产品。所以在CI工具里面,我们需要配置好在module A构建成功后,自动触发module C的构建,经过类似步骤1、2这样的构建后,最终会生成产品P的war包。而C的构建成功,只代表着通过了module C自身的单元测试,还不能对生成的war包进行功能测试。然后就要看我们下一步的工作--自动部署了。

    自动部署

    在功能测试之前,我们需要在CI工具里配置一项任务,用于将最新构建出来的产品包部署到测试工环境中去。这个任务由产品构建任务成功而被触发,而部署方式根据不同使用方式及不同的实际情况而多种多样。例如通过脚本将新构建的war包上传至指定位置,等待web容器自动扫描及部署。能或者产品有自己的安装脚本,我们在任务中配置好运行安装脚本,就可以自动将产品部署到指定的测试环境中去。

    功能测试(集成测试)

    当部署成功后,真正的功能测试就可以开始了。一般情况下,我们可以独立出一块代码,基于JUnit编写好我们的功能测试代码(JUnit是作为测试的入口以及基本测试框架。如果你的需求比较复杂,那你完全可以将其它三方框架与JUnit集成使用)。功能测试过程和构建过程非常相似,均是依赖Git和Maven去完成:

    1,Jenkins调用Git插件,从Git库上下载最新代码;
    2,Jenkins调用Maven插件,执行Maven命令:mvn clean test。

    区别在于功能测试阶段,Maven只执行到default生成周期的test阶段,不会执行后面的package和install。因为它只需要Maven帮忙运行测试代码即可,它本身没有什么可以构建的。

    P.S.

    如果还需要更复杂的端到端测试的话,可能就需要准备更复杂的部署脚本,或者预先准备好整套端到端测试环境,后面只需要部署好war包即可。但无论怎样,最终原来理还是相同。

    交付

    当新提交代码后构建出来的产品包,通过了各种各样残酷的测试后,就说明这个包是稳定的,能达到基本交付条件的(前提是自动化测试的覆盖率足够高,当然,有一些极端的情况需要人工测试的另说)。那么,我们就可以将这个包放到指定目录作为交付品,供其它测试团队获取并进行进一步的测试,甚至供生产环境部署使用。

    总结

    持续集成作为极限编程中的一个实践,现在已被很多公司使用。但是,使用持续集成,并不是说你得接受极限编程的全部东西。相反,它可以独立开来,与其它实践结合使用。
    持续集成是敏捷开发中快速迭代的重要保证。
    自动化测试是持续集成中重要一环,要真正用好持续集成,就要尽量提高自动化测试的覆盖率。


    以上两种流程A,B都是一些公司常用的模式,大同小异,大家仅供参考。

    引用

    《持续集成是什么?》- 阮一峰的网络日志。 ↩

    《持续集成是什么?》- 阮一峰的网络日志。 ↩

    引用链接:https://www.jianshu.com/p/f92c4112a125

    展开全文
  • 四、使用Jenkins完成项目的持续集成,持续部署 ( 一 ) Jenkins 初始化 ( 二 ) Jenkins配置( Manage Jenkins) ( 三 ) Jenkins持续集成( CI ) 一、Jenkins简介 官网链接:https://jenkins.io/zh/ 用户手册...

    目录

    一、Jenkins简介

    二、其他软件使用及安装配置

    三、Jenkins安装

    四、使用Jenkins完成项目的持续集成,持续部署

    ( 一 ) Jenkins 初始化

    ( 二 ) Jenkins配置( Manage Jenkins )

    ( 三 ) Jenkins持续集成( CI )


     

    一、Jenkins简介

    官网链接:https://jenkins.io/zh/

    用户手册:https://jenkins.io/zh/doc/

    Jenkins下载:https://jenkins.io/download/

    Jenkins 是一款开源 CI&CD 软件,是基于Java开发的一种持续集成工具,用于自动化各种任务,包括构建、测试和部署软件。

    Jenkins 支持各种运行方式,可通过系统包、Docker 或者通过一个独立的 Java 程序。

    二、其他软件使用及安装配置

    1、系统及软件版本使用情况

    名称 版本 安装方法
    操作系统 CentOS 7 ISO镜像安装
    jdk 1.8.0_201 CentOS安装
    maven 3.6.3 CentOS安装
    svn 1.7.14 CentOS安装
    Jenkins docker.io/jenkins/jenkins:lts Docker 安装
    Tomcat 7 Docker 安装

    本次使用的版本控制工具为 svn, Web 应用服务器为 Tomcat 7 , 

    2、jdk 安装

    下载并安装jdk, ( 安装位置视个人情况而定,对应修改JAVA_HOME )

    设置环境变量:JAVA_HOME =  /opt/software/jdk1.8.0_201

    3、maven 安装

    下载并安装maven, ( 安装位置视个人情况而定,对应修改MAVEN_HOME)

    wget http://mirror.bit.edu.cn/apache/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz

    设置环境变量:MAVEN_HOME = /opt/software/apache-maven-3.6.3

    4、设置环境变量的方法为:

    打开编辑profile文件

    vim /etc/profile

    在文件的末尾添加jdk和maven的安装位置

    export MAVEN_HOME =/opt/software/apache-maven-3.6.3                                                        
    export PATH=$PATH:${MAVEN_HOME}/bin
    
    export JAVA_HOME=/opt/software/jdk1.8.0_201
    export PATH=$JAVA_HOME/bin:$PATH
    export CLASSPATH=$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

    结束编辑并保存文件

    :wq

    执行文件

    source /etc/profile

    修改文件后,最好重启Docker.

    5、tomcat的配置与用户的添加

     (1) 修改 server.xml ,添加 URIEncoding="UTF-8", 设置编码集

    <Connector port="8080" protocol="HTTP/1.1"
                   connectionTimeout="20000"
                   redirectPort="8443" URIEncoding="UTF-8"/>

    (2) 修改 tomcat-users.xml, 添加用户

    <role rolename="manager-gui"/>
    <role rolename="manager-script"/>
    <role rolename="manager-jmx"/>
    <role rolename="manager-status"/>
    <user username="dzp" password="dzp" roles="manager-gui,manager-script,manager-jmx,manager-status" / >

    6、svn的安装配置与用户的添加

    (1) 安装svn

    yum install subversion 

    (2) 检查是否安装成功

    svnserve --version

    (3) 创建仓库目录创建名为project的仓库

    svnadmin create /home/svn/project/

     (4) 启动svn服务

    svnserve -d -r /home/svn/project/

    (5) 查看启动服务

    netstat -tnlp |grep 3690

    (6) 进入仓库 conf 设置 svnserve.conf 文件 ( 注意 : 行首不能有空格 ), 如图所示

    anon-access = none
    auth-access = write
    password-db = passwd
    authz-db = authz

    (7) 设置 passwd 文件,添加user, 如图所示

    dzp = dzp

    (8) 设置 authz 文件, 其中 [/] 表示所有权限, 如图所示:

    [groups]
    adminGp = dzp
        
    [/]
    @adminGp = rw
    * = r

    7、 mysql, redis等的安装视项目情况而定,具体安装详见之前的博客:

    https://blog.csdn.net/DZP_dream/article/details/104670943

    三、Jenkins安装

    本次采用Docker安装Jenkins容器的方式

    1、拉取jenkins镜像

    docker pull jenkins/jenkins:lts

    2、查看已经安装的jenkins镜像 

    docker images

    3、查看是否是最新版 

    docker inspect ba607c18aeb7

    4、创建一个jenkins目录 

    mkdir /home/jenkins_home

    5、启动一个jenkins容器 

    docker run -d --restart=always -p 8060:8080 -v /home/jenkins_01:/home/jenkins_01 -v /opt/software/jdk1.8.0_201:/opt/software/jdk1.8.0_201 -v /opt/software/apache-maven-3.6.3:/opt/software/apache-maven-3.6.3 --name jenkins_01 jenkins/jenkins:lts

    6、查看jenkins服务 

    docker ps | grep jenkins

    7、进入容器内部

    docker exec -it jenkins_01 bash

    8、创建并启动成功,在可视化界面出现端口号为8060的jenkins容器

    四、使用Jenkins完成项目的持续集成,持续部署

    ( 一 ) Jenkins 初始化

    1、访问 http://IP地址:8060,跳转至解锁页面

    2、执行以下命令,得到密码并粘贴过去,进行解锁, 并继续

    [root@local ~]# docker exec -it jenkins_01 bash
    jenkins@daa92a050df6:/$ cat /var/jenkins_home/secrets/initialAdminPassword
    008fc9166eca49d0a8da7f6fe06c7cb7
    jenkins@daa92a050df6:/$ 

    3、自定义Jenkins, 插件安装,选择安装推荐的插件,进行安装

    4、安装完成后,进入创建用户界面, 可以使用admin账户继续, 也可以创建用户.

    5、开始使用Jenkins

    ( 二 ) Jenkins配置( Manage Jenkins )

    1、全局安全配置(Configure Global Security)

    为防止忘记用户名密码, 所以勾选 允许用户注册. 勾选 任何用户可以做任何事,点击保存,如图所示:

    2、全局工具配置(Global Tool Configuration)

    Maven 配置, 修改默认 settings 提供和默认全局 settings 提供, 选择文件系统中的settings文件,并输入文件路径:

    /opt/software/apache-maven-3.6.3/conf/settings.xml

    JDK 安装, 进行新增JDK, 取消勾选自动安装, 进行命名, 并输入JAVA_HOME的路径:

    /opt/software/jdk1.8.0_201

    Maven 安装, 进行新增Maven, 取消勾选自动安装, 进行命名, 并输入MAVEN_HOME的路径:

    /opt/software/apache-maven-3.6.3

    修改完成并保存, 如下图所示:

    3、插件管理

    搜索并安装插件:  Deploy to container Plugin 和 Subversion Plug-in 插件

    ( 三 ) Jenkins持续集成( CI )

    1、在Eclipse中创建项目, 并将项目svn初始化导入

    2、在Jenkins中新建任务并进行配置

    (1) 名称与项目同名, 选择自由风格项目, 并创建

    (2) 源码管理

    选择Subversion, 输入Repository URL  ( 注意:路径到项目名 )

    svn://192.168.189.130/svn/project/Pear 

    添加 用户名和密码, 在前边进行选中用户名.操作顺序入下图所示:

    (3) 构建

    选择:调用顶层maven目标

     maven版本选择 : myMaven

    目标 : 进行 clean install

    操作完成后可以手动进行构建.  构建过程中可以点击时间右侧箭头,查看控制台输出.

    首次构建较慢, 下载项目所需jar包等操作. 直至出现Finished: SUCCESS, 说明构建成功. 

    (4) 构建触发器

     触发远程构建 (例如,使用脚本) : DZP_TOKEN

    使用JENKINS_URL/job/apple/build?token=TOKEN_NAME, 拼接后即

        http://192.168.189.130:8060/job/pear/build?token=DZP_TOKEN

    可以在浏览器访问路径, 便可以自动进行构建, 并查看控制台输出.

     访问tomcat 地址:http://192.168.189.130:8090/pear/, 说明成功

    (5) 构建后操作

     选择 : deploy war/ear to a container

    war files : target/Pear-0.0.1-SNAPSHOT.war

    context path : pear (便于通过tomcat访问)

    containers :选择 tomcat7, 并填写之前设置的 用户名 密码

                        url : 填写 tomcat 的地址

    (6) 钩子程序拼接

    Linux 的 curl 命令用来发送HTTP请求:

    -X 参数: 指定请求方式

    -v 参数: 显示响应结果

    -u 参数: 携带用户名/密码

    -H 参数: 携带请求消息头信息

    格式为 : curl -X post -v -u [Jenkins用户名]:[Jenkins密码] -H "请求消息头"  http://[Jenkins服务器地址]:[Jenkins服务器端口号]/job/[Jenkins项目名]/build?token=[身份验证令牌]

    curl -X post -v -u admin:008fc9166eca49d0a8da7f6fe06c7cb7 http://192.168.189.130:8060/job/pear/build?token=DZP_TOKEN

        在命令行中运行以上curl代码, 便可实现自动构建.

    (7) 钩子程序配置

    在svn中仓库下,将/project/hooks下 post-commit.tmpl 进行复制并改名( 注意无后缀名 )

    cd home/svn/project/hooks/
    cp post-commit.tmpl post-commit

    编辑 post-commit 文件, 在文件中添加curl代码.

    修改 post-commit 文件权限.

    chmod 755 post-commit

    钩子程序设置完成.

    (8) 进行项目提交svn, 测试钩子程序

    项目提交svn, Jenkins自动开始构建项目, 访问tomcat服务器地址, 得到最新的提交的页面, 至此Jenkins 持续集成部署完成.

     

    * 具体配置结合项目进行差异化设置.

     

    敬请批评指正.

     

     

     


     

     

    展开全文
  • 持续集成、持续交付、持续部署

    万次阅读 多人点赞 2018-11-27 12:56:23
    持续集成、持续交付、持续部署持续集成持续集成的优势持续交付持续部署DevOps总结参考资料 又到了例行的技术报告环节。想着在实验室里头絮絮叨叨的讲一些前端开发相关的内容,师兄师姐们不爱听,老大也会摆出经典的...
  • 持续集成

    2018-03-07 16:44:06
    持续集成 持续集成的定义:频繁的将代码集成到主干上。 持续集成的优点 快速发现问题:更新完后,集成到主干上,容易快速发现bug定位问题 防止分支branch大幅偏离主干:由于主干不断更新,不经常集成,会导致...
  • 为什么需要持续集成

    千次阅读 2018-06-09 23:31:51
    一、 持续集成的基本概念持续集成(ContinuousIntegration,简称CI),是一种软件开发实践,在实践中指只要代码有变更,就自动运行构建和测试,反馈运行结果。通俗一点来讲,就是绑定项目代码库,自动抓取新的代码...
  • 持续集成相关理论

    千次阅读 2016-10-27 11:41:20
    2、极限编程的概述 2.1.1 极限编程的产生 2001年,为了解决许多公司的软件团队陷入不断增长的过程泥潭,一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则,他们称自己为...
  • 持续集成(Continuous Integration)

    千次阅读 2015-02-07 23:22:56
    持续集成   作者:Martin Fowler 译者:滕云 原文发布时间:2006年5月1日 翻译时间:2012年2月25日 原文链接:http://www.martinfowler.com/articles/continuousIntegration.html (此翻译已获原...
  • 持续集成简介

    2008-01-20 00:44:00
    想起我刚毕业后,进入一家以软件外包为主的外企做开发。它使用传统的瀑布式的软件开发流程,没有使用任何的敏捷实践。我每天上班打开电脑,拿到自己的任务,然后从版本控制更新代码,打开工程按下Build,准备进行...
  • 持续集成、持续交付与持续部署

    千次阅读 2018-06-18 16:30:01
    之前写了一篇戾气很重的文章,抱歉。 好久没有更新了,再次抱歉。 最近在使用Jenkins弄CI,遇到了之前就...顺便安利一篇文章:你的微服务敢于持续交付吗? 本文主要综合了两篇别人的文章: https://www.jianshu.com/...
  • 常用的持续集成工具

    千次阅读 2019-01-16 14:16:00
    2019独角兽企业重金招聘Python工程师标准>>> ...
  • 建立可持续集成系统(Jenkins)

    千次阅读 2016-06-20 17:26:10
    在软件工程实践中,...集成系统:输入指定的软件资产,输出根据软件资产生产出的软件产品以及其他副产品的系统。 对于一般系统而言(以VC开发为例),软件的生产过程包括:源码获取,源码检查,源码编译,测试,部署
  • 持续集成与持续部署系统

    千次阅读 2018-06-08 07:38:51
  • GitHub500lines小项目 框架详细介绍 调试过程中的问题: 一.作者采用从本地的一个git库写代码提交,来产生新的commit ID,用于触发新的build,事实上,每五秒轮询一次查看代码库是否有更新,在使用git add之后...
  • 持续集成(CI)系统

    2020-03-31 14:39:13
    持续集成(CI)系统 gitlab、gerrit、jenkins三大系统整体框架 开发本地从gerrit下载代码进行开发后将代码git push review到Gerrit系统上, Jenkins 在监听 Gerrit 上的项目事件会触发构建任务来测试代码,...
  • 持续集成架构图

    千次阅读 2018-09-30 17:21:59
  • 持续集成工具的选择

    万次阅读 2012-01-04 15:06:12
    1 下面的链接有具体的比较 ... 2转一篇文章: 让开发自动化: 选择持续集成服务器 对开源 CI 服务器:CruiseControl、Luntbuild 和 Continuum 的调查 Paul Duvall, CTO, Stell
  • Jenkins 持续集成综合实战

    万次阅读 多人点赞 2017-01-08 13:59:30
    Jenkins 是一款流行的开源持续集成(Continuous Integration)工具,广泛用于项目开发,具有自动化构建、测试和部署等功能。本文以 CentOS7 环境为例,总结了 Jenkins 的安装与配置、邮件功能使用,并接入阿里巴巴的...
  • 持续集成的好处

    千次阅读 2017-05-18 14:57:37
    持续集成的好处包括下面这些: 1 减少风险  通过每天集成变化的代码并发布,我们将减少项目的风险。这样做将可以推动尽早发现缺陷;尽早估量软件的质量;尽早排除假设。 ----尽早发现缺陷并修复缺陷 软件开发中...

空空如也

1 2 3 4 5 ... 20
收藏数 194,406
精华内容 77,762
关键字:

持续集成