[持续交付实践] pipeline:pipeline 使用之快速入门

什么是pipeline

先介绍下什么是Jenkins 2.0,Jenkins 2.0的精髓是Pipeline as Code,是帮助Jenkins实现CI到CD转变的重要角色。什么是Pipeline,简单来说,就是一套运行于Jenkins上的工作流框架,将原本独立运行于单个或者多个节点的任务连接起来,实现单个任务难以完成的复杂发布流程。Pipeline的实现方式是一套Groovy DSL,任何发布流程都可以表述为一段Groovy脚本,并且Jenkins支持从代码库直接读取脚本,从而实现了Pipeline as Code的理念。
Pipeline的几个基本概念:
Stage: 阶段,一个Pipeline可以划分为若干个Stage,每个Stage代表一组操作。注意,Stage是一个逻辑分组的概念,可以跨多个Node。
Node: 节点,一个Node就是一个Jenkins节点,或者是Master,或者是Agent,是执行Step的具体运行期环境。
Step: 步骤,Step是最基本的操作单元,小到创建一个目录,大到构建一个Docker镜像,由各类Jenkins Plugin提供。
本节介绍Jenkins Pipeline的一些核心概念,并介绍在运行的Jenkins实例中定义和使用Pipelines的基础知识。

使用条件

要使用Jenkins Pipeline,需要:
Jenkins 2.x或更高版本
Pipeline插件

Pipeline定义

Pipeline脚本是用Groovy写的 。Groovy语法将在后续文档中介绍。
可以通过以下任一方式创建基本Pipeline:
pipeline script:直接在Web UI的script输入框里面输入pipeline script语句即可,参考说明可以点击输入框下边的Pipeline Syntax,里面有很多示例操作说明,非常好用。
pipeline script from SCM:需要配置SCM代码存储Git地址或SVN地址,指定script文件Jenkinsfile所在路径,每次构建job会自动去指定的目录执行script文件
以上两种方法定义Pipeline的语法都是一样的。

在Web UI中定义Pipeline
要在Jenkins Web UI中创建基本Pipeline Job,请按照下列步骤操作:
单击Jenkins主页上的New Item。

输入Pipeline的名称,选择Pipeline,然后单击确定。

在脚本文本区域中,输入Pipeline,然后单击保存。

单击“构建历史记录”下的#buildId,然后单击控制台输出以查看Pipeline的完整输出

在SCM中定义pipeline
复杂的Pipeline难以在Pipeline配置页面的文本区域内进行写入和维护。为了解决这一问题,jenkins Pipeline支持在文本编辑器中编写脚本文件jenkinsFile,Jenkins可以通过从SCM选项的控件中加载Pipeline脚本。
选择SCM选项中的Pipeline脚本后,不要在Jenkins UI中输入任何Groovy代码; 只需指定要检索的Pipeline脚本的路径。更新指定的存储库时,只要Pipeline配置了SCM轮询触发器,就会触发一个新构建。
---文本编辑器,IDE,GitHub等将使用Groovy代码进行语法高亮显示, 第一行Jenkinsfile应该是#!/usr/bin/env groovy Jenkinsfile。
内置文档
Pipeline配有内置的文档功能,可以更轻松地创建不同复杂性的Pipeline。根据Jenkins实例中安装的插件自动生成和更新内置文档。
内置文档可以在全局范围内找到: localhost:8080/pipeline-syntax/,假设您有一个Jenkins实例在本地端口8080上运行。同样的文档也作为pipeline语法链接到任何配置的Pipeline的侧栏中项目。

代码段生成器
内置的“Snippet Generator”程序有助于为单个步骤生成代码段。
Snippet Generator动态填充Jenkins实例可用的步骤列表。可用的步骤数量取决于安装的插件,它明确地暴露了在Pipeline中使用的步骤。
要使用代码段生成器生成步骤代码片段:
1、从配置的流水线或本地主机:8080 / pipeline-syntax导航到Pipeline语法链接Pipeline Syntax

2、在“ Sample Step”下拉菜单中选择所需的步骤,使用“Sample Step”下拉列表下方的动态填充区域配置所选步骤,如message为“hello world”,单击生成Pipeline脚本以创建一个可以复制并粘贴到Pipeline中的Pipeline代码段

全局变量引用
除了代码片段生成器之外,Pipeline还提供了一个内置的“ 全局变量引用”。像Snippet Generator一样,它也是由插件动态填充的。与代码段生成器不同的是,全局变量引用仅包含Pipeline提供的变量,这些变量可用于Pipeline。

在Pipeline中默认提供的变量是:
ENV
Pipeline脚本可访问的环境变量,例如: env.PATH或env.BUILD_ID。请参阅内置的全局变量,以获取管道中可用的完整和最新的环境变量列表。
PARAMS
将为Pipeline定义的所有参数公开,例如:params.MY_PARAM_NAME。
currentBuild
可获取当前正在执行的Pipeline job的信息,例如属性currentBuild.result,currentBuild.displayName等等

引用官方文档:https://jenkins.io/doc/book/pipeline/getting-started/
Groovy语法及入门:
Groovy入门之语法和变量定义
Groovy进阶之函数、闭包和类
精通 Groovy

时间: 2024-10-12 18:51:59

[持续交付实践] pipeline:pipeline 使用之快速入门的相关文章

云端基于Docker的微服务与持续交付实践

