要一向能回退代码。确保所有的版本都可以或许回退，在一个阶段或QA情况中，要实践回退功效。在临盆情况中，当必需用它解决突发事宜时，要应用回退功效整顿代码，制订几个简略的流程，确保可以或许回退本身的代码。

假如你还没有阅历过不克不及回退体系的苦楚，那么假如持续玩火，一直地敏捷修复体系，迟早会碰到这种问题。不要用运用太庞杂或者代码宣布太频仍作为托言，拒不参加回退代码的功效。一个明智的飞翔员，假如没有具备让飞机着陆的才能，就不会让飞机腾飞。一个明智的法式员，假如不克不及让体系在紧迫情形下回退代码，就不该该宣布代码。

为了给接下来要讲的原则制作氛围，我们应当在深夜围坐在一堆篝火四周讲恐惧故事。我们要讲的是经典的恐惧故事，就是人们在房子里听到了恐惧的声音但并不逃跑的事。那些疏忽所有警告旌旗灯号的傻瓜就是我们。作为法式员的上司和CTO，我们收到过几平每个司理架构师和法式员的报告请示:运用太庞杂了，不克不及进行回退。我们本身对此也确信无疑。代码宣布后曾经涌现过几回中止或问题，先是猖狂地敏捷修复，之后在统一天中获得一个热修复补丁，以便完整恢复办事。我们忍耐了这种小小的未便，因为我们以为这个运用太庞杂了，不克不及进行回退。

和之前宣布的所有版本一样，一个重要的基本举措措施的版本宣布后，也不克不及进行回退。此次宣布的确是场灾害。清晨时，一切看起来都很好但当天亮了今后，流量激增，这个站点就抵挡不住了。假如回退，只会让几个用户不愉快，给本身留点儿小伤痕，但不会有更糟的工作了。但我们却不克不及回退，所以只好消费一成天的时光，为这个站点做点儿增长容量、限制流量等工作，以便在获得修复补丁之前坚持一切仍然运行。那天晚上我们推出了一个补丁，其时站点并没有流量，所以我们以为问题已经修复了。第二天凌晨，当流量增长后，这个站点又开端有问题了。只好又在晚上打补丁…这种模式连续了一周多。

接连折腾了这么多天，到那周停止时，所有人都已精疲力竭。最后，我们打了一个补丁，完整疏忽之前的所有修正，终于使站点稳固了。固然从此次变乱(包含批示掉误)中可以学到许多器械，但与本条原则关系最慎密的是，无论我们照样客户所阅历的所有苦楚都是可以经由过程回退代码避免的。

过后总结经验教训，我们肯定日后不许可再宣布没有回退功效的版本。其时除了发出这个书记外，我们别无选择，客户无法容忍这种性质的问题，每个法式员也都懂得了这种请求的需要性。六周后，当下一个版本预备好时，我们已经可以或许进行回退了。我们曾经都以为难以战胜的艰苦变得相当简略了。

下面列出了要具备回退功效须要留意的几个症结点。是的，回退的重要难点在于数据库。经由过程细心检査运用，一一消除那些显著的问题，然后保持几个简略的原则，所有团队都可以或许进行回退。

口数据库修正只能是増量的。鄙人一个破除了列之间的依附关系的版本宣布前，只能添加数据库中的列或表，不克不及删除。一旦实行了这些尺度，每个版本都应当有一部门代码专门用于消除上一个版本遗留的不再须要的数据。

口DDL和DML必需剧本化且测试过。每个版本中对数据库的修正必需经由过程剧本实现，而不克不及手动进行。个中应当包含回退剧本。如许做的原因有两点:1)团队须要在QA或某个阶段测试回退操作，以便验证什么都没有漏失落，不会妨害回退；2)须要在必定负载的前提下测试剧本，确保在运用法式应用数据库时，它仍然可以或许履行。

口对运用中的SQL查询进行束缚。开辟团队须要清除所有SQL语句中的歧义，删除所有SELECT*查询，而且给UPDATE语句加上要更新的列的名字。

口数据的语义修正。在宣布版本中，开辟团队不克不及修正数据的界说。举个例子。票务表中的一列用于寄存状况旌旗灯号，个中有三个值assigned、fixed和closed。在运用的新版本中，假如没有宣布处置新状况的代码，就不克不及添加第四个状况。

口WireOn/ireOff。应当让运用构造化，使其能依据外部设置装备摆设，让有些用户可以或许拜访某个代码路径和功效，而有的用户则不克不及拜访。这种设置可以寄存在设置装备摆设文件中，也可以寄存在数据库表中既可以或许依据脚色付与拜访权限，也可以或许依据随机百分比分派权限。有了这种构造，就可以或许让有限的用户对新功效进行beta测试，并且可以或许敏捷地删除重要bug的代码路径，从而不必回退全部代码。我们获得的教训固然惨痛，然则很有网站扶植价值，有了此次教训，我们再也不会宣布不克不及回退的代码了。即使今后和其他团队一路工作，我们也会如许请求本身的。可见，这些原则并不庞杂，而是相当简略，任何团队都可以或许运用它们，都能具备回退的才能。