今年もDevelopers Summit 2020に参加してきたので参加したセッションのメモを備忘録的に残しておこうと思います。 event.shoeisha.jp
講演資料など全体的な情報はここでまとめてくれています。 codezine.jp
GitHubとAzureDevOpsは同じチームが開発している
- MicrosoftではGitHubが中心に変わってきている
- 開発の主体もすでにGithubで展開されている
カルチャー
AzureDevOpsのチームは500ユーザーオブザベーションと5000ユーザーインタビューを1年にこなしている
リーン開発のカルチャー
- 社内で実践している
- 呼んでいる本は特別ではなく、一般的な本
インナーソースを実現
- 組織内でのOSSの活動
- ソースを共有することでコラボレーションの増加
- インナーソースとしてやっていたものをそのままOSSに持っていくことができる
開発テスト
デプロイを自動化するなら"完全に"
部分的な自動化避ける→ケアレスミスによって1日の成果を丸ごと失う可能性があるバグキャップ
- チームのエンジニア数 × 4(経験則で変える) = ?
- この数字をチームが超えてしまったら今行っている作業をとめてバグがこの数字を下回るまでバグをけさなければならない→負債を止めない
統合テストから単体テストへのシフトレフト
- MSはずっとウォーターフォールの会社だった
- 統合テストが単体テストよりも多かった
- テストのレスポンスが得ってくるまで時間がかかってしまう
リリース・ライブサイト
本番環境へのデプロイめんとの追跡 影響範囲の少ないところからリリースしていく
- カナリア
- 最小の外部データセンター
- 最大の外部データセンター
- 国際データセンター
- 残りすべて
フィーチャーフラグ
- すべてのコードがあらかじめデプロイされフィーチャーフラグが公開するかを制御できる
こっからGithubのおはなし
GitHub Flow
デプロイする環境は3つ
* review-lab
ステージング環境
* production/canary
カナリア環境。自動テストは行わない。
リグレッションがないかを確認する
* production
ChatOps
- Slack上で.deployってコマンドを使うとbotがトリガーされて自動でデプロイ処理が出てくる。デプロイ後にメトリックのリンクが送られてくる
- 承認フローがない
- ほぼすべてのデプロイをhubotを使っている
何かおきても迅速に対応できるのがChatOpsの特徴
GitHubはモノリックの構造
- 規模が大きくなるにつれ、デプロイロックがはしるようになってしまった
デプロイキュー
- デプロイのキュー機能
- 自分の順番が回ってきたらbotが優位してくれる
リリーストレイン
- PRをまとめて一つにデプロイ
- トレイン用のプルリクエストを自動的に作って、フィーチャーブランチはトレイン用のブランチに乗るようになる。トレインに乗客がたまったらトレインのブランチごとマスターにリリースする
リリーストレインは社内ブログで宣伝したら他の部署で少しずつ全体に広がってきた。
最後に
Microsoft EA経由でGihubライセンスを買うことができます
