持续集成1---初步

1.Jenkins是什么

  • Jenkins是一个可扩展的持续集成工具。简单就说就是,让项目的代码签出、编译、部署等构建过程自动化完成,并支持周期性自动构建

2.准备工作

  • 首先准备好编译和部署、自动化测试需要用到的脚本,例如ant的build.xml

3.Jenkins负责什么

  • Jenkins负责周期性的代码签出、并调用编译部署及自动化测试的脚本,在这个过程中发生任何错误,都可以及时的通过多种方式通知到相关负责人构建失败,例如以邮件的形式告知项目负责人以及提交问题代码的开发人员。

4.下面是Jenkins配置流程

  • 首先将jenkins.war扔到tomcat下并启动,访问10.1.100.10/jenkins,进入系统管理

  • 先进行系统设置

  • 设置JAVA_HOME和ANT_HOME

  • 设置系统管理员邮件地址

  • 设置邮件参数并测试,注意如果想要测试成功,填写的用户名必须与上面的管理员邮件地址相同,设置完成后,保存

  • 接下来创建一个jenkins账号。回到系统管理,点击Configure Global Security

  • 启用用户注册功能

  • 点击注册,注册部分略

  • 再次进入Configure Global Security,更改授权策略,这样就只有刚才建立的用户有所有权限

  • 回到系统设置,默认的邮件插件只能发送邮件给一个人,我们想发送给更多人,需要再安装一个邮件插件,点击管理插件

  • 输入Email Ext Recipients Column Plugin,并安装

  • 新建一个build项目

  • 源码管理部分选择svn地址后会报错如下,点击enter credential,设置账号密码即可。

  • 触发设置,共有4种触发情况
  • 这里说一下第三种和第四种触发情况

    Build periodically   周期性构建

    Poll SCM   根据SVN等代码同步工具的版本号进行周期性创建,也就是说,版本无改变不构建

  • 为了更容易看到效果,这里选择Build periodically
  • 5 * * * * 的含义是每5分钟执行一次

    (分钟  小时  天 月 年)

    前面的H/代表一个随机的秒,Jenkins更推荐H/这样的写法

  • 下面填写构建的shell脚本(根据项目本身依赖关系、环境等进行编译、部署等操作的脚本)

  • 接下来进行构建后操作配置,这里我们只进行邮件配置,选择Editable Email Notification
  • “cc:”代表抄送,多个邮件用逗号隔开

  • Trigger可以设置选择在何时发送邮件,默认是构建失败发送邮件,设置Trigger需点击Advanced Settings按钮
  • 也可设置追加发送邮件给对构建有影响的提交者,即"犯过错者" ,设置选项为Culprits,此时该邮件会发给上次构建时提交代码发生错误的人员,插件会基于提交者的ID和追加Jenkins配置页面的(default email suffix)默认邮件后缀来生成一个邮件地址。譬如,上次提交代码的人是”first.last”, 默认的电子邮件后缀为“@somewhere.com”,那么电子邮件将被发送到“first.last@
    somewhere.com”。

保存。项目的持续集成构建完毕。

如果有自动化测试的脚本文件,也由Jenkins来调用,即可实现签出、编译、部署、测试的自动化完成,并且在这个过程中有任何问题,按照如上的配置,将发送邮件给Project Recipient  List中的地址以及提交错误代码的人。

参考文档

http://jenkins-ci.org/

http://www.cppblog.com/fwxjj/archive/2012/10/04/192809.html

时间: 2024-10-25 01:18:33

持续集成1---初步的相关文章

基于 Jenkins 快速搭建持续集成环境

持续集成是一种软件开发实践,对于提高软件开发效率并保障软件开发质量提供了理论基础.Jenkins 是一个开源软件项目,旨在提供一个开放易用的软件平台,使持续集成变成可能.本文正是从持续集成的基本概念入手,通过具体实例,介绍了如何基于 Jenkins 快速搭建持续集成环境. 持续集成概述 什么是持续集成 随着软件开发复杂度的不断提高,团队开发成员间如何更好地协同工作以确保软件开发的质量已经慢慢成为开发过程中不可回避的问题.尤其是近些年来,敏捷(Agile) 在软件工程领域越来越红火,如何能再不断变

为什么我们迫切需要持续集成(Continuous Integration)

原文同步至 https://waylau.com/why-we-need-continuous-integration/ 持续集成(Continuous Integration),也就是我们经常说的 CI,是现代软件开发技术的基础.本文论述了当前软件开发过程中存在的问题,讲解了持续集成.持续集成服务器的概念,最终探讨了为什么我们需要持续集成来解决这些问题. 当前软件开发过程存在的问题 在没有应用持续集成之前,传统的开发模式是这样的: 项目一开始是先划分好模块,分配模块给相应的开发人员: 开发人员

Jenkins持续集成实战总结

