遇到问题

前面有讲到通过Jenkins完成环境部署的步骤，在实际使用过程中遇到一个问题，因为在war包传输结束后执行完shell，部分容器可能启动时间需要较长时间，可能造成shell执行结束，直接触发了构建成功的邮件，测试人员收到邮件之后却发现环境还没有起来，对我们造成一定困扰。

解决方案

在shell最后加以下这段代码：

1
2
3
4
5
6

STATUS_CODE=0
echo $STATUS_CODE
while [[ $STATUS_CODE != 200 ]]
do
    STATUS_CODE=`curl -o /dev/null -s -w %{http_code} http://localhost:8080/test.html`
done

使用场景

Jenkins没有数据库，因此构建产出的内容都是放在文件中，如果要获取构建日志中的指定内容会非常麻烦。例如有一些用于造测试数据的自动化工具，需要从构建日志中获取到指定的测试数据，则需要借助正则解析构建日志。

Email-ext plugin

Email-ext plugin插件提供了通过正则解析构建日志，提取指定构建日志内容的功能。$BUILD_LOG_MULTILINE_REGEX

使用实例

在邮件content中配置如下内容：

${BUILD_LOG_MULTILINE_REGEX,regex=”测试数据：.*”,maxMatches=0,showTruncatedLines=false,escapeHtml=false,matchedSegmentHtmlStyle=”color:blue”}

前言

上一章中已经介绍了如何基于Jenkins配置一个独立的Job，即完成了交付流程中单个节点的实现，持续交付管道需要将交付流程中的各个节点串起来，再加上适当的反馈。本章将介绍如何将各个独立Job进行串联。

各个交付节点的实现

结合上一章的内容，交付流程中的各个节点其实就对应到一个一个的Job。以典型的Java项目为例，如果使用Maven进行构建，可能涉及的节点可能有：编译打包、单元测试、静态扫描、测试部署、功能测试等。分别对应的Maven命令如下：

• 编译打包(跳过单元测试)：mvn clean install -Dmaven.test.skip=true

• 单元测试：mvn clean test

• 静态扫描：mvn sonar:sonar

前言

本系统旨在从零基础开始讲解如何基于Jenkins搭建持续交付管道，因此本系列前面几篇会比较基础。本章结合实例讲解Jenkins的基础用法。

安装插件

上一章中提到了在第一次启动过程中选择插件安装，那之后的使用过程中如果需要用到其他插件呢？

具体操作是：进入系统管理>管理插件，点击“可选插件标签”，可看到所有可用插件，可通过右上角输入框进行过滤：

例如需要安装maven插件，可在输入框中输入”maven”,可看到可用插件被过滤到只剩几个。选择Maven Integration plugin，点击直接安装。

前言

持续交付流程的持续指的是不断产出能够工作的成果。与敏捷思想一致，过程中通过不断对产出成果进行验证，避免与最终客户实际需求有过大偏差。

持续交付管道是持续交付的实践之一，持续交付管道的核心包括自动化、管道化和持续化。自动化的意义在于提升效率，管道化的意义在于节约流程控制所需要的人工成本，持续化的目的不断产出成果，加强过程结果监控。

以常见的Java项目为例，从代码检入到最后代码投产到生产环境，大致会包含单元测试，静态扫描，自动部署，功能测试，性能测试，安全测试、自动投产等一系列检查步骤。这里将自动部署和自动投产也列为检查步骤之一，是因为我认为自动部署和自动投产都不应该仅以执行完部署或投产的脚本就算成功，而是以部署完或投产之后环境符合预期，才能作为这两个步骤的成功条件。

持续交付管道的实现就是将各个检查步骤尽可能自动化，并串成一条线，通过管道中的自动反馈，能够快速直接地反馈当前工作成果的实际情况，比如是已经测试通过了还是连单元测试都没通过。

基于Jenkins的持续交付管道实现方式有两种，其中第一种相对好理解也好实现，但是非官方，第二种是官方推荐的管道实现方式。

关于Jenkins

使用场景

最近遇到两个问题，需要对已有的镜像进行修改并重新上传。

修改tomcat默认设置

有个项目需要用到ojdbc的jar包，需要放到tomcat的lib里，默认的tomcat没有这个jar包，所以需要手动上传至lib然后重新打镜像。

修改应用参数

第二个场景略奇葩，有个项目需要做数据库迁移，但是项目的war包和源码都找不到了，唯一能拿到的地方就是现在正在运行的容器和镜像库里对应的镜像。

具体操作

前言

常见的Jenkins持续交付管道是基于Build Pipeline View插件的，实际上是通过另外新建一个视图来将原本没有关系的Job串联在一起，构成“管道”视图。这种方式的好处在于实现简单，不需要变更使用习惯。 　　

但是随着持续交付管道应用的深入，渐渐会发现这种方式的种种弊端：

• 与“管道流”的初衷违背。由于各个交付节点实际上是各自分离的独立Job，所以每一个Job会在都是在自己的独立工作空间进行构建任务。这与“管道流”的初衷-上一节点的合格交付物流入下一节点-是违背的，因为各个Job的交付物其实是没有直接关联的；

• Job维护工作量大。由于每一个交付管道的节点数众多，意味着每一条交付管道需要你维护多个Job，然后再将各个Job串联。因此，你可能需要花费大量时间来维护多个Job配置；

• 交付反馈流程可能存在冗余。由于各个Job都有自己独立的工作空间，各个工作空间是无法直接交互的。为了尽早反馈，我们希望将反馈节点尽量分割开，比如单元测试和静态扫描我们会分离成两个Job，但是静态扫描实际会依赖单元测试的产物（主要是覆盖率jacoco文件），所以导致单元测试可能会在单元测试和静态扫描环节重复执行，同样的情况还存在于编译打包和部署环节。

　　
more >>

基于Docker环境下的持续交付画的一张图，感觉还是比较合适的。

去年一年主要做的就是推持续交付思想，今年也将持续，将去年工作中的一些想法记录一下。

一些想法

• 持续交付其实是敏捷思想的一部分，强调小频快，将可交付物切分到最小粒度，通过频繁的提交可供客户验证的交付物频繁接受反馈，从而快速响应做出相应反馈。

• 持续交付与持续集成的区别在于，持续集成关注的是过程产物的合格与否，而持续交付只关注最终的可交付物，过程只是为了提升最终可交付物合格率的手段而已。

• 持续交付有一个关键的前提是过程自动化程度要很高，比如自动化单元测试，自动化静态代码扫描，自动化功能测试，自动化性能测试，自动化安全测试，环境自动部署，自动投产等等。

• 持续交付的最佳实践之一TDD成功开展的前提是单元测试得先推行且需要让项目组成员真正理解单元测试的意义以及具体如何写有效的单元测试，否则很难开展。

• 单元测试与功能测试虽然都是测试，但是对于最终可交付物质量的影响不大相同，个人理解单元测试更多的是确保代码没问题，功能测试则是希望找出问题，这与软件测试理论里所说的软件测试的目标是一致的。

Jenkins

Jenkins完成代码自动编译打包的任务。

Jenkins配置注意

建议安装的插件包括版本管理（SVN/GIT），邮件，Ansible。
在打包成功之后，在后置操作中选择调用Ansible playbook。

Ansible

Ansible完成war包发送和tomcat的启停。
more >>