共计 1779 个字符，预计需要花费 5 分钟才能阅读完成。
Etsy 是怎么做到每天 50 次以上部署的，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
Daniel Schauenberg 在伦敦 QCon 大会上描述了 Etsy 是如何做到每天 50 次部署的。Etsy 以其 DevOps 和持续交付的实践而闻名。一个完全自动化的部署管道、全面的应用监控和基于 IRC（互联网中继聊天）的协作是能达到这个变更频率的同时又保持最小风险的重要因素。
Etsy 的开发策略是反复围绕着做许多小的、连续的变更。这样做的一个直接后果就是需要每天做很多次部署。用 Daniel Schauenberg 的话来说，在任何时刻每个 Etsy 的开发人员都需要知道下面这个问题的答案：“我现在有足够的信心来部署这个变更吗？”。为了能够每次都可以轻松部署，Etsy 采取了一系列的工具和做法：强制基于 IRC 的沟通、开发者虚拟机、持续集成、一键式部署、全面的应用和系统监控、对于开发和运营团队都采取免责怪的事后检查（post-mortem）和随叫随到的政策。
每个开发人员都拥有自己的通过 Chef 配置的 KVM（基于内核的虚拟机）。在线上运营中使用的 cookbooks 也同样地用在了开发人员的虚拟机中，这意味着每个开发者都有自己完整的 Etsy 栈。任何人都可以通过 Virtual Madness(一个可以实现整个过程自动化的 Web 应用) 来提供一个虚拟机。
在持续集成方面，Daniel 解释了 Try 是如何成为所有过程的核心。Try 是一个工具，它允许开发人员在 Jenkins(在 Etsy 中使用的持续集成工具) 中测试他的代码变更，而不需要先提交到 trunk 中。Try 有助于保持 trunk 干净从而实现可部署，而同时让开发人员能够快速、可靠地测试他们的变更。CI(持续集成) 集群必须强大到足以支持 150 名工程师，以及每天超过 14000 个测试集的运行。LXC(Linux 容器）会平衡工作的负载，它们还提供了隔离机制，确保不同测试的执行之间不会冲突。
部署管道会经过 Princess，或者工作台，这是一种上线前的环境。Princess 的所有意图和目的就是上线环境，但只有 Etsy 的员工可以访问它。Deployinator 是由 Etsy 构建并使用的部署工具，提供一键式部署。
配置标志，也被称为功能标志，是部署过程中的一个主要组成部分。通过其功能 API，Etsy 能够做 A / B 测试，即完全启用或者禁用某一功能或一个给定功能的变体。
监控是 Etsy 团队建立信心做持续交付的关键。开发人员做自己的功能监控，而且每个人都可以通过仪表盘看到所有的监控图表。Etsy 具有这样一个策略，在默认情况下所有可以被绘制的信息都会被制成图表。随着时间的推移，指标的数量一直稳步增加，所以 Etsy 建立了 Kale 来帮助检测异常模式。所有的日志都可以通过 Supergrep 展现出来，Supergrep 是一个基于 Web 的日志展示工具，这增加了日志的信噪比。
IRC 是贯穿 Etsy 的主要沟通工具，也是 Etsy 协作文化的关键。里面有很多不同的聊天室，每一个都具有特定目的。例如，在聊天室#warroom 中仅允许中断事故有关的会谈。聊天室是用来协调调查，讨论应对措施和解决方案监控的。与其他的聊天室一样，#warroom 是个鼓励新工程师们潜水的地方，因为这些聊天室被认为是学习的好地方。
每次中断发生，或接近中断的时候，所有人被邀请来做事后检查。事后检查是一个重要的文化活动，如果财务和支持人员需要，他们也可以参与。事后检查是为了成为一个学习的机会，所以它们不应该包含责备。所有事后检查相关的信息被记录在 Morgue 里面：日期、严重性、IRC 日志、图表和补救措施。Morgue 是 Etsy 为了保存事后检查记录而特别构建的另一种工具。
对于运营、开发、支付和支持部门的员工都采取随叫随到的政策。开发人员通常轮流地在每四个星期里的某一周提供随叫随到的支持。该政策的目的是让每个人都意识到上线产品每天所面临的问题，使他们能够在开发新功能或改进现有流程时考虑到这些问题。
Etsy 拥有约 60 万的月访问量和每月 15 亿页面浏览量。
关于 Etsy 是怎么做到每天 50 次以上部署的问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注丸趣 TV 行业资讯频道了解更多相关知识。
