Jenkins自动化构建系列:01敏捷开发、自动化构建与持续集成

SVN与TortoiseSVN实战系列》已写完,今天新开一个《Jenkins自动化构建系列》,上周听了Bob Jiang老师的Agile1001公开课,一直想写个总结,这篇关于敏捷开发、自动化构建与持续集成的思考就作为开题篇吧。

敏捷是什么?

敏捷是一把伞,这把伞下边有XP、Scrum、FDD。。。,当然也包括自动化构建、持续集成,其实符合敏捷思想的开发方法、工具,如Jenkins都可以属于敏捷开发的范畴,上课时的PPT:

敏捷到底是什么?

其实关于敏捷的定义有很多,Bob Jiang的解释是:尽早地交付商业价值。

为什么需要敏捷开发?

敏捷之所以流行,是因为传统的瀑布式开发方式导致大项目的失败率很高(与小项目对比),而敏捷的解决思路是将大项目分解为小项目(也可以理解为阶段里程碑)来提高项目的成功率,尽早地、频繁地、持续的交付。

大项目与小项目成功率对比图:

为什么需要自动化构建?

传统的开发流程:

敏捷的开发流程:

由于敏捷的开发方式改变了传统的开发流程,需要持续频繁的对代码进行集成、构建、发布,所以就产生了自动化构建与持续集成的需求。

想想每次发布所需的工作:构建、交付准备环境、代码发布全由手工完成,同样还有运行测试、备份旧版本、新版本打标签以及许多其他重复的事情。

计算机就是用来解决重复性工作的,同一项工作重复3次以上就应该使用工具来解决。

Jenkins能解决什么?

Jenkins 是一个开源项目,提供了一种易于使用的自动化构建和持续集成系统。

软件构建自动化:配置完成后,Jenkins会依照预先制定的时间表,或者针对某一特定事件触发,对源代码编译构建;

可持续的自动化检查:Jenkins能持续地获取新增或修改后签入的源代码,并对这些代码使用预先设定的规则进行代码质量检查;

可持续的自动化测试:构建检查的扩展部分,构建后执行预先制定的一套测试规则,如项目中的单元测试、集成测试代码,并收集测试代码覆盖率、结果;

生成后后续过程的自动化:当自动化检查和测试成功完成,软件构建的周期中可能也需要一些额外的任务,诸如生成文档、打包软件、部署构件到一个运行环境或者软件仓库。

Jenkins是框架式的,大部分功能通过插件的方式来实现,可扩展性非常高。

手贱百度了下Jenkins的百度指数,大家看出点什么没?



记录,为更好的自己!

时间: 2024-10-10 15:42:05

Jenkins自动化构建系列:01敏捷开发、自动化构建与持续集成的相关文章

HUDSON(Java开发的一种持续集成工具)

Hudson是Jenkins的前身,是基于Java开发的一种持续集成工具,用于监控程序重复的工作,包括: 1.持续的软件版本发布/测试项目. 2.监控外部调用执行的工作. Hudson的特性 1.易于安装-只要把hudson.war部署到servlet容器,不需要数据库支持. 2.易于配置-所有配置都是通过其提供的web界面实现. 3.集成RSS/E-mail/IM-通过RSS发布构建结果或当构建失败时通过e-mail实时通知. 4.生成JUnit/TestNG测试报告. 5.分布式构建支持-H

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

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

内修敏捷开发心法 + 外炼持续整合招式

说好的软件质量 提升软件质量是我们一直追求的理想,但软件开发唯一不变的真理就是变,为了应付变化多端的软件开发过程,敏捷开发提倡了一种拥抱变化的软件开发理念,少说也替软件开发人员带来了不少小确幸. 这些软件开发模型与方法论,最终的目的在于软件开发管理与质量的提升,与其说质量提升倒不如说是维持一定的水平.虽然敏捷开发有很多不同的方法论 (例如 Scrum, XP 等等),但我们注意到这些方法论都一定会提到「持续整合 (Continuous Integration)」这个概念.持续整合到底是何方神圣?

