MSとGitHubが機能リリースの舞台裏

MSとGitHubが機能リリースの舞台裏

​- デブサミの話

概要

自己紹介

  • GitHubとAzureDevOpsは同じチームが開発している
  • GitHubActions2.0がこないだGA
  • 裏ではAzureDevOpsのツールをフォークしたものが動作している
  • MS内部でもAzureDevOps中心だったがGitHubを使っている
  • ５年で２千人から２万に増加 ​

    統合認証

  • GitHub資格情報でAzureにログインできるようになった ​

    MSの機能リリース舞台裏

    カルチャー

    開発の文化

  • CustomerObsessionー＞好きで好きで仕方ないという意味
  • プロダクト成長を中心とするために、5000ユーザオブザーベーション・インタビューを１年にかこなす
  • リーン開発カルチャーを社内で実勢するため、UXチームがカルチャールームを使用
  • Hypothesis Driven Frameworkなどの各種プラクティスを社内復旧 ​

    今までの組織

  • 柔軟でない組織、コラボレーション低下、モノリスになりすぎた ​

    インナーソースという文化

  • OSSの活動を社内でやる
  • 組織内におけるOSSとベストプラクティスの実現
  • インナーソース実現の４つポイントー＞発見可能性、実行可能、貢献、操作性
  • GitHubのマイクロソフトリポジトリをみると、最初コミット履歴にインナーソースの取り組みがある
  • 社外のコラボレータを採用したりもしている ​

    開発

    プラクティス

  • MSはなるべく自動化
  • ただしデプロイするなら完全自動化をめざす
  • 部分的な自動は避ける
  • 理由は、インナーソースを公開した時に、単純なミスがあると、コラボレーションが加速しないから
  • 負債を背負い続けないためのバグキャップという単純なルール
  • エンジニア数　X ４以上のバグ数を抱えてしまうと、良いチームでないと判断される ​

    統合テストから単体テストへのシフトレフト

  • 今まで統合テスト量が多かった
  • 統合テストが多いと何が起こるかというと、エンジニアが小さい機能追加もしてもレスポンスまで長い時間がかかる
  • ５年で統合テストを減らし単体テストを増やした ​

    リリース、ライブサイト

    本番環境へのデプロイメントの順番

  • カナリアリリース（内部リリース）
  • 最小の外部データセンター
  • 最大の外部データセンター
  • 国際データセンター
  • 残り全て ​

    フィーチャーフラグ

  • コードをがあらかじめデプロイされフィーチャーフラグが公開を制御する仕組み
  • フラグはユーザレベルでの制御を提供 ​

    ライブサイト

  • フィーチャーチームの最優先事項をカンバンで管理
  • ライブサイトにおけるステータス確認 ​

    GitHubの機能リリース舞台裏

    ​

    GitHubFlow

    GitHubFlow説明

  • GitHubでもGitHubFlowを使って開発している
  • 性能ベンチマークとアクセシビリティなどあらゆる観点でCIを行う
  • 3つのデプロイ環境。Review lab production/canary production
  • Review labはレビューした内容をデプロイする。CIもここで回す
  • production/canaryへデプロイする意味はサーバリソースやユーザリクエストなどのリグレッション確認する環境
  • productionは全ユーザに配布 ​

    ChatOps

    Slack上

  • .deplyをすると、Hubotがデプロイ処理をする
  • デプロイしたら次に、Hubotからエラーレートとリスースの使用率を確認するよう指示される
  • 余計な処理がなく自動化されているので、すぐにデプロイできる
  • ほぼオペレーションはChatOpsを使っている
  • オンコール対応もHubotでわかるので、Slackにコマンド叩いてすぐにメンションできる
  • 過去にやったことはSlackに残っているのですぐに終える ​

    GitHubFlowを使っていった中で起こった問題

  • GitHubFlowとChatOpsは2015年からずっと続けている
  • どんどんデプロイできるので、人が増えたら機能開発がどんどんできる
  • ただモノリスなサービスなので、人が増えてしまい、Hubotのデプロイロックが起きてしまうことがあった ​

    対策１

  • そのためデプロイキューを作った
  • 2016年にそれでもキューが溜まりまくって、待ち時間が３時間から６時間待ちという状況になった ​

    対策2

  • 2018年にリリーストレインという仕組みを作った（電車のこと）
  • 同じプルリク内容のものはまとめて１つのプルリクにした
  • Entrainコマンド
  • トレイン用のブランチのプルリクをHubotが作るようにした
  • フィーチャーブランチのトレインに乗せると、トレイン用ブランチにマージされる
  • トレインが満席になったら、トレインのブランチをマスターにマージするようにして、デプロイサイクルを改善
  • そのおかげでデプロイの数が４００くらいのものが３００に減った
  • 去年から全プルリクがリリーストレインになった
  • 裏話で、これが発案された経緯は、デプロイ遅くて自分たちのチーム向けにトレインという仕組みを作った
  • 今はHubotが、Developブランチにプルリクを出したのを検知すると、トレインに乗せたらというサジェストをする
  • 言いたいのは、デプロイサイクルを早くする意識が全メンバにあるので、このようなことが仕組みができたということ