Slackのデプロイプロセス

• すべてのPRはコードレビューとテストの通過が必要

• マージされたコードは北米の業務時間内にのみデプロイされる（問題発生時に対応するため）

• 1日に約12回の定期デプロイ

• 各デプロイごとにデプロイ担当者が指定される

1. リリースブランチを作成

2. ステージングにデプロイして手動テスト

3. 社内Slack（ドッグフーディング層）にデプロイ後、Canaryデプロイ（全トラフィックのうち2%のみがルーティングされる）

4. 10、25、50、75、100パーセントまで段階的にデプロイを進行

リスク管理のためにデプロイ担当者を訓練し、すべての段階を監督し、コミュニケーションを担当させる。

問題を可能な限り早く検知し、原因となったPRを特定して取り除いたうえで新しいビルドをデプロイする。

本番環境までの間に発見できなかった問題が発生した場合は、調査の前にまずロールバックを行う。

会社の初期にEC2インスタンスを10台だけ運用していた頃のデプロイは、単に rsync するだけだった。

本番デプロイ前にはStagingの1段階しか存在せず、テスト後にそのままデプロイを進めていた。

顧客が増えるにつれて、rsync だけでは難しくなった。

→ Full parallel pull-basedシステムへ変更

新しいビルドをサーバーにスクリプトで投入するのではなく、各サーバーがConsulキーの変更によるシグナルを受けたときに同時にビルドを取得するようにした。

→ Hot/Coldフォルダに分離したAtomic Deploy

デプロイ時には新しいコードを使用していないColdディレクトリにコピーし、既存サービスはHotディレクトリが配信する。

サーバーにアクティブなプロセスがないときにHot/Coldディレクトリを相互に切り替え、新しいコードを即座に配信する。

[xguru]

Consul by Hashicorp https://www.consul.io/

SlackのバックエンドはHHVM上で動くPHP/Hacklangなので、あのHot/Coldの切り替えが可能なようです。

https://www.quora.com/What-is-the-tech-stack-behind-Slack