记一次线上回滚代码的经历

下面将采用文字描述重现整个流程的方式,来进入到这次回滚代码的经历中…

说明

  • 代码管理: 采用git及git flow来管理代码
  • 上线代码: 上线代码是通过一台专门的合代码机器,用脚本选取当前已经处于可以上线状态的进行合代码上线。
  • 合代码脚本原理:通过脚本自动完成git flow feature finish、git flow release start、git flow release finish、给当前最新代码打上新的tag等需要手动输入的命令,及一些其他流程控制逻辑。
  • 上线: 通过web界面操作,自动化将线上代码更新为最新代码,然后完成其他操作

问题背景

这是一个繁忙的一天,既要配合内测,又要处理紧急问题,所有的事情都好像没法按照常规处理,每件事情都是重要且紧急的。临近下班才开始合代码上线。处于可以上线状态的工单有A(bitdata)、B(23qi)、C(品牌)(该部分不用测试,由于合并了工单F(yiyuan),所以依赖测试中的F)、D(伪)、E(rspec) 4个工单,其中A、B、C存在冲突,A/B是前端代码冲突(前端同学在合代码时发现,于是将A、B工单的代码合在一起解决了冲突),B/C是后端代码冲突。且B、D工单必须当日上线。

流程

由于时间比较匆忙,没有像以前一样核对每个需要上线的工单,直接通过脚本抓取可以上线的工单,然后开始合并代码,合并过程中,提示了B、C工单代码冲突,于是我又将B、C工单git分支合并在一起解决了冲突,然后push到远程(注意:此时C中已经存在A、B、C、E所有工单的代码了)。然后再次合代码,合并完成之后,由于合并完成之后的工单会提示前置未上线,此时才注意到工单C依赖的F。于是将工单C剔除,重新合并代码,此时并未意识到前面解决冲突时,其实已经手动将C和F代码合并到了B工单代码中,于是部署上线(在部署过程中,我们一般会先选择一台,连到上面,观察日志),并未发现错误,于是将其余的几台机器也全部更新了。当全部更新完毕之后,发现后台页面更新时500了,此时观察到日志报了一个错误,由于该错误需要修改代码,于是回滚线上所有代码,然后修改代码,重新合代码,注意此时仍然未发现C和F的代码未被剔除。于是再次更新。此时仍然是选择一台,并连接上去观察日志,这次观察时间稍长一点,突然发现报了一个只有C、F分支中才会出现的错误(事后分析C、F中的不会出现该错误,原因未知),此时才意识到C和F未能够剔除去。于是又将刚才更新的那台机器代码回滚。此时经过讨论,由于F工单测试时间比较长,选择了通过将本地的(合代码机器上的git仓库和开发机上的git仓库)代码回滚,将C、F的代码完全剔除后重新合并上线(git push -f)。剔除完毕后,经过仔细的检查,所有事情都没有问题了。于是上线部署,此时问题又来了,线上代码无法更新,此时叫来运维同学帮忙查看,发现前一步线上代码回滚的代码又自动回到回滚前的代码(为何会自动回到回滚之前的代码版本,原因未解),导致更新冲突。于是,运维同学帮忙将线上所有代码会退到第一次上线之前的版本,此时,可以通过web界面操作部署上线了,重复上述部署线上步骤,上线之后一切运行正常。

总结和思考

出现错误的地方

  • 工单C前置F未到达可以上线状态,C处于可以上线状态
  • 多个工单分支出现冲突时,相互之间合并代码
  • 合并代码时未检查相关工单的情况
  • 剔除对应工单时,未检查剔除之后的代码是否包含剔除工单的分支代码,完全依赖脚本
  • 出现问题时,未将当时日志进行截图保存,不利于事后分析

思考

  • 当事情很多,如何规划事情完成顺序很重要,时间管理应该做好。
  • 对于多个事情,都是重要且紧急的,应该如何处理?总能分个紧急程度吧!不要并行执行!并行不是一般人能够玩的。
  • 当做一件事频繁在出错,那么这个时候,你就该放下休息休息,慢慢理一理了
  • 做事时,有些必要的步骤不要因为忙就省略,或许就因为你少做的几分钟,需要用几小时来作为代价。预速则不达!

标签:

专题:

发表于2017-03-19 14:59:20,最后修改于2019-08-02 18:42:12。

本站文章欢迎链接分享,禁止全文转载。


« 上一篇 通过案例学习如何在mac中抓取http请求信息 下一篇 » 关于我

推荐阅读

Big Image