Upgrade to Pro — share decks privately, control downloads, hide ads and more …

デプロイ頻度を10倍にした、ブランチ戦略とGitHub Actions on AWS ECS

デプロイ頻度を10倍にした、ブランチ戦略とGitHub Actions on AWS ECS

Tadashi Nemoto

April 27, 2021
Tweet

More Decks by Tadashi Nemoto

Other Decks in Technology

Transcript

  1. デプロイ頻度を10倍にした、 ブランチ戦略と GitHub Actions on AWS ECS Tadashi Nemoto

  2. ⾃⼰紹介 • 根本 征 (ねもと ただし) • 株式会社エクサウィザーズ • Platform

    Engineer (DevOps Engineer) ◦ CI / CD 基盤の構築・改善・導⼊ ◦ 本番・検証環境の構築・運⽤ ◦ テスト⾃動化の導⼊・布教
  3. CI / CD を導⼊していますか︖

  4. その CI / CD パイプラインは 現在のプロダクト・開発組織に 最適でしょうか︖

  5. State of DevOps Report 2019

  6. State of DevOps Report 2018

  7. State of DevOps Report 2018

  8. https://tech.uzabase.com/entry/2021/01/28/190209

  9. スタートアップでは変化するスピードがとても重要

  10. None
  11. デプロイ頻度(27回 / 2週間) 10倍以上のデプロイ頻度

  12. アウトライン • これまでの CI / CD・デプロイフロー • 変えたこと ◦ Jenkins

    → GitHub Actions on AWS ECS ◦ Git Flow → GitLab Flow • 改善の効果 • これから
  13. これまでの CI / CD・デプロイフロー

  14. これまでのCI / CD・デプロイフロー • Hashicorp Nomad on AWS ◦ develop,

    staging, production ◦ 簡単に複数の develop 環境が作れない • Git Flow ◦ チームによって使い⽅が多少異なる • Jenkins on AWS ◦ 本番環境へのデプロイは⼀部弊チームに依存
  15. ⼩さく・⾃律的に デプロイできるようにする

  16. デプロイ頻度を上げる

  17. 改善したこと① Jenkins → GitHub Actions on AWS ECS

  18. Jenkins • メンテナンスコストが⾼い ◦ バージョン・プラグインのアップデート ◦ マシンの追加・スケール ◦ 権限付与・セキュリティなど •

    専任のメンバー・チームが必要 • ⾃律的なデプロイに向いていない
  19. SaaS系 CI / CD ツール

  20. デプロイ制限

  21. GitHub Actions self-hosted runners

  22. GitHub Actions self-hosted runners • GitHub Actions ではクラウド版とセルフホスト版を⽤意 • セルフホスト版は無料で利⽤可能(GitHub

    ユーザー) • クラウド版同等の機能を利⽤可能 (Marketplace, Secret) • クラウド版とセルフホスト版を両⽴することが可能 ◦ デプロイはセルフホスト版、テストはクラウド版 • ワークフロー管理部分をマネージドにできる
  23. GitHub Actions self-hosted runners on AWS ECS

  24. https://techblog.exawizards.com/entry/2020/10/22/080000

  25. 改善したこと② Git Flow -> GitLab Flow

  26. Git Flow

  27. Git Flow • リリースタイミングが決まっている開発には有効 ◦ モバイルアプリ(1~2週間に1回) • 恣意的にリリースできる開発にはメリットが少ない ◦ API

    / Frontend をクラウドにいつでもデプロイできる • 不要なブランチ作業によってデプロイ頻度を下げる可能性 ◦ リリースブランチ・Hotfix ブランチ・Tag の作成
  28. GitHub Flow

  29. GitHub Flow 本番環境 ?環境 ?環境 • シンプルなブランチ管理 ◦ master /

    feature ブランチ • リリース頻度を⾼くできる • リリース前の検証環境が課題 ◦ master ブランチ = production ◦ staging 環境︖ ◦ development 環境︖
  30. 既存の環境 (develop, staging, production) をうまく使いながら、 デプロイ頻度を上げたい

  31. GitLab Flow • feature → master ブランチの関係 ◦ GitHub Flow

    と同じ • リリースに必要なブランチを⽤意できる ◦ master ブランチ → staging 環境 ◦ production ブランチ → 本番環境 ◦ リリースするタイミングで merge Staging 環境 本番環境
  32. Develop 環境へのデプロイ

  33. リリースのための Pull Request を⾃動⽣成・更新 Staging 環境 本番環境

  34. https://techblog.exawizards.com/entry/2021/01/21/111031

  35. 改善の効果

  36. デプロイ頻度(4回 / ⽉)

  37. デプロイ頻度(27回 / 2週間)

  38. デプロイ頻度(27回 / 2週間) 10倍以上のデプロイ頻度

  39. State of DevOps Report 2019

  40. ⼩さく・⾃律的にデプロイできるように

  41. これから

  42. 継続的に計測・改善する

  43. PRベースの環境構築 / self-hosted runners を使わない staging 環境 PR1 環境 PR2

    環境
  44. 継続的テスティング / 継続的インスペクション

  45. まとめ

  46. まとめ • デプロイ頻度の向上はスタートアップ含めとても重要 • 2つの改善によって 10 倍以上のデプロイ頻度を実現した ◦ Jenkins ->

    GitHub Actions on AWS ECS ◦ Git Flow -> GitLab Flow • 継続的な計測・改善