@编者按:
由于公司内部存在的开发系统:内网开发–外网预发布–外网生产环境,程序员频繁的更新代码造成运维人员大量时间被占用,于是有了使用该开源工具的部署测试环节。在这里感谢该开源工具的作者,也希望我这边文档能多少帮助需要类似开发环境的技术人员。
1.部署:
开源项目地址:https://github.com/kelvv/my-deploy
操作视频教程:http://v.youku.com/v_show/id_XMTYxMjc0ODg3Mg==.html
基础环境:node 4.X.X以上版本
git 2.7.4及以上版本 sudo apt install git
安装:$ npm install -g my-deploy
2.配置:
创建配置文件
1 cd /data/test #进入到管理项目目录
2 mydeploy init #创建配置文件.mydeploy.json
clone代码到本地:
1 cd /data/test
2 git clone git@gitlab.apicloud.com:swht/test.git .
配置文件:
{
"mode": "pullwatch",
"url": "git@gitlab.apicloud.com:swht/test.git",
"localdir": "/data/test",
"interval": 3000,
"branch": "dev",
"hook": {
"postchanged": "pm2 reload test"
},
"rules": [
{
"type": "commit",
"value": "^Reload"
}
]
}
说明:mode–模式,分为pullwatch、webhook两种模式
url–管理项目仓库地址:一般存放在github、gitlab或自建gitlab仓库中
localdir–本地管理项目路径;
interval–时间间隔,指mydeploy间隔多少时间去检测git仓库是否有更新,默认3000ms,建议内部开发服务器上使用pullwatch模式,主动隔一段时间去git pull最新代码;
branch–分支,指开发代码库的分支,建议分为几个分支:dev–pre–master。如果内部开发人员较多,可以创建自己的分支,由专门的代码审查人员进行分支合并;
hook–代码更新完之后需要执行的系统命令,借用pm2进行项目重启操作;
rules–检测更新的规则,即根据git提交的类型(commit、tags)、注释信息进行更新;
备注:mydeploy start -c /data/test/.mydeploy.json -p 3110 自定义启动方式,-c 指定配置文件的路径,-p指定监听的端口
mydeploy start #启动默认的监听端口为3100
@南非波波 github:https://github.com/swht