Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

为程序发布过渡版本

  当代码部署到线上后,如果发现一些小问题可以快速打个补丁 hotfix 掉。但有时一些问题并不是分分钟能搞定的,甚至根本不知道问题出在哪儿。这种情况下,最快的解决办法就是将线上的代码回滚到上一个可以稳定工作的版本,线下再来修 BUG。
  每次部署代码通常都会有个版本的概念,每个版本的代码都是独立的,所以代码层面的回滚很容易。但一套程序正常工作并不仅仅是代码而已,数据才是核心。而且数据这种东西并没有版本的概念,它是无法回滚的。
  举个例子吧。假如旧版程序是 v1,数据库中原本有一个枚举类型的字段有 1、2、3 这三个取值。后来由于产品新增了功能,开发了新程序 v2,并且给数据库中的这个字段添加了 4 这个取值。v2 的程序发布后,数据库中的这个字段就会产生 4 这个取值。此时突然发现线上程序有问题,怎么办?如果回滚到 v1 版本,v1 的程序可能因为没有处理 4 这个取值而抛出异常。于是就只能硬着头皮去解决线上问题。
  我们应该尽可能地避免发布这种无法回滚的程序,这种操作太危险了。比如上面的例子中,如果要发布 v2 这个版本的程序,那么就应该给 v1 先打好疫苗。比如在 v2 发布前,先给 v1 更新一个过渡版本,让其对 4 这个字段取值做一些基本处理。在这个过渡版本发布到线上并跑稳定后再发布 v2 的程序。
  上面的例子只是一个最简单的情况,实际业务的复杂程度往往超出我们的想象。有时候新版的程序可能会对数据结构做很大改变,于是可能存在一些旧版的疫苗程序比业务本身还复杂的情况。但即便是这样我们也应该做好这个过渡处理,否则一旦出问题就要呵呵了。
  我一扯到数据库,很多前端开发者就表示没有兴趣了?其实存储这东西和数不数据库没什么关系,前端也有 localStorage 和 Cookie 等一些列可用于数据存储的地方。所有可以持久储存的地方都需要考虑这个过渡问题。后端由于经常和数据打交道,对这种问题也许我不说大家都明白。而前端往往不会考虑到这种问题,最后掉进自己挖的坑里。
网名:
3.80.32.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^