Github 的发布流程，最高一天内发布 175 次

   <p>        发布是 Github 所有雇员的工作最为繁重的部分，我们没有发布管理器，也没有设置每周发布。开发人员和设计人员直接对他们所开发的内容负责，只要他们已经准备好了就可以随时发布。</p>    <p>        我们发现能提供这样灵活性的最佳系统就是使用独立的发布分支，所有的改动不会合并到 master 主分支上，除非它们通过了产品分支的验证工作后。这意味着 master 永远是稳定的，如果有问题发生，我们可以随时的回滚到这个安全点上。</p>    <p>最佳的工作流程是这样的：</p>    <ul>     <li>将修改提交到分支上</li>     <li>等待 CI 服务器构建通过</li>     <li>告诉 Hubot 去发布</li>     <li>验证已经做的更改是否解决之前出现的问题</li>     <li>合并到 master 主分支</li>    </ul>    <p>        不久以前，这套系统还不够智能。分支有时候会在构建完毕后自动就发布了，设置是构建失败也发布。或者员工作了超出自身工作的误操作。当公司不断的成长，我们需要增加一些检查和平衡来帮助我们避免这些问题。</p>    <h3>        安全第一</h3>    <p>        现在当我们要发布新改动时，我们要做的第一件事就是从 Janky 持续集成服务器里查看构建是否成功完成，如果尚未完成或者已经失败，我们将通知发布者修复这些问题并重试。</p>    <p>接下来我们检查应用程序是否“锁住”，这个锁用来指示一个特别的分支已经发布到产品环境中，当前不能处理任何发布。master 分支的成功构建会自动的发布，我们不希望这些更改被意外的发布，或者被其他工作人员发布。</p>    <p>        最后一步是确定要发布的分支是否包含 master 上最新的提交，一旦 master 的提交已经发布到产品环境，它将不会因为发布一个分支导致从 master 中被删除。</p>    <p>        我们使用 Github 的 API 来验证这些操作需求。通过 Github.com 应用端点所导出的 SHA1 当前正运行在产品环境中。我们将这个 SHA1 数值提交给 Github 的比较 API来比较 master 分支和产品环境来获得“合并基准”或者是共同的“祖先”。我们也可以用它来比较即将发布的分支以确保是最新的版本。通过使用 master 和产品环境的共同的“祖先”，如果是只存在于分支的代码将会从产品环境中移除，而尚未部署的修改不会在发布前被要求合并。</p>    <p>        如果分支的版本比较老，master 中的内容会自动合并到分支。可通过 Merging API 来实现这个功能。这个合并会启动一个新的 CI 构建，和其他 push 份风格的事件类似，当构建通过就开始部署。</p>    <p>        到这个时候，代码实际上已经发布到我们的服务器上，我们通常会发布到所有的服务器以保证一致性。但可能有时候会需要只发布的一部分服务器，这个部分是根据功能来划分的，例如：前端、文件服务器、worker、搜索等待，我们也可以发布到指定名称的某一台服务器上。</p>    <h3>        监控</h3>    <p>        接下来要干什么？这视情况而定，根据我们的经验，中小规模的改动需要在产品环境中观察最少 15 分钟，如果没出什么问题就可以认为是稳定的。在这 15 分钟内，我们需要检查异常、性能指标以及其他一些额外的验证。如果没有什么关键的问题需要解决，提交到分支上的更改会自动的发布，如果这个时候出什么问 题，会在 30 秒内回滚到主分支上。</p>    <h3>        大功告成</h3>    <p>        如果事事顺利，是到了合并的时候了。在 Github ，我们使用 Pull Requests 来处理大多数开发，因此也是通过 Pull Request 来合并。我们检测分支是否已经合并到 master 上并对应用进行解锁。下一个部署器就开始工作。</p>    <h3>        我们该怎么做？</h3>    <p>        最容易混淆的地方是内部发布服务，名为 Heaven。Heaven 是一组 Capistrano 菜单，封装到一个 Sinatra 应用中，并提供了 JSON 的 API。多数应用使用一般的菜单进行发布，但一些复杂的应用可执行定义额外的发布步骤。只需要提交到 Janky， 随后巧妙的利用 Github API 的钩子, 可轻松实现扩展。Hubot 为 Janky 和 Heaven 提供了集中接口，让在所有人可看到所发生的事情。在写这篇文章时，有 75 个独立的应用通过 Heaven 进行发布。</p>    <h3>        Always be shipping</h3>    <p>        并不是所有的 Github 项目都使用了这套核心开发工作流，但在 2012 年我们做过的统计数据如下：</p>    <ul>     <li>41,679 次构建</li>     <li>12,602 次发布</li>     <li>8月中旬是我们的首脑会议，在接下来一周拉开序幕，并带来大量的灵感，我们最忙的一天是 8月23日，这一天有 563 次构建和 175 次发布。</li>    </ul>    <p><img alt="Github 的发布流程，最高一天内发布 175 次" src="https://simg.open-open.com/show/cfc39db44f9c0a3e370324a7c4c4631e.png" width="545" height="252" /></p>    <a href="/misc/goto?guid=4958523729870925395" rel="nofollow" target="_blank">英文原文</a>， OSCHINA翻译