精华内容
下载资源
问答
  • 使用Jenkins和Kubernetes搭建一个可伸缩的持续集成系统教程:Jenkins和它的插件体系、使用Docker启动Jenkins服务、Jenkins Pipelin 2.0和持续集成、基于Dockerd持续交付、基于Kubernetes的可伸缩持续集成。...
  • 基于K8s和docker的Jenkins 可伸缩持续集成系统

    万次阅读 多人点赞 2016-11-25 18:35:49
    Jenkins基于kubernetes可伸缩持续集成 Jenkins基于Docker in Docker jenkins pipeline

    概述

    本文档主要介绍Jenkins的可伸缩部署方式,一种是基于Docker(或者docker-swarm 集群)的部署方式,另外一种是基于kubernetes的部署方式。

    由于基于kubernetes也是基于docker的,都需要用到docker进行通信和中转,因此使用同一的slave镜像将大大节省平台开发与维护成本,因此需要引入jenkins的另一个大插件pipeline。Pipeline也是jenkins 2.0以后的主要方向和升级。

    Jenkins系统基于docker的应用

    jenkins介绍及传统部署遇到的问题

    Jenkins 是开源的一套持续集成框架,可以进行大规模的编译、测试和发布的工作,给软件开发团队带来极大的便利性。

    Jenkins 的持续集成环境可以是集群化的,主要的运行模式为master-slave模式。

    Jenkins 的master为Jenkins系统的控制节点,slave节点负责具体的项目编译测试等工作。

    由于大公司里面需要进行编译的工程或者对象非常庞大,因此需要大量的物理节点作为slave,而且这些环节相对固定,可能很难适应其他项目的编译测试,一旦salve节点遭到破坏,需要人为的进行修复甚至重建,非常麻烦。

    Docker 来解决问题

    Docker的问世,为我们提供了解决方案,使用docker作为jenkins slave节点可以解决slave节点遭到破坏后遇到的问题, 而且大量的工程不是每时每刻同时运行的因此可以在需要时吧docker拉起来进行编译测试,这样就节约了大量的物理节点, 解决了上述问题。

    然而使用docker 同样需要集群,因此要用到集群管理工具, swarm 或者kubernetes。Swarm 一般用在小集群上,而且swarm和docker本身的借口完全一致, 因此这里就简单介绍单点docker节点作为slave。 Kubernetes作为大的docker 集群管理工具,当jenkins的工程数量非常大的时候可以用kubernetes, kubernetes的运维相对比docker 和swarm的门槛要高一点。

    Jenkins master也可以使用docker来运行或者使用kubernetes来提供高可用的jenkins master。本文不对jenkins master的安装和docker运行做过多的说明。


    kubernetes 管理Jenkins slave

    Kubernetes 主要是用来进行docker 调度运行的,同样因为这一点通过kubernetes插件的配置,不需要管slave节点是否在线,因为kubernetes帮你负责创建和连接。这样就可以做到没有任务的时候没有任务slave节点在线,做到完全的按需启动slave和调度slave。

    使用kubernetes 部署管理的jenkins slave如下:


    Jenkins master 的部署

    简单说明 jenkins master的安装与运行

    1)       物理机上的安装

    以centos为例:

    yuminstall –y java java-devel

    由于centos自己的yum源并没有包含jenkins因此需要添加jenkins对应的源

    wget -O /etc/yum.repos.d/jenkins.repohttp://pkg.jenkins-ci.org/redhat-stable/jenkins.repo

    rpm--import http://pkg.jenkins-ci.org/redhat-stable/jenkins-ci.org.key

    yum install –y Jenkins

    修改jenkins 的配置文件 /etc/sysconfig/jenkins

    systemctl enable jenkins.service

    systemctl start jenkins.service

    2)       使用docker来运行

    自己制作镜像或者网上下载jenkins_master的镜像。(我这里是下载的镜像)

    dockerrun –idt –v /home/jenkins:/home/jenkins -v /home/data:/var/jenkins_home  -p8080:8080 -p 50000:50000 jenkins-master

    这样既可。

         https://hub.docker.com/_/jenkins/  可以下载到jenkins master镜像


    Jenkinsmaster配置和插件安装

    jenkins 系统初始化

    这里以jenkins master运行在docker 中为例

    1)        这里每次全新的jenkins初始化的时候都会有一个任意的密码,路径在/var/jenkins_home/secrets/initialAdminPassword,按 照提示解锁jenkins:


    2)   解锁后,系统会根据网络情况提示安装一些插件:



    3)   安装过程如下:


    安装完成后设置系统管理员账户和密码。

    然后登陆即可使用。

    Jenkins Docker 插件安装与kubernetes 插件安装

    1)   插件更新中心配置:

        登陆jenkins-->系统管理-->插件管理-->高级

     

    首先配置涉及站点,默认的是 官方的:http://updates.jenkins-ci.org/update-center.json

    也可以配置日本的或者俄罗斯的 http://mirror.esuni.jp/jenkins/updates/update-center.json

    http://mirror.yandex.ru/mirrors/jenkins/updates/update-center.json

    配置完以后必须点右下角的立即获取

    也可以在可选插件哪个页面的下面点击获取。

     

    2) 安装需要的插件:

    在可选插件页面勾选需要安装的插件,点击直接安装即可。

    例如选择smartjenkins插件:

       

    我们这里需要找的是kubernetes的插件和docker的插件进行安装,如果安装过程中有些插件安装失败,则手动下载插 件然后再高级里面选择上传插件进行安装:

       

    直到安装完成所有需要的插件。

    注:pipeline的插件在一开始初始化的时候安装完成了。


    使用docker运行jenkins slave并连接到master 

    Jenkins master 连接slave 有两种模式,一直是master主动发起连接,主要通过ssh 来进行连接,另外一种是slave 主动连接master,使用的jnlp协议。

    我们使用docker来运行jenkins slave 都可以,但是要做到没有任务在编译测试的时候没有slave在线则只能通过 jnlp来进行连接而去必须使用kubernetes来调度。

    我们这里讨论的是使用单独的或者几个slave长期在线,进行项目的编译测试,都是由master发起连接的。

    https://hub.docker.com/u/jenkinsci/    slave镜像下载地址上


    docker 运行jenkins slave (ssh 模式)

    这种模式docker 运行一个slave 容器跟普通物理机使用完全一致,这里不做说明。

    同样可以再在同一个slave节点(docker 容器)上绑定很多个工程或者任务。

    docker 运行jenkins slave (jnlp 模式)

    Jnlp 模式的则相对应用的比较少,jnlp 是由jenkins slave节点(物理节点,虚机或者容器均可)发起连接的, 会根据配置的jenkins master的url , Jenkins连接的token和jenkins slave name( lable)来进行进行连接。


    举个例子:

    登录jenkins-->系统管理-->节点管理-->新建节点

    那么slave 进行运行连接的时候4个参数是:

    1.        –url

    2.        http://172.25.8.10:9080

    	  3.   54cf091374806d8db7b9cd3977e23d080c955fa6fa33dd6c33dd594aa7b79350
    	  4.   jnlp_test
    	  command as : Jenkins-slave –url http://172.25.8.10:8090 54cf091374806d8db7b9cd3977e23d080c955fa6fa33dd6c33dd594aa7b79350 jnlp_test

    之后的编译跟ssh 模式一模一样

    如何做到方便高效已经保持少量的slave在线

    上面介绍的这两种方式都是使用一个slave进行任务的编译测试,跟传统的部署方式对比仅仅只是增加了编译环境的数 量,但是每个编译环境跟物理机基本一致。


    而且由于docker 环境需要进行调试和连接master,也比较麻烦,作为代码开发者一般只管理工程代码怎样编译,可能 根本不懂jenkins,怎么办?


    大量的jenkins-slave(dokcer)在线jenkinsmaster的管理效率低下,而且可能由于slave(docker)在线,某些任务的编 译资源被挤占,编译效率下降,怎么办?

     

    这些问题的解决办法是使用docker in docker 来处理。

    每个物理节点上长时间的只有一个jenkins-slave(进程或者docker容器都行,最好是容器—无状态,可重新来,降低运 维成本),所有的任务绑定到这几个slave上,每个任务的编译过程是启动自己的容器——下载代码——编译——测试等。


    把编译过程写成脚本:

    docker pull

    docker run

    docker exec *** git clone

    docker exec build

    ***

    那么什么是docker in docker

     

    使用docker in docker 来进行CI 

    Dockerin docker 就是在docker中运行docker, 单实质上是将host的docker.sock 挂载到容器中,然后再容器中创建的容器,其实是运行在host机器上呢。

    使用docker in docker 来进行CI

    Docker in docker其实就是让一个物理机上只有一个jenkins slave在运行,这个jenkinsslave 仅仅只负责任务转发,相当于是一个标准接口, 这样开发人员只需要知道自己的软件需要什么样的docker环境进行编译,而不用关注这个docker 容器怎样跟jenkins master连接。

    这时候 Jenkins slave的运行如下:

    docker run -it -u root -v /var/run/docker.sock:/var/run/docker.sock my_jnlp_test:0.1  -url http://172.25.8.10:9080 54cf091374806d8db7b9cd3977e23d080c955fa6fa33dd6c33dd594aa7b79350 jnlp_test

    项目配置跟原来一样。

    同样带来一些问题,例如 docker 脚本的编写,docker状况的监控,编译构建结果的查看与测试等等。

    Docker 插件和pipeline 插件帮你搞定这些。

    pipeline 来解决docker in docker带来的问题

    Pipeline是jenkins 2.0 的主要升级。其主要是用来定义工作流的,这里结合docker来更好管理docker in docker 的编译。

    同样对于多个依赖关系的任务进行更好的CI 管理,同时其stage view 更直观的反应CI运行的状况。

    Pipeline工程的创建和配置:

    Jenkins-->新建-->需要选择pipeline


    项目配置中仅仅需要配置pipeline部分


    写一段pipeline script 就可以进行构建了

    node('jnlp_test1'){

        stage "Container Prep"

        docker.image('my_docker:0.1').inside{

            stage 'Checkout'

            git url:'http://101.71.10.3:15480/chenmiao/dhcAPI.git'

            stage 'Build'

            sh "mvn clean package"

        }

    }

    Node 用来制定在哪一个slave节点上进行构建

    Stage 用来给任务分段

    这些具体的得看自己学习啦,我这里也是简单的一个例子。

    编译的效果如下:


    比较清晰的显示出每一个阶段用了多长时间,哪个阶段失败了。

    这个到目前为止解决了基于固定的物理服务器,尽可能少的在线编译问题,但不能解决占用冲突—即可能1000个任务中只有20个在线,但这20个在线的任务是同一个物理服务器上的,结果是编译依旧非常低效。

    kubernetes进行按需创建slave

    kubernetes 的引入是为了高效平衡的对docker进行调度,可以有效解决上述的问题。

    Jenkins环境上kubernetes的配置:

    登录Jenkins-->系统管理-->系统设置:

    搜索“云” -->增加一个云-->kubernetes


    然后配置kubernetes:

    这里必配项有:Name、Kubernetes URL、kubernetesNamespace、 Jenkins URL 以及 Kubernetes Pod Template(大项,这一项最少需要一个,否则不能使用kubernetes)


    再来配置jenkins-slave 对应的docker的信息,由于kubernetes是报docker封装成Pod来管理,即配置kubernetes Pod Template:


    这里需要名却的是第一处的Name  就是子啊项目配置时的slave节点,label 是kubernetes进行管理用的。其余的配置项为slave容器需要的配置。

    Jenkins ci工程的配置

    Pipeline Test1 for example:


    这里只需要指定node为kubernetes Pod配置的哪个名字即可。

    自由风格的工程配置一样:


    这样既可以在对应的docker 里面进行项目CI。

    在没有任务运行的时候,系统上是没有slave的:


    Kubernetes get pod的结果也一样没有jnlp-slave的Pod

    root@debian:/home/Daniel/jnlp_slave# kubectl -s 172.25.5.150:8080 get pod --all-namespaces -o wide

    NAMESPACE     NAME                                   READY     STATUS    RESTARTS   AGE       NODE

    default       kube-apiserver-172.25.5.150            1/1       Running   3          14d       172.25.5.150

    default       kube-controller-manager-172.25.5.150   1/1       Running   0          14d       172.25.5.150

    default       kube-scheduler-172.25.5.150            1/1       Running   0          14d       172.25.5.150

    kube-system   kube-ui-v1-1dn43                       1/1       Running   0          10d       172.25.5.155

    运行任务时:


    Kubernetes got pod 中有jnlp-slave 的pod

    root@debian:/home/Daniel/jnlp_slave# kubectl -s 172.25.5.150:8080 get pod --all-namespaces -o wide

    NAMESPACE     NAME                                   READY     STATUS    RESTARTS   AGE       NODE

    default       kube-apiserver-172.25.5.150            1/1       Running   3          14d       172.25.5.150

    default       kube-controller-manager-172.25.5.150   1/1       Running   0          14d       172.25.5.150

    default       kube-scheduler-172.25.5.150            1/1       Running   0          14d       172.25.5.150

    jenkins       jnlp-slave-4eeed2fbc128e               0/1       Running   0          3s        172.25.5.155

    kube-system   kube-ui-v1-1dn43                       1/1       Running   0          10d       172.25.5.155

    问题记录

    1. 我们使用的kubernetes版本不支持Pod name 和lable中使用下划线,因此前期Pod一直创建不成功。

    2. Kubernetes Pod template 中Container的配置项 Commandto run slave agent 以及Arguments topass to the command配置一直有错误:Command 最好使用全路径, Arguments 最好用括号


    3. Jenkins master 和jenkins slave 运行的时候需要挂载卷,这些卷如果是host上的目录需要将其的所有者改为jenkins 里面运行的用户,而且容器里面的卷也需要修改其所有者。

    chown Jenkins:Jenkins/home/Jenkins   为例

    4. Jenkins maste 和jenkins slav镜像需要进行定制,网上下载的镜像仅保证最简单的连接。



    展开全文
  • 建立可持续集成系统(Jenkins)

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

    在软件工程实践中,需要将开发完成的最终产品交付给用户(或发布给测试部门),就需要我们将源代码编译为可执行文件。将各个分别开发的模块集合为一个完整的系统,这个过程成为系统集成,我们用一个系统来描述这个集成过程。

    集成系统:输入指定的软件资产,输出根据软件资产生产出的软件产品以及其他副产品的系统。

    对于一般系统而言(以VC开发为例),软件的生产过程包括:源码获取,源码检查,源码编译,测试,部署。经历以上几个过程之后得到一个可用的系统。

    故一般而言集成系统通常会按照顺序经历以下几个模块组成:

    1. 版本检查:用于获取代码和其他必要的文件。

    2. 源码检查:对于源代码的静态分析,检查可能存在的错误。

    3. 源码编译:通过编译器和连接器编译源文件,生产可执行文件或库。

    4. 测试:通过对编译出来的文件进行一定测试,并获得测试结果。

    5. 部署:若测试通过则文件可以作为最终得到的产物用于交付。


    在实践过程中软件的最终集成会存在各种各样的问题而导致集成失败,需要大量的修改和测试,而得到最终可以的交付的产品。故每次版本发布时的加班不可避免,而交付的延期也时常发生,软件的质量不可保证。为了解决这些问题或者说减少修复这些问题所需要付出的成本,我们尽量让这些问题提早发生(问题越早发生修复的代价越小)。因此我们可以以一定频率对工程的更改进行集成,若集成失败则尽早修复,以保证能够得到可交付的产品,这样的实践称为持续集成。

    我们可以将系统集成的工作交由项目经理负责,让项目经理定期集成系统并发布版本,我们称之为人肉集成系统:

    1. 版本检查:SVN或者Git工具能够check out出代码的工具都可以。

    2. 源码检查:使用beyondcompare等工具对比原有版本,通过codereview的方式用肉眼对代码进行检查,好坏全凭项目经理的经验。

    3. 源码编译:VS工程的生成功能,将源代码编译,连接,生成可执行文件或库。

    4. 测试:跑完单元测试,对文件的功能进行测试,或检查是否功能完备或者bug是否已经得到修复。

    5. 部署:将生成的文件打包交付。


    人肉集成系统处理了集成最大的问题,通过项目经理以一定频率反复执行以上过程保证交付。但是项目经理的精力完全被消耗在这个重复劳动的过程中,而且质量保证完全取决于项目经理的经验和能力,并且不能量化结果对于决策的支持有限。以上几个模块会被按顺序重复执行,若有一定的工具可以自动完成以上模块的各个功能则可以将项目经理从繁复的重复劳动中解脱出来,大大的节省项目成本。故我们需要构建一个自动持续集成系统来取代人肉集成系统,感谢开源工具让我们能够使用自动化的工具完成以上各个模块的功能,并通过CI工具反复执行,自动集成系统同样包含一下模块:

    1. 版本检查:SVN或者Git工具能够check out出代码的工具都可以。

    2. 源码检查:使用cpplint检查代码规范,使用cppcheck静态检查代码缺陷,使用cppncss或SourceMonitor分析代码复杂度。

    3. 源码编译:通过命令行调用VS工程的生成功能,将源代码编译,连接,生成可执行文件或库。

    4. 测试:执行gtest和gmock进行单元测试和回归测试,通过opencppcoverage来检查代码覆盖率。

    5. 部署:将生成的文件打包交付。

    我们使用jenkins作为CI工具,来完成持续集成的各个模块的管理(jenkins的插件能够帮助我们完成以上工作)。


    我们在windows7下构建CI服务器,并使用vs2013作为开发环境来完成一个CITest的持续构建活动。接下来使用CITest的编码来模拟日常的开发工作,并从开发人员与项目经理两个角色参与CI系统的搭建。

    1. 使用VS2013新建C++工程CITest,并编写一些代码用于测试。


    2. 选择代码仓库,Git不是很熟悉一直用subversion,而且资源有限并不想多架设一条svn的服务器而且作为一个test项目代码需要的空间有限,故选用免费的代码托管服务器(taocode),以此svn地址作为上传下载代码的地址,上传CITest工程代码和工程文件。



    3. 将静态代码检查工具集成到VS上

    推荐google的c++代码规范 (注释风格参考doxygen的格式,使用代码风格检查工具cpplint:

    先安装python2.7,下载cpplint.py到目录C:\cpplint,打开vs,工具菜单,选择外部工具将cpplint添加进去,再通过工具.选项.键盘为cpplint分配快捷键


    添加代码段保持注释的风格一致,工具代码段管理器,导入代码段定义文件,并在工具.选项.文本编辑器.c++.制表符中见制表符替换为两个空格:



    安装完成后运行一次,修复报告的所有问题



    再将静态分析工具cppcheck集成到vs上,与cpplint一样为cppcheck添加快捷键:



    修改代码以使得通过检验。

    使用SourceMonitor测量代码复杂度:



    4. 用命令行编译VS工程

    基于后期使用jenkins持续集成系统的考虑,这里使用ant,调用devenv命令来编译解决方案。

    先安装ant,并配置环境变量,再配置devenv的环境变量,编写bulid.xml放到工程的根目录下,并作为项目资产加入svn,在工程目录下运行ant。


    5. 为工程添加单元测试

    感谢google提供的两个工具,使得完成单元测试的工作变得简单。在实际开发中需要采用测试驱动开发的实践:

    我们下载gtest和gmock两个工具,然后根据被测试代码所在工程的运行库选项并编译他们:


    创建一个空的工程用于单元测试,并将上一步生存的lib文件和头文件拷贝到单元测试工程目录下:


    在工程文件中增加一个用于单元测试的配置,定义输出为lib文件,在单元测试的工程中包含他们,编写测试代码:




    测试代码的编写参考网上的资料:主要有玩转google开元c++单元测试系统和GMockForDummies,cheat sheet,cookbook这几份资料。

    在ant的bulid.xml文件中添加target,实现自动化


    6.安装并使用opencppcoverage开查看测试代码的覆盖率


    以上在开发端的设置全部完成,或者还有其他的需要补充的工具可以视具体项目再决定如何补充和添加。

    接下来使用jenkins来搭建CI服务器,在客户端完成私有构建后将代码提交到svn上,CI服务器将执行以上所有的构建和测试动作,并将结果反馈给相关人员,构建失败应当是优先级最高的处理事件(在错误的基础上做的再多也是白费功夫)。

    1.安装Jenkins和需要的插件

    2.创建一个自由风格的项目,填写基本信息





    2.定义构建动作并解析构建结果(使用以上与客户端相同的工具,并将构建结果解析出来)

    cpplint(此处lint.py遍历当前目录,检查所有.h和.cpp文件,并将结果输出到xml文件中):



    cppcheck:



    SourceMonitor:



    Ant(需要根目录下的build.xml文件支持)


    opencppcoverage(在build.xml文件中去掉执行单元测试的部分内容,在此同时输出两个文件)




    最后在配置邮件通知:


    至此CI系统配置完成,返回上一级,点击立即构建(上边每一步每添加一个功能构建一次,直到这些功能配置完成):




    展开全文
  • 正忙于工作,却被打断要给市场部门打个包? 测试部门要求每天有新的版本,可以验证bug?...持续集成(continue intergration,简称CI)系统,就是一个可以定时从源代码管理系统下载代码,调用编译器编

    正忙于工作,却被打断要给市场部门打个包?

    测试部门要求每天有新的版本,可以验证bug?

    策划要求每天有新的版本,可以跟进审查?

    每次集成版本,总担心合并带来问题,要把主要模块手动跑个遍?

    如果你遇到这些情况,还不得不手动打包,人工测试,那这篇文章正适合你。


    持续集成(continue intergration,简称CI)系统,就是一个可以定时从源代码管理系统下载代码,调用编译器编译链接,调用测试工具测试,部署产物,并通知相关人员的自动化系统。

    它的本质只是一个定时器,时机一到,就调用设置好的动作。

    它需要跟其他各种系统打交道(代码管理、编译、测试等),是一个调度者。

    它的实现可以很简单,比如使用windows的任务计划工具、unix的cron这些定时服务,定期调用一些脚本即可。

    更方便的做法,是直接使用一些持续集成工具,简化脚本的编写。使用者往往只需要填写一下集成的周期,项目的SVN地址,项目工程文件的路径,测试文件的路径,产物的路径,通知者的email地址等,就可以让一套系统建立起来。

    比较常用的持续集成工具,有Jenkins、Hudson、TeamCity等。

    这里介绍下使用Jenkins,对一个cocos2dx手机网游的持续集成实践。


    项目目前支持3个平台,windows、android、iOS,希望可以每日构建出这三个平台的版本。策划、测试人员也可以按需要随时构建版本

    版本采用网页下载的形式提供给项目组成员

    项目构建成功时,发送邮件给策划、测试;构建失败时,发送邮件给开发

    版本构建成功并不只是编译通过,还希望跑一些集成测试,自动测试通过后,才认为版本构建成功


    1.持续集成CI服务器的安装

    Jenkins在各系统下的安装配置,网上的资料很多,这里就不再赘述了

    因为要构建windows和iOS版本,因此在一台windows笔记本和一台mac air上各自安装了对应的Jenkins版本


    2.Windows版本的构建

    安装msbuild插件,使用这个插件,只要填入项目sln文件路径即可完成windows版本的编译工作


    3.构建产物发布与邮件通知

    目前我们使用批处理脚本,将exe和资源打包成zip文件的方式生成windows版产物

    使用Jenkins的artifacts功能,在网页上提供产物的链接

    使用Jenkins的Email Notification功能,当构建不成功时,发送邮件给开发人员

    使用Email-Ext插件,当构建成功时,发送邮件给产品人员


    4.android版本的构建

    首先使用ant,完成apk的批处理生成、打包功能(网上资料很多)

    在Jenkins里使用批处理脚本,构建并发布android版本产物


    5.ios版本的构建

    在mac上的jenkins安装xcode插件,类似msbuild插件,原则上填入项目文件路径即可完成编译链接工作,但因为需要使用keychain签名,遇到了一些麻烦。

    mac上的jenkins,会在os x上新建一个jenkins用户,并使用这个用户的keychain进行签名

    目前采取的方式,从之前成功签名的用户keychain里,导出证书、私钥对给jenkins用户的keychain;将可用账户的provision profile拷贝到jenkins用户的Library/MobileDevice目录下。做完这些,就签名成功了。

    目前使用两个jenkins主机,提供多个版本的构建。其实jenkins提供master/slave模式,只需要在master上安装jenkins,并添加slave节点,即可以进行分布式编译。


    6.游戏的自动化测试

    使用CI,自动构建部署只是第一步;在构建过程中,运用自动化的手段,对产物进行测试,对代码进行检查,才能最大化的发挥持续构建的威力。

    项目主要使用lua开发,选择了luaunit作为测试框架,输出xml测试报告。在jenkins中指定测试报告的目录路径,就可以自动在测试失败时通知开发人员了。

    目前的手游项目,只编写了一些简单的集成测试脚本。在脚本中对游戏的主要界面进行跳转,并在脚本中检查跳转是否成功;在脚本中调用一些功能函数,检查执行过程中是否产生异常。

    这种测试方式,要求使用构建好的客户端产物作为测试主体,使用特殊的测试方式跑游戏。


    7.总结

    使用Jenkins搭建一个CI系统并不是一件很困难的事情,相比它带来的好处,很值得进行尝试。


    展开全文
  • 持续交付之三——持续集成

    千次阅读 2016-05-08 08:45:34
    2.2. 一个基本的持续集成系统开发人员使用持续集成服务的简单流程 查看一下是否有构建正在运行,如果有的话,等它完事,如果它失败了,就和团队的其他人把他一起修复,然后再提交代码 一旦构建完成且测试完全通过,...

    其他持续交付相关文章:《持续交付》系列文章目录

    公众号,欢迎关注
    在这里插入图片描述

    第三章 持续集成

    1. 引言

    持续集成的目标是让软件一直处于可工作的状态

    2. 实现持续集成

    2.1. 准备工作

    1. 版本控制
    2. 自动化构建
    3. 团队共识

    2.2. 一个基本的持续集成系统

    开发人员使用持续集成服务的简单流程

    1. 查看一下是否有构建正在运行,如果有的话,等它完事,如果它失败了,就和团队的其他人把他一起修复,然后再提交代码
    2. 一旦构建完成且测试完全通过,就从版本控制库中将该版本的代码更新到自己的开发环境上
    3. 在自己的开发机上执行构建脚本,运行测试,以确保在你机器上的所有代码都正常工作
    4. 如果本地构建成功,你提交代码
    5. 然后等待你这次提交的构建结果
    6. 如果失败了,停下手中的活,修复问题,转到步骤3
    7. 如果成功,庆祝一下,开始下个任务吧

    3. 持续集成的前提条件

    3.1. 频繁提交

    3.2. 全面的自动话测试套件

    单元测试,集成测试,验收测试

    3.3. 保持较短的构建和测试过程

    频繁的执行不能占据太长时间

    3.4. 管理开发工作区

    开发人员开始新任务的时候,应该总是从一个已知正确的状态开始

    4. 使用持续集成软件

    Jenkins,CruiseControl,Go,TeamCity等

    5. 必不可少的实践

    5.1. 构建失败之后不要提交新代码

    5.2. 提交前在本地运行所有的提交测试,或者让持续集成服务器完成此事

    5.3. 等提交测试通过之后再继续工作

    5.4. 回家之前,构建必须处于成功状态

    如果你不想第二天被同事骂的话

    5.5. 时刻准备着回滚到前一个版本

    按照持续继承的流程,前一个版本肯定是没有问题的

    5.6. 在回滚之前规定一个修复时间

    比如说10分钟没有修复问题,就回滚

    5.7. 不要将失败的测试注释掉

    要么测试错了,要么改出问题了,,要么测试可以删除了,酌情处理,而不是注释掉

    5.8. 为自己的导致的问题负责

    5.9. 测试驱动开发

    6. 推荐的实践

    我们任务下面的实践也是有用的

    • 若违背架构原则,就让构建失败
    • 若测试运行变慢,就让构建失败
    • 若有编译警告或者代码风格问题,就让测试失败

    8. 小结

    持续集成是部署流水线的基石,即使只采用了持续集成,也会对开发流程带来极大的改善

    展开全文
  • 持续集成(CI)系统

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

    千次阅读 2012-07-30 22:16:15
    就像一门优秀语言的出现会影响一个软件开发人员职业生涯的...目前的淘宝、腾讯、百度在介绍他们的敏捷开发时,无一不对持续集成系统进行了重点阐述。持续集成到底是什么,有着怎样的魅力,能让这么多成功的互联网公司如
  • 持续集成

    2018-06-05 22:52:31
    持续集成概述1、持续集成介绍2、持续集成管理平台的组成3、持续集成实践介绍4、持续集成篇的课程内容持续集成介绍持续集成是一种软件开发实践团队开发成员经常集成他们的工作,每次集成都通过自动化的构建(包括自动...
  • 持续集成、持续交付、持续部署

    千次阅读 2019-08-19 17:19:23
    持续集成持续集成持续集成好处持续集成流程使用 GitLab 持续集成Gitlab Runner持续交付持续交付概念持续部署持续部署 持续集成 持续集成好处 持续集成指的是, 频繁的将代码集成到主干。 好处: 1. 快速发现错误 。...
  • Jenkins+maven持续集成

    万次阅读 2021-02-24 09:33:50
    Jenkins+maven持续集成环境安装Jenkins下载依赖导入密钥安装配置jdk保存后 重新加载一下服务启动Jenkins查看运行状态开通Jenkins默认端口8080浏览器访问配置Jenkins解锁Jenkins安装插件下载插件下载源码插件 ...
  • 12.1 持续集成的作用、过程和优势  简单的说,持续集成就是快速且高频率地自动构件项目的所有源码,并为项目成员提供丰富的反馈信息。 --快速:集成的速度要尽可能的快,开发人员不希望自己的代码提交半天后才得到...
  • 最近又重新部署了jenkins持续集成系统,看到之前整理的文章不够详细,于是重新整理了docker下使用jenkins的容器进行持续集成的相关文章,拿来分享下
  • 软件开发过程中,开发成员经常需要把自己工作集成到项目中,通常每个成员每天至少集成一次。如果项目较小,对外部的依赖较...因此一个有效的持续集成系统越来越重要。       个推平台是一个极其复杂的分布式
  • 京东持续集成实践

    万次阅读 2018-10-18 22:46:47
     京东持续集成实践 1、持续集成简介 2、持续集成实践 3、集成环境的部署及自动化测试 3.1、搭建J-auto系统 3.2、J-auto系统使用 4、持续集成数据分析   1、持续集成简介  持续集成不仅仅是一项项目实践...
  • 切记,授权策略要先选择“登录用户可以做任何事”,因为现在还...然后使用刚才注册的用户登录,”系统管理—>Configure Global Security”到安全管理界面 将刚才的授权策略改为“安全矩阵”,在这个矩阵里,可
  • 持续集成之Jenkins+Gitlab实现持续集成 [二]标签(空格分隔): Jenkins项目:使用git+jenkins实现持续集成开始构建 General 源码管理 我们安装的是git插件,还可以安装svn插件 我们将git路径存在这里还需要权限...
  • 持续集成 之 Jenkins

    万次阅读 2015-09-23 17:45:17
    持续集成 之 Jenkins
  • 一、持续集成是什么? 持续集成是一种软件开发的实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化...
  • 我们常看到许多团队和开发者分享他们的持续集成实践经验,本期 fir.im Weekly 收集了 iOS,Android,PHP ,NodeJS 等项目搭建持续集成的实践,以及一些国内外公司的内部持续集成系统的经验,供大家集中研究,参考...
  • 请问安装好tomcat和jenkins后,新建job 构建,生成的workspace不在jobs下,为什么呢,找不到原因,求大神们帮忙
  • Jenkins简介Jenkins 是一个开源项目,提供了一种易于使用的持续集成系统,使开发者从繁杂的集成中解脱出来,专注于更为重要的业务逻辑实现上。同时 Jenkins 能实施监控集成中存在的错误,提供详细
  • 持续集成进阶篇

    千次阅读 2016-12-19 23:17:04
    在前一篇文章持续集成入门篇中我大概介绍了下持续集成的概念及工具(抱歉,在前一篇文章中我查的资料不够与时俱进,工具介绍的都比较老,目前流行的工具应该就属Jenkins和Travis CI 了)。这篇文章我将就持续集成的...
  • 持续集成 」实践教程合集

    千次阅读 2016-09-06 10:00:08
    我们常看到许多团队和开发者分享他们的持续集成实践经验,本期 fir.im Weekly 收集了 iOS,Android,PHP ,NodeJS 等项目搭建持续集成的实践,以及一些国内外公司的内部持续集成系统的经验,供大家集中研究,参考...
  • 持续集成hudson

    2011-10-15 12:49:14
    极限编程中一项建议实践便是持续集成持续集成是指在开发阶段,对项目进行持续性自动化编译、测试,以达到控制代码质量的手段。  持续集成提供了及时发现问题、追踪问题、修复问题的机制,他替代了传统的在所有...
  • Hudson 持续集成

    千次阅读 2018-06-06 17:55:22
    Hudson 持续集成概述IP:192.168.4.221 8G 内存(Hudson 多个工程在同时构建的情况下比较耗内存) 环境:CentOS 6.6、JDK7 Hudson 不需要用到数据库Hudson 只是一个持续集成服务器(持续集成工具),要想搭建一套完整...
  • AliOS Things 持续集成(CI)系统介绍

    千次阅读 2018-01-26 15:17:25
    同时物联网硬件碎片化,资源紧张,对持续集成(CI)系统也提出了特殊的要求。本文介绍AliOS Things的CI系统的实现方式及思考。点此查看原文:http://click.aliyun.com/m/41052/背景简介AliOS Things 是一款由阿里...
  • 正如你在上图中看到,「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」有着不同的软件自动化交付周期。 持续集成 持续集成是指软件个人研发.....
  • 为什么要持续集成与持续部署

    千次阅读 2019-07-05 18:04:00
    DevOps、持续集成、持续交付、持续部署、敏捷等词语大家应该都耳熟能详了,说到底就是快速交付价值,从工程上、管理上、组织上、工具上来提高效率,打造可靠的、快速的产品(项目)交付过程。本书将围绕项目管理、...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 174,795
精华内容 69,918
关键字:

持续集成系统