Jenkin-持续集成

1、Jenkins安装

  本文将会介绍如何在windows 中安装Jenkins,并且使用Jenkins进行项目的构建。

  首先我们进入到Jenkins 的官网下载地址:https://jenkins.io/download/

  在下图中,我们可以选择相应的Jenkins 版本,本次教程将会在windows 中进行演示,因此我们此处下载windows版的安装包。

  下载完后,解压出windows 的安装包:

 

    除了使用安装包以外,Jenkins 还提供了使用war包进行服务启动,这种模式比安装包更为方便,并且在各个平台中也适应。

    使用war进行启动服务,需要在从Jenkins官方网站https://jenkins.io/下载最新的war包,然后再目录下执行:

java -jar jenkins.war

2、Jenkins基本配置

  在上述的一通安装操作后,系统完成Jenkins 的安装后会自动启动Jenkins 服务,Jenkins 的默认端口为8080,因此在安装的同时,需要先将占用8080端口的服务先行关闭,避免在安装的时候出现异常。

  Jenkins 安装完成后,进入都首页,会提示我们进行账号密码的设置,如下:

    我们需要在系统提示的目录下找到对应的密码,进行校验。

    在校验完后,会让你选择相应的插件,我们这里选择默认的插件,然后进行安装:

    在系统安装好相应的插件后,我们需要进行用户创建:

    在完成用户的注册后,即可以开始使用Jenkins 服务。

3、部署Git 项目

    在创建项目前,我们需要先管理一下插件,优于部署的项目是基于Maven进行依赖管理的,而Jenkins默认是没有帮我们安装Maven 插件,因此 我们需要手动添加Maven插件:

      在可选插件中,我们找到一下这个插件:

      

      安装完插件后,我们即可以开始一个新的Maven项目,我们为这个项目命名,然后选择构建一个Maven项目,进入到项目的配置。

    

  在源码管理模块,我们可以将线上的代码仓库地址输入进去,在这里我输入的是我的一个开源项目:https://github.com/jaycekon/Crawl-Page.git

    

  在触发器这一栏,我们可以设置Jenkins的自动打包时间约束,在日程表中,我们输入的是 */3 * * * * 每三分钟执行一次

   最后,在build 中,输入我们在项目编译时需要执行的Maven 命令,然后选择保存。

   

时间: 2024-11-04 09:23:08

Jenkin-持续集成的相关文章

关于云与持续集成杂谈

在网上看到了一款号称云时代的操作系统:数人云,简单看了一下其产品Demo:https://dashboard.shurenyun.com/cluster/listclusters ,瞬间觉得很眼熟,有种似曾相识的感觉,原来和我2012~2013年时候,在EISOO平台研发部门时候,为当时的云存储后端系统设计的那个管理后台初版有点像.不过那时候还涉及到集群管理,节点管理等等,比这个更复杂一些,那个是供IT管理员使用的后台系统: 我2011年时候接触到Openstack,转眼之间,已经是时隔四年多了

centos+Jenkins+maven搭建持续集成

Jenkins是一个开源软件项目,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能 什么是持续集成 随着软件开发复杂度的不断提高,团队开发成员间如何更好地协同工作以确保软件开发的质量已经慢慢成为开发过程中不可回避的问题.尤其是近些年来,敏捷(Agile) 在软件工程领域越来越红火,如何能再不断变化的需求中快速适应和保证软件的质量也显得尤其的重要. 持续集成正是针对这一类问题的一种软件开发实践.它倡导团队开发成员必须经常集成他们的工作,甚至每天都可能发生多次集成.而每次的集成都是通过自动化

续篇--TFS+MSbuild+jenkins 实现 持续集成+自动部署到WEB网站

之前写过两个博文都是这段时间接触持续集成的不断跟进,由于我们项目的实际情况,一度使得我认为我们的持续集成做不了,但是,却一直不死心,迭代的项目,不做持续集成,发版太劳神了,在有了之前的实践基础之后,让我在突然接触到Team Foundation Server--jenkin的插件时,灵光一闪也许可以试一下,通过jenkin插件 而不用去配置什么 Team Foundation Server本身的生成定义,那个实在有些高深,而且Team Foundation Server服务器并不在我的可空范围内

fir.im weekly - 「 持续集成 」实践教程合集

我们常看到许多团队和开发者分享他们的持续集成实践经验,本期 fir.im Weekly 收集了 iOS,Android,PHP ,NodeJS 等项目搭建持续集成的实践,以及一些国内外公司的内部持续集成系统的经验,供大家集中研究,参考借鉴. 先来看看国内外一些公司的实践经验: Continuous Deployment at Instagram Instagram 的开发团队每天保持着 30 - 50 次后端代码部署,几乎全程无人参与,完全自动化.这听起来很疯狂,但一切确实在这样运转.来这里看看

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

使用beanstalkd实现定制化持续集成过程中pipeline - 持续集成系列

持续集成是一种项目管理和流程模型,依赖于团队中各个角色的配合.各个角色的意识和配合不是一朝一夕能练就的,我们的工作只是提供一种方案和能力,这就是持续集成能力的服务化.而在做持续集成能力服务化的过程中,最核心的一点就是,如何实现一个可定制化的任务流,即所谓的pipeline. 在传统的持续集成工具实现了pipeline功能,以供串联上下游job,并把多个job联系成一次完整的构建,例如jenkins的pipeline插件. 但是各种持续集成工具,或多或少都有自己的短板,总结起来如下: 1.配置并不