版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/seacean2000/article/details/82861634
内容：必须具备代码回滚的能力。
场景：确保所有版本的代码都有回滚能力，在准生产或者QA环境演练，必要时在生产环境，必要时在生产环境用它来解决客户问题。
用法：清理代码并遵循几个简单步骤以确保可以回滚代码。
原因：如果没有经历过无法回滚代码的痛，还继续冒险地“修改-发布”代码，那么你可能会在某个时刻体会到这种痛苦。
要点：应用过于复杂或者代码发布太频繁所以不能回滚，这个借口无法接受。稳健的飞行员不会在飞机不能着陆的时候起飞，明智的工程师不会发布不能仅仅回滚的代码。
从任何版本回滚的成本几乎总比你想象的低，能够回滚的价值不可估量。大多数的回滚问题都出现在了数据库中，这里有一些简单的规则：
1.数据库结构的变更仅可以增加，必须到下一次版本的时候，才会清理明确不需要的列。
2.数据库变更脚本化并经过测试，不能手动操作，脚本必须在测试环境测试过之后，并在一定的负载下测试过。
3.限制应用中的SQL查询的使用，开发人员需要纠正所有含糊不清的查询，去除select * 查询，为所有的update添加列名。
4.数据的语义变化，开发人员不可以改变版本中数据的定义，除非先发布的代码可以处理新的语义状态才可以。
5.上线/下线，应用应该有一个基于外部配置的框架，该框架允许特定用户可以访问代码路径和功能。
在现在的公司遇到过一次这种情况，场面很夸张。