从零打造自己的CI/CD系统|php项目部署v3版本

从零打造自己的CI/CD系统|php项目部署v3版本

新搬家了，暂时没有网，今天就纯文字描述下吧，今天我们继续接着昨天的话题进行完善，大家看了昨天的文档，会看出来当前存在不少问题，那今天我们就把这些问题解决下。

github仓库地址[1]

环境需求

参考上两篇文档:

从零打造自己的CI/CD系统|php项目部署v1版本

从零打造自己的CI/CD系统|php项目部署v2版本

当前存在的问题

•命令行传递参数过多，稍不注意就可能会出错，而且只能是ops才能操作，不能交付给开发自助发布•本地执行和远程执行在同一个roles里，整体不是很完美•服务么有重新加载(视语言而定)•没有实现滚动更新•没有实现通知机制(甭管是失败还是成功)

首先我们来看下命令行传参的问题

从上面两篇文章我们能看得出，命令行传递的参数有些是在项目的生命周期内是固定不变的，这个时候就没有必要进行每次的传入来，可以写到一个文件里，运行roles的时候进行加载即可,我们看看那些是可以抽出来的固化的参数:

可以固化的参数

•pname•env•git_repo•laravel_releases•smoketest_url

不可以固化的参数

•branch

抛开生产环境来说，我们需要支持研发在非主干分支上进行自测工作，所以传递分支就成了必备功能。

本地操作和远程操作拆分

拆分使得本地操作和远程操作更清晰，roles的复用性更强。

本地操作

•directory create•git clone•compile•deploy(upload)•pre-commit(非必须放在这里做,理论上入仓库之前就需要做)•code-style check•unit-test

远程操作

•sync•symlinks•disable slb•disable monitor•reload(restart)•verify•enable slb•enable monitor•notify

服务重新加载

这一步看情况而定，其实PHP并不需要重新加载，但是如果开启opcache的情况下，可能会导致代码不生效的问题，所以如何操作要看你的场景是什么样的。

滚动更新支持

其实这里引入一个参数即可，就是serial， 这个参数可以设置百分比，也可以设置为数字，默认不设置的话，整个task的执行是并行的(默认并行数是在ansible.cfg里定义的), 比如serial:1, 意思就是一台一台的操作，这样的话就能实现我们想要的滚动更新的操作，但是，这里要注意，及时我们实现里滚动更新，并不意味着已经实现里零宕机发布，因为发布的上下文里有很多东西是需要适配的，比如前面的SLB的超时时间, 比如注册中心的健康检测周期等等。

关于通知机制

一个部署操作，甭管是成功的还是失败的，我们都希望有一个反馈，这个时候不能单纯的靠人工去盯着，所以整个流程里我们需要通知，成功里就正常通知，失败的话，不单单要通知，还要有对应的补偿机制。所谓的补偿机制是要清理当前不成功操作的所有痕迹，然后重新回滚到正常的哪一个版本，然后在通知进行人工干预。

后续跟进文档

•为发布添加一个web页面操作入口(引入Jenkins)，这其中针对Jenkins会穿插讲解一些其他的内容•回滚roles操作的编写•如何秒级别创建job并关联对应的项目的palybook文件•总结篇

总结

一个好的发布系统需要考虑的边界点实在是很多很多，前面我们也提到过文件分发，也包括上千台机器的情况下如何快速的分发，并保障可用性，还有就是灰度，加油吧，要学的还有很多很多。

引用链接

[1] github仓库地址: https://github.com/zhuima/kylin