マイクロソフトの機能リリースのプロセスとは？
「Azure DevOpsとGitHubは同じチームが開発しており、今後もどんどん統合を進めていく」――セッションは服部氏のこの力強いメッセージから始まった。
GitHub Satelliteで発表されたGitHub Actions v2はAzure Pipelinesとの連携が実現。Azure Pipelinesのエンジニアが数十人規模でGitHub Actionsの開発チームに異動するなど、今組織もドラスティックに変化しているのだそうだ。「MicrosoftもGitHubが中心の開発に舵を切っている」と服部氏は言い切る。
Azure DevOpsとGitHubが統合されることで、GitHubアカウントでAzureにサインインしたり、Azure ADでGitHub Enterpriseに対してシングルサインオンで認証できるようになる。もちろんCI/CDの連携も密になる。「Azure DevOpsとGitHubの連携はまだ過渡期。今後、さらに統合を加速させていく」と服部氏。
マイクロソフトではどのようなプロセスで機能をリリースしているのか。まず、マイクロソフトには、カスタマーオブセッションのカルチャーがある。これは「顧客志向」と訳されることが多いが、マイクロソフトでは「好きで好きで仕方がない」という強い言葉として捉えられているという。これは、Azure DevOpsのチームが、年間5000のユーザーオブザベーション（ユーザー観察）と5000のユーザーインタビューをこなしていることからも明らかだ。
またリーン開発のカルチャーがあり、それを先導するためのカルチャールームも用意しているという。「だがこれは最近の話」と服部氏。かつてのマイクロソフトは組織の規模が拡大するに伴い、官僚的組織となり、コラボレーションが低下。リポジトリも大きくなり「ソースコードレベルでも共有できないことが起こっていた」と服部氏は明かす。
そこでまず取り入れたのが、GitHubでの「インナーソース」の実現である。インナーソースとは組織内においてオープンソースの文化とベストプラクティスを実現すること。社内にソースコードとライブラリ群が共有される環境が生まれ、コラボレーションが増加したという。「どういう人がどういう技術を持ち、どう動いているか。組織内でチームの見える化が実現した」と服部氏。そのほかにも、組織のサイロを壊すこと、興味のあるプロジェクトに取り組み、スキルを向上できるなど開発者の満足度向上にもつながったという。メリットはそれだけではない。
「インナーソースの取り組みをすると、最終的にオープンソースのリポジトリとして社外に公開しやすくなったり、社外のコラボレーターを引き寄せやすくなったりする。そういったメリットがあるため、マイクロソフトではインナーソースを採用している」（服部氏）
次に、開発においては、デプロイを自動化するなら完全にすることにこだわったという。つまり部分的な自動化は避け、すべて自動化するのである。「Azure DevOpsのチームも一日の成果物をケアレスミスの手動処理によってまるごとつぶしてしまったことがある」と明かす。
また、開発チームが積極的に行っているプラクティスがバグキャップである。バグキャップは単純なルールで、次の式で求めることができる。
- チームのエンジニア数×係数＝バグキャップ
係数は経験則から求める。例えばチームに7人のエンジニアがいて、経験則から求めた係数が4だとすると、7×4＝28となり、28という値を上回るバグが発生すると、新しい機能の開発はその段階で止め、バグの解決に専念する。バグキャップを超さない状態になって初めて、新しい機能を開発するというルールだ。「インナーソースの活動がどんどん盛んになると、たくさんの人が開発に参加することで、メンテナンスが追いつかなくなることがある。バグキャップはそんな負債を負い続けないようにするためのプラクティスだ」と服部氏は説明する。
従来、マイクロソフトではウォーターフォールでの開発を行ってきた。ウォーターフォールの課題は、統合テストの量が非常に多いこと。小さな単位で変更をコミットしても統合テストが走り、そのレスポンスが返ってくるまでに時間がかかるからだ。「UIテストもエンドツーエンドのテストだと、反映するまで1時間ほどかかることもあった」と服部氏。そこでマイクロソフトでは、統合テストから単体テストへのシフトレフトを進めている。
「今ではエンジニアが1つ変更点を加えたら、10分ぐらいでそのコミットがテストに通ったかどうか、わかるようになった」（服部氏）
リリース・ライブサイトのプラクティス
テストだけではない。マイクロソフトは安全にリリースする策として、カナリヤリリースを採用している。
Azure DevOpsのチームの場合、まずカナリヤ（内部ユーザー）に公開。Azure ポータルでプレビューをテストする。次に最小の外部データセンターにデプロイ。最小とは、ユーザーが少ないデータセンターを使うということ。全体のダメージを減らしてから、最大の外部データセンター、国際データセンター、残りすべてといった流れで範囲を広げていく方法だ。
「アプリケーションのデプロイだけではなく、データベースのコンフィギュレーション、それに伴うインフラの設定など、膨大なカナリヤリリース環境がマイクロソフトは構築できている。これらは、Azure DevOpsやGitHub Actionsを使うとできること。ぜひ、みなさんもトライしてほしい」（服部氏）
リリースが完了した後の、ライブサイト（プロダクション環境）カルチャーも重要になる。マイクロソフトではフィーチャーチーム（機能ごとのチーム）を形成し、ライブサイトにおけるステータス確認を最優先事項として活動。縦型統合の組織で、PMやテストエンジニアなどあらゆる役割の人が1つのチームに属しており、オンコール対応や毎週のライブサイトレビューなどがフィーチャーチーム内で完結するようになっているという。情報共有はAzure Boardで行っている。
服部氏は「当社ではこのような開発スタイルで、カスタマーオブセッションやリーン開発を実現している。参考にしてほしい」と語り、GitHubの田中氏にバトンタッチした。
機能リリースに欠かせないGitHub FlowとChatOps
続いて登壇したGitHubの田中氏は、最初にここ1年半以内にアップデートしたプロダクトを披露した。無料のプライベートリポジトリ（アクセス制限3ユーザまで）Free Private Repositories、GitHub Actions、GitHub Packages、GitHub Sponsors、GitHub Desktop 2.0など、主立ったものだけで8つ。なぜこれだけ多くリリースできたのか。「大事になってくる要素が3つある」と田中氏。それがGitHub Flow、ChatOps、継続的デリバリ Continuous Deliveryである。
まずはGitHub Flowの解説から。GitHubでは機能開発する際、masterからフィーチャーブランチという機能開発用のブランチを切るという。その上でコードを変更してコミットして、プルリクエストを作成する。そこでコードレビューやCIプロセスを動かし、変更内容の品質を確認する。
CIプロセスでは自動テストやユニットテスト、機能テスト、結合テストなどを実行。そのほかにもアクセシビリティテストや性能ベンチマークなど、あらゆる観点で品質チェックなども実行する。そしてコードレビューやCIが成功しないと次のステップには進めないようになっているのだ。そしてすべてのチェックが終わると、デプロイをする。「デプロイと言っても、いきなりプロダクション環境にデプロイするわけではない」と田中氏は説明する。
GitHubはデプロイ環境を3種類用意している。1つはreview-lab。これはプロダクションと同じ構成のステージング環境である。CIのジョブ中で自動的にデプロイされ、https://<branch-name>.review-lab.github.com/というURLからアクセスできるようになる。
そこで結合テストを実施する。レビューラボの確認がOKになると、production/canaryというカナリヤ環境で実際のプロダクション環境の一部に、フィーチャーブランチの内容をデプロイする。カナリヤ環境の目的はユーザーのリクエストを実際にさばいてみて、エラーレートが上昇しないかやサーバーリソースを変な使い方をしていないかなど、リグレッションがないかどうかを確認するためだ。「これらは5～10分ぐらいで判別できる」と田中氏。
大丈夫だと判断できれば、productionにデプロイする。これで全ユーザーに公開されることになる。プロダクション環境でもカナリヤ同様、サーバーリソースのようなメトリクスを確認して、OKであればその時点でフィーチャーブランチをマスターにマージする。
これがGitHubでのデプロイの基本的なフローである。だが、これだけでは誰がどのように実行するのかがわからない。そこで活用するのがChatOpsだ。社内で使っているSlack上でコマンドを実行すると、裏でボットが処理してくれる仕組みだ。例えばデプロイ処理は、.deployというコマンドを使う。そしてどのブランチをどの環境にデプロイするのかを指定する。すると、その裏でHubotというボットが反応し、デプロイ処理を行う。
デプロイ後、知りたいのはプロダクション環境に異変が起こっていないかどうだが、それもHubotが教えてくれる。プロダクション環境のさまざまなメトリクスのダッシュボードや、エラー監視ツールのリンクを返してくれるからだ。「ここでひとつ大事なことがある」と田中氏。「GitHubではデプロイを実行するのは、プルリクエストをしていた本人。自分でデプロイするため、余計な承認フローなどはない。だからガンガンデプロイできる」という。
このようにGitHubではChatOpsのコマンドをたくさん作成しているため、ほぼすべてのオペレーションはChatOpsで行われているという。
「例えばサーバーリソースがおかしければ、Slack上でサーバーリソースの確認ができる。またデプロイ後に何か問題が発生したとき、今日のオンコール担当の確認などオペレーションに必要な操作は、すべてSlackコマンドで実装されており、Hubotで見ることができるようになっている。しかもSlackなので、直接、担当者にメンションして、経緯の説明やメトリクスを見せることなく、その場で一緒にトラブルシュートできる。問題が迅速に解消できるのが、ChatOpsのメリットだ」（田中氏）
リリーストレインでデプロイロックを解消
GitHubではこのような形でこれまでずっとプロダクトアップデートをしてきた。デプロイ数も2015年には週に400回を超える数を行っていたという。3つ目の要素、継続的デリバリ Continuous Deliveryも問題なく実現できているように思える。
だが、人が増えるに従い、大きな問題が出てきたという。GitHubはマイクロサービス化している部分もあるとはいえ、基本的には大きなモノリス。それに対して、先の体制でデプロイしていくと、デプロイが競合するようになったという。デプロイロックが起こっていたのである。
GitHubはフィーチャーブランチからプロダクションをデプロイし、その後、数分間はメトリックスがおかしくなっていないか確認する。その間に他の人がデプロイすると、きちんとした監視ができない。そのため、Hubotはプルリクエストをデプロイしてから、それがマージされるまでの間、他の人がデプロイできないようにロックをするのである。「デプロイロックの競合が起きて、デプロイロックが取られていないタイミングを待つ必要がでてきた」と田中氏は振り返る。
その改善策として作ったのがデプロイキューである。ロックがかかりデプロイできなかったときに、順番待ちできるようにする仕組みである。そして自分の番が回ってくるとHubotが通知をしてくれる。これでロック解消を待ち続けないといけないという問題は解消された。だが人が増えると、順番待ちの時間は長くなっていった。「2018年の初頭、キューの待ち時間が3時間19分。ひどいときは5～6時間待ちも起きていた」と田中氏は吐露する。そうなるとフィードバックサイクルのループも遅くなってしまう。
2018年の後半、この問題を解決する仕組みとして導入したのが「リリーストレイン」である。リリーストレインは、同じタイミングでデプロイするプルリクエストを複数まとめて、一気にデプロイする仕組みだ。
トレインにはたくさんのプルリクエストが乗るので、他の人のプルリクエストを乗車させることもできるようになっている。またフィーチャーブランチにはどのトレインにしたかという情報がHubotにより自動で記載される。そしてトレインに乗客がたまると、トレインのブランチごとにreview-labにデプロイする。問題がなければ複数プルリクエストをまとめてカナリヤ環境、さらにはプロダクションにデプロイして確認してから、トレインのブランチをマスターにマージする流れになる。「このような仕組みにより、シップされたトータルのプルリクエストの数は右肩上がりに増えている」と田中氏は満足そうに語る。
リリーストレインの仕組みは、元々GitHubの1つのチームが、自分たちのチーム向けにまとめて作った仕組みだという。実際試してみたところ効果がよかったので、社内ブログに記事を公開。さらに別のチームがHubotのコマンドに変更したり、草の根的に改善が加えられ、全社に広がっていったという。「これもGitHubらしさ。よい仕組みはすぐ広がっていく」と田中氏。
GitHubはDevOpsやリーン開発でよく語られる学習サイクルを高速に回すことを重要視しており、全員に根付いているという。「デプロイプロセスをどうするかに正解はない。きっと2、3年後には別の動きをしていると思う」と田中氏は語り、セッションを締めた。
お問い合わせ
日本マイクロソフト株式会社
-
【Microsoft Learn もくもく会】
- 全国のMicrosoft Learnユーザーのコミュニティです。
-
【JAZUG （Japan Azure User Group）】
- Azureを学び、楽しみ、活かす、日本のユーザーグループです。
-
【クラウドデベロッパーちゃんねる】
- クラウドを使って開発するITの開発者・デベロッパーの皆様へ様々な技術情報をお届けするYouTubeチャンネルです。
-
【Microsoft Learn】
- Microsoft Azureについて学習できる無料のオンライン トレーニング コンテンツ一覧です。
-
【開発者コミュニティ ニュースレター】
- マイクロソフトが配信しているニュースレターで、最新テクノロジ記事、技術ドキュメント、および開発者イベントなど、世界の情報を月イチで配信しています。
