在Jenkins2.X使用Pipeline执行python测试脚本
一、pipeline介绍
Pipeline是Jenkins2.X的最核心的特性，帮助Jenkins实现从CI到CD与DevOps的转变。
Pipeline，一套运行于Jenkins上的工作流框架， 将原本独立运行于单个或者多个节点的任务连接起来， 实现单个任务难以完成的复杂流程编排与可视化。
二、jenkins2以上版本如果在安装时安装插件，就有了。如果没有请升级你的版本，我现在是 2.258。
三 、Pipeline脚本是由Groovy语言实现（无需专门学习）支持两种语法：Declarative 声明式，Scripted Pipeline 脚本式。
我们以声明式为例写个最简单的：
1、新建一个pipeline（流水线）的工作job，在流水线选择helloworld模板：
1、在流水线上的脚本输入下面的：
2、执行的视图：
控制台输出结果如下：
如何用Jenkins/Hudson创建真正的pipeline
如何用Jenkins/Hudson创建真正的pipeline
这几天尝试用Jenkins/Hudson创建pipeline，发现网上的信息很少，所以写一篇跟大家分享。
在开始之前，得告诉你被我的标题给忽悠了，不是Jenkins/Hudson，只是Jenkins！如果你还在用Hudson，那么我建议你立即切换到Jenkins。理由就不说了，看看这个投票就行。（此中，我吃尽了苦头）
接下来，就让我们一步一步用Jenkins搭建真正的pipeline吧。
第一步
第一步，我们先创建一个最简单的pipeline。所谓pipeline，顾名思义，就是一个流水线，由多个步骤（steps）组成。每走完一步，就来到下一步。用Build Pipeline Plugin就可以很方便地实现。
实现的效果如下图：
上例中，UnitTest是我们的初始任务。UnitTest结束之后，自动触发AC Test。如果通过了AC Test，团队可以有选择地部署到任意测试环境。
在配置这个插件时，最重要的就是选择Initial Job。
然后，在每一个step（job）中选择downstream step。可以是自动触发（Build Other Projects），也可以选择手动触发（Manually Execute Downstream Project）。
第二步
第一步中我们实现了一个流水线，但这个只是看上去的流水线而已。在工厂的流水线中，历经流水线上游到下游的，应该是同一个产品。但上例中显然不是，Unit Test和Acceptance Test所运行的可能是不同版本的代码。
要让几个step的代码运行在同一个版本，可以使用一个叫做Parameterized Trigger Plugin。如下图：
选择把Subversion revision传到下面的steps，则接下来的Steps都会checkout同一个版本的代码。但这个也有限制，就是这些Steps必须有相同的subversion URL配置。
另外，你应该还注意到我们还传了另一个参数：PL_BUILD_NUMBER。这个参数会另有用途。
除了希望保持相同版本，我们很可能希望重用upstream step生成的artifact。比如，在AC Test step会生成一些artifacts，这些artifacts经过测试之后，希望可以用于Deploy步骤。一方面，这会节省重新构建artifact的时间；另一方面，这些artifact是已经经过测试的，是可用的，而重新构建生成的却是未经测试的，可用与否未知。（虽然他们应该是一样的，但谁知道呢。。）我们可以使用ArtifactDepolyerPlugin实现。
jenkins之pipeline相关概念
pipeline是什么，有什么作用，用groovy语言编写
创建pipeline操作步骤：
1、安装jenkins 和安装插件 pipeline。
2、新建一个pipeline项目，在pipeline中加入脚本，构建执行。
部署流水线：Deployment pipeline,从软件版本控制库到用户手中这一过程的自动化表现形式。
所有的部署流水线都写在jenkins-file文件中，需要安装插件pipeline插件后才能使用jenkins-file。
1.pipeline最简单的结构
pipeline是什么，用于描述整条流水线是如何进行的。流水线的内容包括执行编译、打包、测试、输出测试报告等步骤。以下5个部分是pipeline的必需存在的，少一个，jenkins都会报错。
2.pipeline的步骤
pipeline基本结构决定的是pipeline整体流程。
pipeline plugin的github仓库：
jenkins pipeline支持的指令有：
声明式（Delar-ative）语法脚本式（Scripted）语法如图：
Jenkins使用痛点小析
Jenkins 刚开始搭建的时候，我们惊叹，这也太方便了吧？功能还这么强，慢慢的，我们会发现对方的缺点了，嗯，恋爱的味道，不对，似乎扯远了，还是说回来 Jenkins 了。
我们很难想象 Jenkins ，这么庞大的一个应用，居然没有数据库。那配置在哪保存呢？运行日志了？构建数据了？等等这些都是需要保存的啊。
屏幕快照 2019-12-19 下午8.29.10.png 屏幕快照 2019-12-19 下午8.29.10.png
当jenkins job数量达到一定量级，访问量大时候，会非常卡顿，仿佛回到了零几年的时候，网页那么卡。
查原因我们会发现瓶颈在 I/O 。因为jenkins每次访问，都需要读取配置，都需要读写日志，这些都是以文件方式写入磁盘的，是 所有slave 节点和 一台master 通信。
可是我们是没有办法做负载均衡的
当我们部署后端服务时候，肯定做 LB(负载均衡) , Jenkins master 因为只能单节点，啊，挂了master，所有slave都掉链子了。
配置 存储 master节点磁盘，嗯，还好，比较小
构建日志 存储在master节点磁盘，这个，百万行代码的编译日志几百M大小，每天N个业务构建M次，存储在master，哈哈，每天上班第一件事清磁盘？
构建产物 存储在master节点磁盘，这个，占磁盘，不安全
针对这种情况了，日志用 ELK ，产物放到到 对象存储
调度，一个好高深的话题，教材上学过操作系统对进程的各种调度算法，什么 先入先出 ， 最短耗时 ， 最高优先级(PRI,NI) 等等，而类似的集群调度， k8s 可能是最常见的了，但是 Jenkins 对于任务调度这块，实际来讲，确实很弱, 虽然 调度 也是 Jenkins 的核心能力之一
k8s 里面有 node节点 概念， Jenkins 也有
k8s 里面有 pod 概念， Jenkins 没有，类似的， Jenkins 是限制 node 的最大并行个数
k8s 里面有调度器， 进行 Predicates 和 Priorities 两个过程， Jenkins 算法很简单，默认就是调度到 最近一次成功节点 上。
这样会带来一个比较严重的问题，会导致 部分机器处于极度打满，部分机器确空转，资源利用率严重两级分化 。
针对这点，我们其实有两种小的补救。
一种是降低node节点并行数量，比如原来是最大限制是10，下降到2后，第三个任务，比如调度另一个节点了，缺点就是可能造成更多排队情况
一种就是利用插件了，比如插件 throttle-concurrents 会比较均匀分配
总体而言，调度这块，Jenkins确实有很长路走
微服务 相比 单体应用 似乎高大上了很多，我们把服务抽象出来，只专注于某一部分，然后各个部分串联起来。
Jenkins 里面，一次构建，我们可能会写一个长长的脚本，举例子来说，我们需要构建一个移动端产物apk/ipa， 我们需要
clone code - 更新依赖库 - 编译 - 产物保存 - 分发到商店
传统上，我们可以把这一串代码都写到 job 配置里面，但更好的做法，我们是把每一步抽象出来，每一步都是一个服务(一个job)
怎么串联起来呢？ 没有流水线之前，是 Jenkins 上下游任务关联 , 哈哈，当任务量多了，我们发现，调用链很难捋清楚了，当然微服务里面有自己的解决办法 - 链路追踪，网关
流水线 ，可以帮我们把这些串联起来，我们最后需要管理的只是流水线
小思考，不足之处，欢迎交流