没有回退功用的设计是失败的设计

要一直能回退代码。确保一切的版本都可能回退，在一个阶段或qa环境中，要实践回退功用。在出产环境中，当必需用它解决突发事宜时，要运用回退功用收拾整顿代码，拟定多少简略的流程，确保可能回退本身的代码。
若是你尚未阅历过不克不及回退零碎的疾苦，那末若是接续玩火，不绝地迅速修复零碎，早晚会遇到这类问题。不要用应用太庞大或者代码发布太频仍作为托言，拒不插手回退代码的功用。一个理智的飞翔员，若是没有具有让飞机着陆的威力，就不会让飞机起飞。一个理智的程序员，若是不克不及让零碎在紧迫情况下回退代码，就不该该发布代码。
为了给接下来要讲的准则制造氛围，咱们应该在深夜围坐在一堆篝火周围讲可怕故事。咱们要讲的是经典的可怕故事，就是人们在屋子里听到了可怕的声音但其实不逃窜的事。那些无视一切告诫旌旗灯号的傻瓜就是咱们。作为程序员的上司和cto，咱们收到过几平每一个经理架构师和程序员的报告请示:应用太庞大了，不克不及进行回退。咱们本身对此也确信无疑。代码发布后已经泛起过几回间断或问题，先是猖獗地迅速修复，之后在统一天中获得一个热修复补钉，以便彻底恢复服务。咱们忍耐了这类小小的未便，由于咱们以为这个应用太庞大了，不克不及进行回退。

和以前发布的一切版本同样，一个主要的根蒂根基举措措施的版本发布后，也不克不及进行回退。此次发布简直是场劫难。清晨时，一切看起来都很好但当天亮了以后，流量激增，这个站点就招架不住了。若是回退，只会让多少用户不快乐，给本身留点儿小创痕，但不会有更糟的事情了。但咱们却不克不及回退，以是只好破费一成天的时间，为这个站点做点儿增加容量、限定流量等事情，以便在获得修复补钉以前连结一切依然运转。那天晚上咱们推出了一个补钉，其时站点并无流量，以是咱们以为问题已经修复了。只知其一，不知其二天早晨，当流量增加后，这个站点又起头有问题了。只好又在晚上打补钉…这类形式连续了一周多。
接连折腾了这么多天，到那周完毕时，一切人都已筋疲力尽。末了，咱们打了一个补钉，彻底疏忽以前的一切修改，终于使站点不变了。尽管从此次事故(包括指挥失误)中可以学到不少东西，但与本条准则关系最严密的是，无论咱们仍是客户所阅历的一切疾苦都是可以经由过程回退代码制止的。
过后总结经验经验，咱们确后不容许再发布没有回退功用的版本。其时除了发出这个书记外，咱们别无选择，客户没法容忍这类性子的问题，每一个程序员也都了解了这类请求的须要性。六周后，当下一个版本筹备好时，咱们已经可能进行回退了。咱们已经都认尴尬以降服的坚苦变得至关简略了。
下面列出了要具有回退功用需求注重的多少关键点。是的，回退的主要难点在于数据库。经由过程细心检査应用，逐个破除那些明明的问题，而后坚持多少简略的准则，一切团队都可能进行回退。
口数据库修改只能是増量的。在下一个撤废了列之间的依赖关系的版本发布前，只能增加数据库中的列或表，不克不及删除。一旦施行了这些标准，每一个版本都应该有一部分代码专门用于革除上一个版本遗留的不再需求的数据。
口ddl和dml必需剧本化且测试过。每一个版本中对数据库的修改必需经由过程剧本实现，而不克不及手动进行。此中应该包括回退剧本。如许做的起因有两点:1)团队需求在qa或某个阶段测试回退操纵，以便验证甚么都没有遗漏，不会阻碍回退；2)需求在必然负载的前提下测试剧本，确保在应用程序运用数据库时，它依然可能执行。
口对应用中的sql查询进行约束。开发团队需求解除一切sql语句中的歧义，删除一切 select*查询，而且给 update语句加之要更新的列的名字。
口数据的语义修改。在发布版本中，开发团队不克不及修改数据的界说。举个例子。票务表中的一列用于寄存状况旌旗灯号，此中有三个值assigned、fixed和 closed。在应用的新版本中，若是没有发布处置新状况的代码，就不克不及增加第四个状况。
口wire on/ire off。应该让应用结构化，使其能按照外部设置，让有些用户可能访问某个代码途径和功用，而有的用户则不克不及访问。这类设置可以寄存在设置文件中，也能够寄存在数据库表中既可能按照脚色付与访问权限，也可能按照随机百分比分配权限。有了这类结构，就可能让有限的用户对新功用进行beta测试，而且可能迅速地删除主要bug的代码途径，从而没必要回退整个代码。咱们获得的经验尽管凄惨，可是颇有网站制作代价，有了此次经验，咱们不再会发布不克不及回退的代码了。即便以后和其余团队一块儿事情，咱们也会如许请求本身的。可见，这些准则其实不庞大，而是至关简略，任何团队都可能应用它们，都能具有回退的威力。