Instagram的持续部署实践

Instagram最近发布了一篇文章来介绍他们的持续部署（Continuous Deployment，简称CD）流水线。借助这套CD流水线，工程师们能更快地将代码推送至生产环境，更方便地找到有问题的改动，以及将代码随时保持在可发布的状态。在一段时间频繁的迭代之后，最终其背后的核心原则主要包括：

• 拥有高质量的测试集
• 拥有快速定位问题改动的能力
• 拥有可视化部署流程的能力
• 拥有可行的回滚（rollback）计划

在Instagram使用这套CD流水线之前，发布流程是由一堆脚本与手动步骤混杂而成。通常有一台机器会先被部署并用来进行可用性测试（Sanity），然后剩下的机器才会被依次部署。Sauron是一款基本的发布跟踪系统，由一套UI和一个数据库构成，用于可视化之前发布的结果。整个发布流程使用Fabric来实现基于SSH的自动化部署。

2013年，Facebook收购了Instagram，并开始将其基础设施从AWS上迁移至Facebook自己的数据中心。据Facebook产品工程师（Production Engineer）、前文作者Michael Gorven介绍，Instagram拥有几千台机器，却能做到每天部署30至50次代码。之所以规模庞大并持续增长的基础设施没有妨碍代码的发布，主要归功于Facebook用于发布的一套分布式SSH系统。

持续部署最初遇到的两个阻碍，分别是脆弱的测试集，以及一大堆等待发布的改动。其中，前者主要由低效及不稳定的测试造成，而后者则由失败的部署造成。基础设施的规模越大，部署时出错的几率越高，对应的每次部署所携带的改动就越多，从而使部署更容易出错。就解决方法来说，脆弱的测试集主要靠人为优化，而部署的试错则可以用所谓的“金丝雀部署”（Canary Deployment）来解决。在金丝雀部署中，改动只被推送到一部分离线服务器上并进行自动化测试，然后根据测试结果来决定这次部署是继续还是回滚。

在此基础上，Instagram在CD流水线中加入了更多智能，使其能够判断决定哪些改动可以发布上线。通过与Jenkins的集成，CD流水线可以根据测试结果将改动分为“好”与“坏”两类，并直接将分类结果推送至Sauron，以供利益干系人（stakeholders）查阅。

Sauron会显示每一个改动及其发布状态，并会将包含作者信息的发布动态自动推送到一个聊天频道；同时，改动的作者将会收到一封邮件与一条短信，来告知他们所做的改动正在发布。稍后，所有发布动态将被记录在数据库中，以便日后做各种可视化分析。

在越过最初的障碍后，CD流水线又面临一个更大的挑战，即数据库的迁移，包括数据的迁移与表结构的迁移。一般来讲，数据库迁移的解决方案大多是根据各自的产品和基础设施而制作的定制化方案，而Instagram也不例外。每次将数据迁移时，Instagram的大致做法为：

1. 将一个在线数据片（shard）慢慢复制至新的位置，直至两者的区别足够小
2. 使用开关将老的数据片下线
3. 将仅剩的区别搬到新的数据片上
4. 使用开关将新的数据片上线

Gorven还详细介绍了如何使用开关（feature toggles）来做表结构的迁移。

首先，我们更新本发布代码，使其能够同时读写新老版本的数据。然后，我们复制一份表结构并对其进行改动，比如添加几列，并将数据写操作同时作用于新老表结构。如有必要，我们将通过批处理，将现有数据从老的表结构更新到新的表结构。最终，我们会将数据读操作从老版本数据切换到新版本数据，而保持写操作不变。这个阶段会持续一段时间，以防万一，直到我们将数据读写操作都切换到新版本数据上，完成整个迁移。

作为后续，Instagram的发布工程团队将会把注意力放在提高甄别问题改动的能力，同时尽量保持发布的速度不受影响。

查看英文原文：Continuous Deployment at Instagram

感谢夏雪对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至[email protected]。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们。