初步使用gitlab-ci

之前,自己一个人跟一个项目,随着项目运营起来,收益的需求很急,运营方面的开发、以及产品功能的开发、项目系统的维护,修Bug,简直就是一个死循环。对于代码质量,根本没时间理会,也没折腾。

但是从项目维护以及现在的情况来看,以及现在的项目,更新维护也是会有出错的地方。所以代码质量,项目部署更新,还是要下功夫的。

刚开始的时候麻烦,后面就轻松了

Ansible

之前用过 ansible,ansible用起来很方便,门槛不高,只要看一下ansible的使用文档,看一下例子,甚至上网找一下例子,就可以把 ansible的部署配置文件写完。

流程大概是这样:

1. 本地写好部署文件
2. 根据配置文件,通过rsync 项目文件到对应的目录
3. ssh到远端,然后执行一系列的操作
4. 例如配置文件,创建虚拟环境,启动项目,重启等等

但是这样会有什么问题呢?

  1. 操作是在本地完成,需要另外弄一个项目来维护这个部署配置文件,就算嵌在代码文件里,感觉不是很合适。
  2. 操作都是手动完成,多个环境的话,容易乱

虽然我用的 Ansible不久,并且我还不是很熟悉使用,我觉得方便易用、依赖不高,门槛相对较低,对于小型的项目还是很适合的。

gitlab-ci使用

流程大概是这样:

1. 需要配置一个`Runner`作为执行命令的机器
2. 根据gitlab-ci文档,编写`.gitlab-ci.yml`文件
3. 更新gitlab项目代码,自动出发项目部署
4. 将项目clone一份到runners上执行
5. 更新配置后,test代码后,通过`rsync`上传代码到机器上
6. ssh到远端,执行一系列操作
7. 例如创建虚拟环境,启动项目,重启等等

最近在公司使用gitlab-ci,本身其他项目有使用,已经有一个共享的 Runner了,并且有一个python3.5的镜像可以使用,所以,我完成的操作大概是写yml文件了。

遇到的问题

  1. SSH远程操作使用引号问题

    使用 ssh 机器名 后,后面跟着一串命令操作,如果使用双引号的话,操作会 Runner上解析,如果遇到路径变量相关的,可能会因为没有找到对应路径,而导致执行操作有误。例如:

ssh host_name "cd /home/server/path/ && for n in $(find . -maxdepth 1 -type d | grep "project_name-*" | sed "s/\.\///"); do cd $n; touch reload; cd ..; done"

实际上,for里面,find的当前路径,根本不是远端,是Runner上的。

后来可以改成单引号

ssh host_name 'cd /home/server/path/ && for n in $(find '"."' -maxdepth 1 -type d | grep '"project_name-*"' | sed '"s/\.\///"'); do cd $n; touch reload; cd ..; done'

这样遇到有变量的,其实就是做一个字符串拼接操作,不然使用",直接在 Runner上解析了

参考地址

优点

  1. 和git使用结合,更新代码自动触发相应的操作,这个需要有一定的git规范、git-flow规范
  2. 多个环境只需要修改 Gitlab-ci的变量就可以了
  3. 可以做很多自动化操作来提升代码质量:测试、质量报告、语法检测

缺点

  1. 门槛比较高:需要额外了解shell语法、甚者是docker镜像
  2. 自己配置一个 Runner,估计不好受,教程虽简单,但可能坑很多

总结

其实我也是学了一点gitlab-ci的皮毛,后续根据自己项目需求,还需要不断踩坑,学习更多关于ShellDocker 的知识,了解更底层的原理、结构。