(六)构建Docker私有仓库、Gitlab仓库和持续集成环境

环境说明 IP 功能 eth0:192.168.124.139 eth1:172.16.100.10 Docker私有仓库.Gitlab.持续集成 eth0:192.168.124.138 eth1:172.16.100.20 Docker服务器,运行容器 构建Docker私有仓库 我们通过Docker官方镜像registry来构建私有仓库. 首先要关闭防火墙.开启IP转发,在CentOS 7上IP转发是禁用的. 默认情况下会将仓库目录创建在容器的/var/lib/registry/下,所以我们

Docker——Jenkins + Git + Registry构建自动化持续集成环境(CI/CD)

前言 在互联网时代,对于每一家公司,软件开发和发布的重要性不言而喻,目前已经形成一套标准的流程,最重要的组成部分就是持续集成(CI)及持续部署.交付(CD). 本文基于Jenkins+Docker+Git\Svn实现一套CI自动化发布流程,同时支持撤回. 一.发布流程设计 工作流程: 开发人员提交代码到Git或Svn版本仓库: Jenkins人工/定时触发项目构建: Jenkins拉取代码.代码编码.打包镜像.推送到镜像仓库: Jenkins在Docker主机创建容器并发布. 二.环境设计 1.

【DevOps】团队敏捷开发系列--开山篇

随着软件发布迭代的频率越来越高,传统的「瀑布型」(开发-测试-发布)模式已经不能满足快速交付的需求.2009 年左右 DevOps 应运而生,开发运维一体化,通过自动化工具与流程让整个软件开发构建.测试.发布更加快捷.频繁.高效和可靠. 本系列教程目录 本系列将详细讲解Devops落地细节.将构建整个持续集成与交付的一整套体系与流程.对于未来要开篇的系列博文列表如下: [DevOps]团队敏捷开发系列(一)--开山篇 [DevOps]团队敏捷开发系列(二)--版本控制之道Git [DevOps]

.NET 半天搭建Jenkins持续集成与自动化部署系统

前言 相信每一位程序员都经历过深夜加班上线的痛苦!而作为一个加班上线如家常便饭的码农,更是深感其痛.由于我们所做的系统业务复杂,系统庞大,设计到多个系统之间的合作,而核心系统更是采用分布式系统架构,由于当时对系统划分的不合理等等原因导致每次发版都会设计到多个系统的发布,小的版本三五个,大的版本十几个甚至几十个系统的同时发布!而我们也没有相应的基础设施的支撑,发版方式更是最传统的,开发人员将发布包发给运维人员,由其讲各个发布包一个一个覆盖到生产环境.因此每次上线仅仅发版就需要2-3个小时.这种方式

接口自动化平台搭建(四),自动化项目Jenkins持续集成

一.Jenkins的优点 1.传统网站部署流程 ??一般网站部署的流程 这边是完整流程而不是简化的流程 需求分析-原型设计-开发代码-内网部署-提交测试-确认上线-备份数据-外网更新-最终测试 ,如果发现外网部署的代码有异常,需要及时回滚. 一般是运维来做 1.功能测试 2.上线的时间 3. jenkins 4.运维 5.功能测试 2.Jenkins部署流程 ??我们可以通过jenkins工具平台实现全自动部署+测试,是一个可扩展的持续集成引擎,是一个开源软件项目,旨在提供一个开放易用的软件平台

拥抱自动化,CODING 2.0 持续集成全新上线

在文章开始前,做一个小调查,在您的软件项目中集成一行新代码平均需要花多长时间? 15 分钟 一小时 半天 一天及以上 注意这里的集成是指将源码放在一起,并验证源码可以作为一个一致.运行可靠的软件的过程,而不只是完成编译. 如果在软件集成阶段耗费的时间经常让您的研发团队加班加点,那么是时候考虑落地持续集成了.我们都知道软件只有从代码生成制品,最终部署到生产环境中可靠运行才会给公司带来收入.持续集成是一种以"反馈"为核心的实践,为了达到短周期.高质量的交付目标,研发团队需要频繁且自动化地发