原文:https://my.oschina.net/CandyDesire/blog/341331#comment-list 持续集成 什么是持续集成 随着软件开发复杂度的不断提高,团队开发成员间如何更好地协同工作以确保软件开发的质量已经慢慢成为开发过程中不可回避的问题.尤其是近些年来,敏捷(Agile) 在软件工程领域越来越红火,如何能再不断变化的需求中快速适应和保证软件的质量也显得尤其的重要. 持续集成正是针对这一类问题的一种软件开发实践.它倡导团队开发成员必须经常集成他们的工作,甚至每天都

Jenkins 快速搭建持续集成环境

持续集成概述 什么是持续集成 随着软件开发复杂度的不断提高,团队开发成员间如何更好地协同工作以确保软件开发的质量已经慢慢成为开发过程中不可回避的问题.尤其是近些年来,敏捷(Agile) 在软件工程领域越来越红火,如何能再不断变化的需求中快速适应和保证软件的质量也显得尤其的重要. 持续集成正是针对这一类问题的一种软件开发实践.它倡导团队开发成员必须经常集成他们的工作,甚至每天都可能发生多次集成.而每次的集成都是通过自动化的构建来验证,包括自动编译.发布和测试,从而尽快地发现集成错误,让团队能够更快

基于Jenkins的开发测试全流程持续集成实践

今年一直在公司实践CI,本文将近半年来的一些实践总结一下,可能不太完善或优美,但的确初步解决了我目前所在项目组的一些痛点.当然这仅是一家之言也不够完整,后续还会深入实践和引入Kubernetes进行容器编排,以及通过阿里云K8S服务进行高效的云上托管,希望对各位童鞋有一点用. 一.持续集成全流程介绍 今年一直在开发我司的一个核心业务系统,一个还未上线的产品开发阶段,其中后端采用ASP.NET Core + 一系列开源组件开发微服务并且部署在Linux Docker中,前端采用React + Fl

Jenkins Gitlab持续集成打包平台搭建

相关概念 Jenkins Jenkins,一个用Java编写的开源的持续集成工具,提供了软件开发的持续集成服务,可监控并触发持续重复的工作,具有开源,支持多平台和插件扩展,安装简单,界面化管理等特点.更多介绍参考[维基](https://en.wikipedia.org/wiki/Jenkins_(software)介绍. Gitlab GitLab是一个利用Ruby on Rails开发的开源应用程序,实现一个自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目,更多介绍参考维基

持续集成(二)工具搭建篇—内网邮件服务器搭建

在我们的持续构建中,项目构建中出现错误提醒,或者开发人员之间的沟通交流,进度汇报的事务,都是离不开一个通信工具,那就是邮件.在我们的项目开发中如果使用第三方的邮件平台,这肯定不是最好的选择,因为第三方的邮件需要外网的支持,但是外网又不是特别的可靠,假如外网链接出现了问题,这样就会不必要的延误我们的工期.再或者很多项目都是保密项目,在开发中只能用内网.但是不用邮件吧又不行.为了解决这个头疼的问题,我们的内网邮件服务器工具就出现了,只要用它安装在我们的服务器上,配置好账户,配置好客户端,在内网里就可

持续集成环境搭建

Jenkins - 持续集成环境搭建 1. Jenkins 概述 Jenkins是一个开源的持续集成工具.持续集成主要功能是进行自动化的构建.自动化构建包括自动编译.发布和测试,从而尽快地发现集成错误,让团队能够更快的开发内聚的软件. 2. Jenkins功能 主要功能: l 代码库(svn/git等)代码发生变化后更新代码至jenkins工作目录 l 代码变化后启动编译或设置定时编译 l 输出编译结果,包括生成的目标文件 l 邮件通知构建结果 3. Jenkins构建过程 1. 向代码库提交代

Jenkins持续集成——安装配置

近期公司准备将原先使用的持续集成工具由Hudson替换成Jenkins,专门研究了一番,现在已有些许成果,准备作为一个专题记录下来. 由于公司已有Hudson,也可以正常用于构建发布,如果只是简单的复制过来就显得太没水平了.首先我在原先完成构建的基础上添加了一步发布完成后自动触发检测发布是否成功的简单验证并将检测结果通过邮件发送给执行构建的人员.当然作为运维能力有限,该验证只能检测tomcat是否启动正常,而业务层面是否正常需要测试人员进一步测试,不在我的研究范围. 最终实现效果如下: 一.三种

持续集成

持续集成实践 只维护一个源码仓库 自动化 build 让你的build自行测试 每人每天都要向mainline提交代码 每次提交都应在集成计算机上重新构建 mainline 保持快速 build 在模拟生产环境中进行测试 让每个人都能轻易获得最新的可执行文件 每个人都能看到进度 自动化部署 http://article.yeeyan.org/view/2251/94882