前面几篇文章主要讲了jenkins搭建和项目构建相关内容，已经能满足自动编译，自动部署等功能，但还差一项很重要的工作：自动化测试！

作为敏捷开发必不可少的工作，我们需要每次构建后都要跑一遍自动化测试，做全量回归，如果有需要还有冒烟测试。那么下面就来介绍如何实现每次构建项目后自动执行一个自动化测试任务。

一、节点管理

一般来说，测试都基于windows操作系统，比如用selenium编写web项目的自动化测试，用teststack.white编写client项目自动化测试。而我们的jenkins是通过docker容器安装部署的，实际是linux环境，这里就会遇到操作系统不兼容的问题。

事实上，不仅仅是需要测试才会遇到这种情况，如果我们要通过jenkins for docker部署一个.net framework 项目，也是同样的问题。

一、 插件

正式介绍使用之前，还需要准备安装一些插件，插件中心使用操作如下：

1.1 进入插件中心

1.2 更新插件

一、 关于持续集成

1.1 什么是持续集成

持续集成, 简称CI（continuous integration）.是一种软件开发实践，即团队开发成员经常集成他们的工作,每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

传统瀑布模型(水平划分项目阶段)：

最近项目组上持续集成，于是利用jenkins的docker镜像做二次开发，原本写好的Dockerfile在生成docker image后不小心被误删，一番折腾后终于找了回来。

如下图所示：

• jenkins为原始镜像
• auto-jenkins为使用Dockerfile生成的镜像

使用history命令查询auto-jenkins镜像所执行的所有命令：

项目使用Webpack打包，打包完成后生成一些asset，不管是本地开发还是jenkins持续集成，都希望自动上传这些asset到阿里云OSS，于是用nodejs写一个脚本：

1. upload_oss.js

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

var co = require('co'); 
var OSS = require('ali-oss') //阿里云oss模块
var fs = require("fs"); //文件模块
var path = require("path");

//---------------------------使用说明----------------------------
//获取命令行传入参数(第0个参数是node 第1个参数是js文件 第2个文件是本地文件夹路径 第3个是oss相对目录)
//命令格式举例： node  oss/upload_oss.js  ../../static/  /static/

var localPath = process.argv[2]
var remotePath = process.argv[3]
if(localPath == null || remotePath == null){
  throw new Error("缺少目录参数！");
  return
}

localPath = path.resolve(localPath); //本地目录
remotePath = path.resolve(remotePath); //OSS相对目录

if(!fs.existsSync(localPath)){
  throw new Error("本地目录"+ localPath + "不存在！")
  return
}


//上传列表
var fileDic = new Array();

//阿里云OSS配置
var client = new OSS({
  region: 'oss-cn-shenzhen',
  accessKeyId: 'xxxx',
  accessKeySecret: 'xxxx',
  bucket: 'xxxx'
});



console.log('---------上传OSS---------');
console.log('【Step1】 分析目录');

readDir(localPath)  

function readDir(filePath){  
  filePath = path.resolve(filePath);
  //遍历文件目录
  var pa = fs.readdirSync(filePath);
  pa.forEach(function(filename,index){  
    var file = path.join(filePath,filename)
    var info = fs.statSync(file)   
    //目录   
    if(info.isDirectory()){  
      readDir(file);  
    }
    //文件
    else {  
      //添加到上传列表
      var localDir = path.join(filePath,filename);
      var remoteDir = path.join(remotePath, localDir.replace(localPath,""));
      fileDic[localDir] = remoteDir; 
      console.log("add file：" + localDir)
    }     
  })  
}  

console.log('【Step2】 上传文件');

co(function* () {
    for(var localDir in fileDic)
    {
      var result = yield client.put(fileDic[localDir], localDir);
      console.log("upload from '" + localDir + "' to '" + fileDic[localDir] + "'");
    }
    console.log('【Step3】 完成');
  }
).catch(function (err) {
     throw new Error(err);
  }
);

2. package.json调用

1
2
3
4
5

"scripts": {
   "dev": "webpack-dev-server  --devtool inline-source-map --progress --color  --watch-poll",
   "test": "export NODE_ENV=test && webpack --progress  --color && node oss/upload_oss.js ../test_static/ /demo/test_static/",
   "prod": "export NODE_ENV=production && webpack --progress  --color && node oss/upload_oss.js ../static/ /demo/static/",
 }

1. 背景

