由于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的方式，消除了因为太多贡献者，对部署系统带来的混乱。