今天我们来聊聊rollback, 前面的文档中我们铺垫了发布的时候远程机器上保留了几份记录,在回滚操作的时候这个就派上用场了,接下来我们来概括下回滚整个流程和需要注意的事项。
github仓库地址[1]
参考上几篇文档
从零打造自己的CI/CD系统|php项目部署v1版本
从零打造自己的CI/CD系统|php项目部署v2版本
从零打造自己的CI/CD系统|php项目部署v3版本
从零打造自己的CI/CD系统|使用Jenkins作为操作入口
前面我们也说了,部署都是通过软链方式实现的,在全量发布的场景下,回滚的操作其中的一步就是把对应的软链切回上一个版本,这个相对来说复杂度没那么高。
在增量发布的情况下,什么情况下会用到增量发布呢,我遇到的是为了解决页面白屏问题(为什么会白屏,因为对应的js已然找不到了),当时为了解决这个问题,在发布系统上做了兼容,也就是确保新旧版本都在,这样的话,用户访问基本不会有什么问题,但是出了问题,快速回滚的话,相对全量发布的场景,却没有那么容易了,我们需要考虑如何设计发布的时候上一个版本的保存和软链切换的时机等条件。
为什么要特别提到这一点,如果没有清理的情况下,再次发布出问题需要回滚的时候,那回滚就会无效,无效的原因是因为当前在远程机器上存在的这个版本是有问题的。
•获取需要回滚的版本(时间戳对应的目录)•获取当前的版本(时间戳对应的目录)•切换软链•重启服务(根据场景可选)•端口存活检测•smoketest•清理当前的版本•通知
当然我们回滚的操作也是需要滚动的,确保服务一直对外提供,不能因为操作回滚二次造成线上服务不可用,回滚的操作逻辑相对来说还是比较精简的,而且都是远程操作,发布机器上或jenkins上点击触发即可。
[1]
github仓库地址: https://github.com/zhuima/kylin