公司前端项目从webpack1.X 升级到webpack2.X，加之技术需求和业务需求增长过快，开发人员没有充足时间深入学习webpack相关技术栈，导致很多配置失效、冗余或者无法辨别究竟有什么用途。

此外，我们基于docker-machine封装了vue、webpack、nodejs等前端开发环境到docker image，docker-machine本身基于Virtual Box，这种虚拟机+Docker的方式又挖了一把大坑。详情见：Docker搭建前端开发环境

综上，几种情况导致我们在docker中使用webpack-dev-server，没办法实时刷新，但在本机开发时却可以。

启动命令为：

系统：CentOS 7

1. 安装SS

参考 官网

1
2

yum install python-setuptools && easy_install pip
pip install shadowsocks

2. 开启多用户

1. 本地操作

• Hexo安装完成

• Git安装完成

• Git配置(Git Bash)

  1 2	git config --global user.name "你的用户名" git config --global user.email "你的电子邮箱"

• Git SSH Keys(Git Bash)

  1 2 3 4

  cd ~ mkdir .ssh cd .ssh ssh-keygen -t rsa

• Hexo安装hexo-deployer-git插件

2. Vultr配置

• 新建用户

  1	useradd git

• 创建authorized_keys

  1 2 3 4 5 6 7 8 9

  su git cd ~ mkdir .ssh cd .ssh vi authorized_keys # 复制本机 ~/.ssh/id_rsa.pub 内容到此 su #切换root chmod 600 /home/git/.ssh/authorized_keys chmod 700 /home/git/.ssh

• 安装Git和Nginx

  1 2 3

  su #切换root yum -y update yum install -y nginx git-core

• 创建Git仓库目录

  1 2 3 4 5

  su git cd ~ mkdir hexo.git cd hexo.git git init --bare

• 创建网站目录

  1 2 3

  su # 切换root mkdir -p /home/wwwroot/hexo chown git:git -R /home/wwwroot/hexo # 变更所有人

• 配置Git Hook

  1 2 3

  su git cd ~/hexo.git/hooks vi post-receive # 内容如下

  1 2 3 4 5 6 7 8

  #!/bin/bash GIT_REPO=/home/git/hexo.git # git 仓库 TMP_GIT_CLONE=/tmp/hexo PUBLIC_WWW=/home/wwwroot/hexo #网站目录 rm -rf ${TMP_GIT_CLONE} git clone $GIT_REPO $TMP_GIT_CLONE rm -rf ${PUBLIC_WWW}/* cp -rf ${TMP_GIT_CLONE}/* ${PUBLIC_WWW}

• 赋予执行权限

  1	chmod +x post-receive

• 禁止Git用户登陆控制台

  1 2 3

  su //切换root vi /etc/passwd #找到 git:x:1000:1000::/home/git:/bin/bash 把 /bin.bash 改成 /usr/bin/git-shell

• 配置Nginx

  1	vi /etc/nginx/conf.d/hexo.conf #内容如下

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

  server { listen 80 ; root /home/wwwroot/hexo; server_name XX.XX.com; # 域名 access_log /var/log/nginx/hexo_access.log; error_log /var/log/nginx/hexo_error.log; location ~* ^.+\.(ico|gif|jpg|jpeg|png)$ { root /home/wwwroot/hexo; access_log off; expires 1d; } location ~* ^.+\.(css|js|txt|xml|swf|wav)$ { root /home/wwwroot/hexo; access_log off; expires 10m; } location / { root /home/wwwroot/hexo; if (-f $request_filename) { rewrite ^/(.*)$ /$1 break; } } }

• 重启Nginx

  1	systemctl restart nginx

3. Hexo配置

一、什么是Scrum

Scrum就是3、3、5、5

二、第一个3——3个角色

1. Product Owner 简称PO

PO是获得授权的一个人

不知不觉搭进去大半个月，终于要迎来这个系列最后一篇文章。这段时间仿佛又回到几年前折腾android刷机的时候。不得不说，年纪大了真折腾不动。那么闲话少说直接开搞：

1. 什么是串流

Streaming (串流处理) 是指透过网际网路传输数位音讯或视讯。

说简单点，就是把设备A的音视频通过网络在设备B上展示，同时设备B无需安装、存储、下载和等待。

往前说，得说到互联网刚普及时出现的流媒体Streaming Media，让用户脱离下载等待，实现边下边看。给你们两个“古董”感受一下：rmvb和Real Player