官方已有文档，why折腾

公司内网，与default配置有区别。

Windows机器配置

操作系统:64位Windows 7专业版

内存：4GB

安装Docker Toolbox

下载：https://download.docker.com/win/stable/DockerToolbox.exe

问题

在用SSH Secure File Transfer从linux服务器传输zip包到windows后，解压报文件已损坏。

解决

查Eidt-Settings-Global Settings-File Transfer-Mode

之前在找其他问题时手贱把mode设置成了ASCII,一般建议设置成Auto selec（自动选择），问题解决！

问题

在基底镜像centos:7基础上制作的镜像所起的容器中运行java程序，打出日志中文部分均显示为问号（?）

解决方法（网络收集）

在镜像Dockerfile中加上以下内容：

RUN yum -y install kde-l10n-Chinese && yum -y reinstall glibc-common && localedef -c -f UTF-8 -i zh_CN zh_CN.utf8

ENV LC_ALL zh_CN.utf8

yum

vi /etc/yum.conf

添加以下这行内容：http.proxy=http://127.0.0.1:8080

apt-get

新建一个文件任意命名如

conf

文件内容如下：

Acquire::http::proxy "http://127.0.0.1:8000/";
Acquire::ftp::proxy "ftp://127.0.0.1:8000/";
Acquire::https::proxy "https://127.0.0.1:8000/";

功能测试覆盖率的意义

首先需要明确，将某些数据指标与KPI联系是毫无意义的！！！

数据指标情况只能辅助咱们决策或调整策略，与功能测试覆盖率类似，大家接触较多的可能是单元测试覆盖率，覆盖率够高，不一定代码质量就好，只是开发人员的质量信心能够有一些保障，覆盖率低，则证明有一些代码的分支甚至是没有经过单元测试的，则有必要检查我们比较关注的重要分支是否被测试覆盖，如果有，我觉得即使总体覆盖率低也是可以接受的。所以，这里的指标数据只是帮助我们及时调整策略。

与单元测试覆盖率类似，功能测试覆盖率的用途首先肯定不是用作各种考核。功能测试的对象也是应用代码，只是从更偏向于终端用户的视角运行应用，所以，从分析功能测试覆盖率可预见的几个好处至少包括：

• 可能发现冗余无用代码

• 可能发现重要逻辑测试遗漏

• 可能根据覆盖率情况及时调整测试策略

坑

因为要将传统的持续交付管道改造成基于Docker的，所以需要切换原有的环境部署方式，相应的环境验证方式也需要更改。之前的方式Jenkins会把部署脚本和环境验证脚本当成一个shell脚本执行，做了切换之后，需要将之前的环境验证脚本改成执行通过shell执行，即只需要用linux环境就可以运行。由于对linux的shell不熟，才遇到这样一个大坑，特此记录。

参考脚本如下:

1

sh " while [ `curl -o /dev/null -s -w %{http_code} http://xxx:xxx/test.html` != 200 ];do sleep 1;done;"

注意点

while里面的判断左右的中括号都需要有一个空格，否则判断语句无效，因为这个问题纠结一下午…

前言

之前遇到有个项目丢失了war包，只有镜像和容器文件，但是现在需要变更数据库地址重新部署。更奇葩的是数据库配置不是在配置文件中，而是在一个Jar包中，需要把这个Jar包解压，然后修改解压后的某一个文件，然后重新打包上传，这就引入了这次的需求。

解决方案

第一想法是在容器里开SSH服务，然后SSH进去，但是立马被自己否了，因为镜像只Expose了单端口，即应用访问的端口。如果需要其他端口服务，需要重新制作镜像并Expose其他端口，例如SSH就需要Expose22端口，相对比较麻烦。所以就找到以下这种比较傻但是有效的方式：

启动容器时候挂载容器里的一个空目录到本地一个目录，然后docker exec进入容器将需要下载的文件复制到容器里的那个空目录，退出容器，done！

简单方便！

前言

上一章中介绍了目前基于Jenkins的Pipeline As Code，解决了之前基于Build Pipeline的一系列问题，本章中我们将介绍引入docker来优化我们的持续交付管道。

Docker是什么

简单来说，Docker是区别于传统虚拟化的另外一种虚拟方式，更轻便。

具体可以参考：https://yeasy.gitbooks.io/docker_practice/content/introduction/what.html

Docker可以解决什么问题

之前有提到过Jenkins完成构建任务主要是通过插件，插件则依赖持续集成服务器上的工具。比如如果我需要完成一个Maven工程的编译打包，首先得需要持续集成服务器上得有Maven工具，才能在管道中调用服务器里的Maven工具完成打包。这样带来的直接问题就是：不同构建任务如果需要不同构建工具，则需要在服务器上配置各种构建工具，这对于持续集成服务器的维护工作是个挑战。

前言

上一章中介绍了目前基于Jenkins的Pipeline As Code，解决了之前基于Build Pipeline的一系列问题，本章中我们将介绍引入docker来优化我们的持续交付管道。

Docker是什么

简单来说，Docker是区别于传统虚拟化的另外一种虚拟方式，更轻便。

具体可以参考：https://yeasy.gitbooks.io/docker_practice/content/introduction/what.html

Docker可以解决什么问题

之前有提到过Jenkins完成构建任务主要是通过插件，插件则依赖持续集成服务器上的工具。比如如果我需要完成一个Maven工程的编译打包，首先得需要持续集成服务器上得有Maven工具，才能在管道中调用服务器里的Maven工具完成打包。这样带来的直接问题就是：不同构建任务如果需要不同构建工具，则需要在服务器上配置各种构建工具，这对于持续集成服务器的维护工作是个挑战。

前言

上一章介绍了如何基于build pipeline plugin插件搭建Jenkins的持续交付管道，但是实际上是通过另外新建一个视图来将原本没有关系的Job串联在一起，构成“管道”视图。这种方式的好处在于实现简单，不需要变更使用习惯。 　　

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

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

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

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

　　
more >>