云端基于Docker的微服务与持续交付实践笔记,是基于易立老师在阿里巴巴首届在线技术峰会上<云端基于Docker的微服务与持续交付实践>总结而出的. 本次主要讲了什么? Docker Swarm Docker Swarm mode 微服务支持(Docker集群架构体系) Docker的发展趋势和前沿成果 在Docker技术方面还是很佩服大牛的,所以赶紧写下笔记,追随大神的脚步. 阿里云资深专家易立,技术就不说了,他比其他直播间硬生生多讲了半个多点,于情于理还是万分感谢本次分享的(可惜devOp

Docker学习总结(7)——云端基于Docker的微服务与持续交付实践

本文根据[2016 全球运维大会?深圳站]现场演讲嘉宾分享内容整理而成 讲师简介 易立 毕业于北京大学,获得学士学位和硕士学位:目前负责阿里云容器技术相关的产品的研发工作. 加入阿里之前,曾在IBM中国开发中心工作14年,担任资深技术专员,负责IBM企业平台云产品线PureApplication System的研发工作:还负责和参与了一系列IBM在Web 2.0,SOA中间件的研发和创新,也曾为全球客户提供SOA技术咨询和项目实施. 日程 大家好,我演讲的主题是<云端基于Docker的微服务与持

持续交付实践-pipeline 使用之 MultiBranch Pipeline

前言 在探讨multiBranch Pipeline之前,很有必要先探讨下如何制定有效的代码分支管理规范,使用高效的版本控制系统,并对构建产物及其依赖进行管理.我们首先要强调,需要进行版本控制的不仅是源代码,还有测试代码.数据库脚本.构建和部署脚本.依赖的库文件等,并且对构建产物的版本控制也同样重要.只有这些内容都纳入版本控制了,才能够确保所有的开发.测试.运维活动能够正常开展,系统能够被完整的搭建.制定有效的分支管理策略对达成持续交付的目标非常重要.看过<持续交付>这本书的同学都知道,持续交

[持续交付实践] pipeline:pipeline 使用之语法详解

一.引言 jenkins pipeline语法的发展如此之快用日新月异来形容也不为过,而目前国内对jenkins pipeline关注的人还非常少,相关的文章更是稀少,唯一看到w3c有篇相关的估计是直接翻译软件翻的,读下来惨不忍睹.没办法,语法详解这章我干脆把jenkins官网上的语法说明全部翻译了一遍,并更新了陈旧的内容(可怜了我大学四级的英语水平~),英语好的朋友也可以直接到官网阅读. 二.语法简介 Pipeline最基本的部分是"step".基本上,step告诉Jenkins 要

[持续交付实践] 安全扫描自动化测试平台实现

前言 TesterHome有人专门加了我QQ问安全测试这个话题,所以这篇准备先聊聊持续交付中的安全测试.现在信息安全已经上升到了国家战略的高度,特别是今年<中华人民共和国网络安全法>颁布后,用户隐私通过国家立法的方式被严格要求保护,另外一方面安全灰产行业风起云涌,形成了一个巨大的地下产业链条和破坏能力.在此背景下,越来越多的互联网公司也开始组建自己的安全职能部门,但也会发现很多公司的软件并没有经过专门的安全测试便运行在互联网上,它们携带着各类安全漏洞直接暴露在公众面前,其中一些漏洞甚至直指软件

联想企业网盘:SaaS服务集群化持续交付实践

1      前言 当代信息技术飞速发展,软件和系统的代码规模都变得越来越大,而且组件众多,依赖繁复,每次新版本的发布都仿佛是乘坐一次无座的绿皮车长途夜行,疲惫不堪.软件交付是一个复杂的工程,涉及到软件开发的各个细节,其中任何一环出现问题,都会导致软件不能及时交付,或者交付的质量堪忧. 从企业的角度来讲,如何利用更科学的工具.更科学的流程来提高产品质量,提升客户满意度,是刚需.从员工角度来讲,生命里值得追求的事情很多,不能把宝贵的时间浪费在一些机械的.重复的事情上面. 联想企业网盘从2007开始

[持续交付实践] 基于 sonarqube 的代码检查平台实现

前言 公司此前用的一直是的SonarQube5.1(2015年版本,为兼容jdk6和jdk7的项目一直没有升级),最近为了pipeline的集成刚刚升级到了最新的SonarQube6.5版本.网上对SonarQube6的介绍比较少,这里重点先介绍下SonarQube6以后的一些新增特性.1.代码问题重新分级,将问题分为bug.漏洞.坏味道:将代码检查结果从可靠性.安全性.可维护性几个角度进行问题分类和风险分级.2.更丰富的代码检查规则,更友好的问题处理曲线展示,更清晰的质量阈和代码规则定制.3.

[持续交付实践] pipelne:pipeline 使用之项目样例

项目说明 本文将以一个微服务项目的具体pipeline样例进行脚本编写说明.一条完整的pipeline交付流水线通常会包括代码获取.单元测试.静态检查.打包部署.接口层测试.UI层测试.性能专项测试(可能还有安全.APP等专项).人工验收等研发测试环节,还会包括灰度发布.正式发布等发布环节. 补充说明:1.此项目的部署还是使用传统虚拟机服务器的方式,暂未采用docker容器,docker容器与pipeline的结合后面会有其他专题进行说明.2.灰度发布.正式发布等发布环节,由于涉及到线上发布系统

[持续交付实践] pipeline:pipeline 使用之 Shared Libraries

前言 随着pipeline交付流水线在团队中的推广,使用pipeline脚本的job也迅速增加.虽然我们已经基于公司的技术栈特点做了一个尽可能通用的pipeline脚本样例,让搭建者只需要修改几个赋值参数就可以在自己的项目中应用,初衷是希望所有人能理解pipeline中的过程,但也发现一些比较麻烦的问题,比如有些人不熟悉具体的脚本拿来随意删改导致各种错误,还有就是我们在pipeline脚本中增加一些新功能时又需要通知所有的pipeline维护人员去修改,过程非常纠结.这时候就意味着我们需要用到p