Save 37% off PRO during our Black Friday Sale! »

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

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

E8aaf6f975dda96c47412cf311089243?s=128

Tadashi Nemoto

April 27, 2021
Tweet

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 • 継続的な計測・改善