随着项目拆的分散了之后 运维工作越来越依赖jenkins。但是随着而来的问题是什么呢???
jenkins的job越来越多 带来的隐患也越来越大。
如果一旦某天jenkins挂了或者数据发生了丢失 绝对会对整个研发流程带来相当大的负担。
根据墨菲定律 【会出错的事总会出错】那么对于jenkins的备份以及保护也是应该要做的。
如上所说 我们也安装了backup组件 Jenkins迁移神器:使用ThinBackup插件备份和还原Jenkins
但是备份是否就万无一失呢?jenkins任务的痛点莫非只是在备份上么???
目前jenkins至少存在以下几个问题
Jenkins 2.0 的精髓是 Pipeline as Code,是帮助 Jenkins 实现 CI 到 CD 转变的重要角色。什么是 Pipeline,简单来说,就是一套运行于 Jenkins 上的工作流框架,将原本独立运行于单个或者多个节点的任务连接起来,实现单个任务难以完成的复杂发布流程。Pipeline 的实现方式是一套 Groovy DSL,任何发布流程都可以表述为一段 Groovy 脚本,并且 Jenkins 支持从代码库直接读取脚本,从而实现了 Pipeline as Code 的理念。
Pipeline 的几个基本概念:
job 执行 pipeline 定义,可以有两种方式,一种直接在 job 填写 pipeline script 来执行,
一种是使用 pipeline script from SCM。
关于Pipeline Syntax 我们可以找到许多例子说明 比如
生成的dsl如下
checkout([$class: 'SubversionSCM', additionalCredentials: [], excludedCommitMessages: '', excludedRegions: '', excludedRevprop: '', excludedUsers: '', filterChangelog: false, ignoreDirPropChanges: false, includedRegions: '', locations: [[cancelProcessOnExternalsFail: true, credentialsId: 'svn-f6car-qixiaobo', depthOption: 'infinity', ignoreExternalsOption: true, local: '.', remote: 'http://svn.f6car/svn/f6car/src/f6-erp/trunk']], quietOperation: true, workspaceUpdater: [$class: 'UpdateUpdater']])
这样运维同学 甚至开发同学完全可以将对应的jenkins的脚本管理起来
利用
可以参考 浅谈Jenkins Pipeline | 一路向北