Etsy 每天多次发布代码，因此没有一次发布能让网站瘫痪

在21世纪初，发布网站新版本是一件大事：工程团队将数周的变更打包成一次推送，为此安排停机时间，并把发布日视为一切可能同时出错的时刻。Etsy 之前也是这么做的，有专门的部署团队把关，每当捆绑发布出错时，就得加班到深夜，因为没人能判断几十个同时上线的变更中，到底是哪一个导致了失败。

针对脆弱发布的标准做法是在发布前增加流程——更长的 QA 周期、更多的签字审批、更大的预发布环境——但这只是增加了延迟，并没有消除真正的风险：一次发布仍然会包含四十个功能，所以一个 bug 仍然会迫使工程师要么回滚所有内容，要么在压力下从整个批次中找出那一行有问题的代码。

持续部署：每天数十次小规模生产部署，每次都能轻易归因和回滚，取代了令人恐惧的发布之夜。

将发布批次缩小到每次部署一个或几个变更，让每次失败都能轻易归因并低成本撤销，而不是增加发布前的流程。

大规模捆绑发布会让单个 bug 淹没在几十个变更中，归因变得缓慢且代价高昂。

小批次意味着每次部署最多只有一个可能的原因，因此失败可以立即追踪。

小的变更可以单独回滚，因此糟糕的部署可以在不整体回滚的情况下撤销。

频繁的小规模部署将风险分散到许多低风险事件中，减少恐惧，并鼓励更小的批次。

当失败难以诊断时，缩小批次大小，而不是在发布前增加更多流程。

到2010年中，Etsy 自己的工程领导层报告每月大约有200次生产部署，并且还在增长（"7月份204次生产部署，比6月多约30%"），每次部署都足够小，可以追溯到单个工程师；到2014年，该公司公开提到每天约30次部署。