发布时间：2022-09-27 00:00   您所在的位置： 网站首页 > 新闻资讯 > 经验杂谈

要一直能回退代码。确保所有的版本都可以回退，在一个阶段或QA环境中，要实践回退基本功能。在生产环境中，当必须用它解决突发事件时，要使用回退基本功能整理代码，制定几个简单的流程，确保可以回退自个的代码。

假如你还没有经历过不能回退系统的痛苦，那么假如继续玩火，不停地迅速修复系统，早晚会遇到这种问题。不要用应用太复杂或者代码发布太频繁作为借口，拒不加入回退代码的基本功能。一个明智的飞行员，假如没有具备让飞机着陆的能力，就不可能让飞机起飞。一个明智的程序员，假如不能让系统在紧急情况下回退代码，就不应该发布代码。



为了给接下来要讲的原则制造气氛，咋们应该在深夜围坐在一堆篝火周围讲恐怖故事。咋们要讲的是经典的恐怖故事，便是人们在房子里听到了恐怖的声音但并不逃跑的事。那些忽视所有警告信号的傻瓜便是咋们。作为程序员的上司和CTO，咋们收到过几平每个经理架构师和程序员的汇报:应用太复杂了，不能开展回退。咋们自个对此也确信无疑。代码发布后曾经出现过几次中断或问题，先是猖狂地迅速修复，之后在同一天中获得一个热修复补丁，以便完全恢复服务。咋们忍受了这种小小的不便，由于咋们认为这样的应用太复杂了，不能开展回退。

和以前发布的所有版本一样，一个主要的基础设施的版本发布后，也不能开展回退。这次发布简直是场灾难。凌晨时，一切看起来都很好但当天亮了以后，流量激增，这样的站点就招架不住了。假如回退，只会让几个顾客不愉快，给自个留点儿小伤痕，但不可能有更糟的事情了。但咋们却不能回退，故此只好花费一整天的時间，为这样的站点做点儿增加容量、限制流量等工作，以便在获得修复补丁以前保持一切仍然运行。那天晚上咋们推出了一个补丁，当时站点并没有流量，故此咋们认为问题已经修复了。第二天早晨，当流量增加后，这样的站点又开始有问题了。只好又在晚上打补丁…这种模式持续了一周多。

接连折腾了这么多天，到那周结束时，所有人都已精疲力竭。最后，咋们打了一个补丁，完全忽略以前的所有修改，终于使站点稳定了。虽然从这次事故(包含指挥失误)中可以学到好多东西，但与本条原则关系最紧密的是，不管咋们还是客户所经历的所有痛苦全是可以通过回退代码防止的。

事后总结经验教训，咋们确定日后不允许再发布没有回退基本功能的版本。当时除了发出这样的布告外，咋们别无选择，客户无法容忍这种性质的问题，每个程序员也都理解了这种需求的必要性。六周后，当下一个版本准备好时，咋们已经可以开展回退了。咋们曾经都认为很难克服的困难变得相当简单了。

下边列出了要具备回退基本功能必须要注意的几个关键点。是的，回退的主要难点在于数据库。通过仔细检査应用，一一排除那些明显的问题，然后坚持几个简单的原则，所有团队都可以开展回退。

口数据库修改只能是増量的。在下一个废除了列之间的依赖关系的版本发布前，只能增加数据库中的列或表，不能删除。一旦实施了这些标准，每个版本都应该有一部分代码专门用于清除上一个版本遗留的不再必须要的数据。

口DDL和DML必须脚本化且测试过。每个版本中对数据库的修改必须通过脚本实现，而不能手动开展。其中应该包含回退脚本。这样子做的原因有两点:1)团队必须要在QA或某个阶段测试回退操作，以便验证什么都没有漏掉，不可能妨碍回退；2)必须要在一定负载的条件下测试脚本，确保在应用程序使用数据库时，它仍然可以执行。

口对应用中的SQL查询开展约束。开发团队必须要消除所有SQL语句中的歧义，删除所有SELECT*查询，并且给UPDATE语句加上要更新的列的名字。

口数据的语义修改。在发布版本中，开发团队不能修改数据的定义。举个例子。票务表中的一列用于存放状态信号，其中有三个值assigned、fixed和closed。在应用的新版本中，假如没有发布处置新状态的代码，就不能增加第四个状态。

口WireOn/ireOff。应该让应用结构化，使其能依据外部配置，让有一些顾客可以浏览某个代码路径和基本功能，而有的顾客则不能浏览。这种设置可以存放在配置文件中，也可以存放在数据库表中既可以依据角色赋予浏览权限，也可以依据随机百分比分配权限。有了这种结构，就可以让有限的顾客对新基本功能开展beta测试，而且可以迅速地删除主要bug的代码路径，从而不用回退整个代码。咋们获得的教训虽然惨痛，不过很有网站开发价值，有了这次教训，咋们再也不可能发布不能回退的代码了。即使以后和其他团队一起工作，咋们也会这样子需求自个的。可见，这些原则并不复杂，而是相当简单，任何团队都可以应用它们，都能具备回退的能力。

本文章由新概念互动原创，如没特殊注明，转载请注明来自：http://www.jianzhan0.com/jingyand/72157.html

上一篇：尽可能使用异步通信

下一篇：Intranet 功能的长处