GitHub 2011–2020：Hubotがチャットをデプロイコンソールに変えた

2011年までに、GitHubの小さなチームはCampfireチャットからインフラを運用しており、彼らのボットは「より大きく、より雑然と」なっていた。彼らはそれをゼロから書き直し、Hubotとしてオープンソース化した——コードを出荷し、CIサーバーの前面に立ち、運用コマンドを全社に可視化するボットである。

ツールをチャットルームに置く：コードをデプロイし、CIを実行し、エラーが急増したときに最後にデプロイした人に通知するボット——すべての行動が可視化され、監査可能で、全員に開かれている。

Hubotは「/deploy my-feature」のようなコマンドを待ち受ける。エンジニアはチャットからデプロイし、例外率が急増するとボットは最後にデプロイした人に内部のHaystackダッシュボードへのリンクを添えて通知し、暗黙的に責任を割り当てる。2011年にオープンソース化され、2020年までにGitHubは依然としてChatOpsを通じて週120〜150回の本番デプロイを実行し、カナリアリリースと、デプロイごとにバッチ処理される数百のプルリクエストを伴っていた。

GitHubでのデプロイは、誰でも実行でき、全員が見られるチャットコマンドになった。同じ週次デプロイ数で今でははるかに多くの変更を出荷し、ロールバックは「信頼の文化」を築けるほど低く抑えられ、ChatOpsという言葉はチームがこのパターンを模倣するにつれて業界全体に広がった。

2011年、GitHubは非常に大規模なサービスを運営する小さな会社であり、そのチームはCampfireチャットの中に住んでいた。彼らのボットは「より大きく、より雑然と」なっていたため、彼らはそれをゼロから書き直し、オープンソース化した：Hubotは「驚くべきCampfireボット」であり、彼らを笑わせ、彼らのコードを出荷し、CIサーバーへのインターフェースとして機能した。

この実践はGitHubがChatOpsと呼ぶものへと成長した：エンジニアはチャットで「/deploy my-feature」を実行し、Hubotが認証、ステージング、カナリアリリースを処理する。デプロイ後に例外が急増すると、Hubotは最後にデプロイした人にHaystack——GitHubの内部例外ダッシュボード——へのリンクを添えて通知する。「この通知の直接の利点は、責任の所在を暗黙的に設定することだ」。

2020年までにこのパターンは成熟していた：GitHubのデプロイチームは「一連のHubotコマンド」で開始されるデプロイを説明し、github.comのために週120〜150回の本番デプロイを実行し、単一の週に400以上のプルリクエストを出荷し、プロセスへの信頼はロールバックが低く抑えられ、開発者がマージして先に進めるほど十分だった。

それは「誰が本番環境に触れてよいか」というボトルネックを取り除いた——どのエンジニアでもチャットからデプロイでき、その行動は全社に見えた。

ボットは責任を暗黙的なものにした：エラーが急増すると最後にデプロイした人が通知されるため、問題はトリアージを待つのではなく担当者を見つける。

すべてのコマンドが共有チャンネルで実行されたため、デプロイは監査可能で教えられるものになった——新しいエンジニアはチャットを見て運用を学んだ。

Hubotのオープンソース化は、内部の便利さを業界のパターンに変え、ChatOpsという言葉を普及させた。

内部ツールは、行動の社会的コストを下げるときに勝つ：運用をチャットに置くことで、デプロイは可視化され、監査可能で、委任しても安全になった——インターフェースの変更こそが文化を変えたのだ。

ChatOpsは広く模倣される実践となり、HubotはSlack、Discord、Teams向けのアダプターを備えたコミュニティプロジェクトへと成長した。GitHubではデプロイパイプラインが進化し続けた——IssueOpsやGitHub Actionsは後に同じアイデアの上に築かれた——一方で、人々がすでに共有しているツールからインフラを実行できるようにするという根本原則は、GitHubの出荷方法の中心にあり続けた。