GitHub自动化多阶段部署程序，解决贡献者人数成长带来的部署问题

由于GitHub.com应用程序的贡献人数，在去年成长了一倍，因此在部署程序出现了一些过去不曾遭遇的问题，对此GitHub决定将部署程序打散成为多阶段，并且自动化部署程序，来解决部署混乱的问题。

虽然专案贡献人数增加是一件值得高兴的事，但是GitHub的部署工具也因此碰到了一些问题。GitHub.com主要透过ChatOps使用分支部署模型，也就是在Slack频道中，让开发人员以ChatOps的方式控制部署程序，在合并到主要分支前，先部署分支，也就是说，开发者可以在伫列中新增变更，检查伫列状态，组织要部署和合并的请求。

官方提到，虽然这是一个简单的系统，但是由于一个频道中，同时要管理多人的伫列、部署和各种任务，因此在监控部署上产生混乱，该频道被大量讯息淹没，使得开发人员无法透过系统追踪变更，进而影响开发产能，并增加GitHub的风险。过去的部署方法存在几个问题，第一个问题是，由于在Slack频道内，一个部署会有许多相关的追踪讯息，要将单一部署的不同讯息组合在一起并不容易，因为来自部署系统的后续讯息，可能多至数百条。

第二个问题则是发生在金丝雀（Canary）阶段，在金丝雀阶段最多只能部署GitHub.com的2％流量，也就是说，在100％部署的生产阶段之前，有许多问题是在金丝雀阶段无法被发现，一旦意外发生就需要回退，官方提到，可用性和正常运作时间（Uptime）是他们最在意的问题，因此随着GitHub持续成长，改善这个问题变得非常重要。因此官方加入了第二个拥有更高流量百分比的金丝雀阶段，让GitHub.com能够以较低的风险，过渡到100％的生产阶段。

最后一个问题则是部署手续太麻烦，需要自动化程序让部署更简单。过去开发人员必须使用不同的指令排队、部署到金丝雀阶段，以及部署到生产阶段，每个阶段都需要人工参与，这让开发人员不只需要学习ChatOps指令，并坐在电脑前等待部署工作结束，还很容易出错。

因此GitHub展开了改善部署体验，要让开发者使用单一ChatOps指令，就能自动化整个部署程序，他们将部署切分成多个阶段，并在不同阶段间加入检查机制，加以验证程式码部署结果，使整个系统如同状态机一般运作。

自动化程序可以自动部署程式码到2％金丝雀阶段，接着是20％金丝雀阶段，再来是部署到生产阶段，最后则是准备合并，每个阶段中间间隔5分钟，指标会在每个阶段完成部署后，自动指向下一阶段。而部署的状态，则从状态机后端部署系统读取资料，统一显示在第一方使用者界面（下图），这不只结合了开发者熟悉的传统ChatOps，也让开发者不需要在吵杂的Slack频道中追踪讯息。

开发者仍然跟过去一样在Slack中开始部署，并且进行监控，官方提到，这还是开发人员最习惯的部署方式。这些调整改变了部署GitHub.com的方式，消除了因为太多贡献者，对部署系统带来的混乱。