最近跟同事们争论的一个问题：一个应用发布平台，版本回滚是否应该支持把配置一同回滚？
针对这个事情的讨论，我们分成了两派，一边是赞成派，一边反对派。
赞成派的观点
“举个真实例子，我这边在配置健康检查的时候配置错了或者端口改错了，导致线上不可用，我想快速回滚线上Pod。”
“主要是改了很多东西，不知道改了啥，想先快速恢复线上环境。”
所以强烈坚持应该一起回滚这一观点！
反对派的观点
“镜像版本的回滚和配置的回滚应该是分开的，不能说回滚一下，把配置也自动给回滚了。 ”
“举个例子： 我想回滚到前几个版本，但是这几个版本之间，有修改过一些配置，比如运维告诉我，要换个端口，然后这几个版本不涉及配置问题，就是一些bug fix。假如回滚把配置也回滚，由于运维把域名回源端口换了，并且已经通知过我们改了。那么回滚后就会出现域名无法访问的问题。 “
镜像是构造阶段的产物，而配置是运行时所需，配置在运行的过程中会随时改动，而镜像构建出来就不会变。
所以强烈坚持配置不能一起回滚这一观点！
我个人观点
其实我就是那个反对派！
我认为不能为了解决一个问题，而引入另一个问题。
如果一个产品功能存在无法替用户做决定的情况下，那么就不应该替用户做任何决定，可以把选择权交给用户，例如回滚的时候给用户选择是否回滚配置。如果一个功能可提供可不提供，而默认提供会给用户造成不必要的问题，那首选就是不要提供。
竞品的做法
有时候我们也可以看看竞品是怎么做的。当然，也只是参考，毕竟不是竞品做的就是正确的。
作为Railway的铁粉用户，我们来看看Railway是如何抉择的。
如下图，这是我在Railway上部署的博客系统。
在当前版本，我加入了GitHub授权登录才能对文章评论，所以配置项我加入了GITHUB_CLINET_ID和GITHUB_CLIENT_SECRET两个新的配置项。
现在我操作回滚到一个月前的一个版本。
回滚完成：
查看配置：
可以看到，配置并没有任何回滚。所以Railway的选择是，不回滚配置。
或许我们对配置的理解不一样
仔细思考赞成派的话，或者我们对配置的理解不一样。
健康检查这个例子，配置是针对容器的，不属于应用配置，属于平台配置，平台提供的部署配置。套到k8s的话，就是k8s提供的Deployment配置。跟应用配置是两码事。
如果是这样的话，那确实应该随镜像一起回滚，不但没有任何副作用，这样才能确保回滚能正常部署起来，因为是平台部署配置！
本文经「原本」原创认证，作者吴就业，访问yuanben.io查询【2Y5HRVZB】获取授权信息。