Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
デプロイ頻度を10倍にした、ブランチ戦略とGitHub Actions on AWS ECS
Search
Tadashi Nemoto
April 27, 2021
Technology
8
4.4k
デプロイ頻度を10倍にした、ブランチ戦略とGitHub Actions on AWS ECS
AWS Startup Tech Meetup Online #4
https://aws-startup-community.connpass.com/event/209830/
Tadashi Nemoto
April 27, 2021
Tweet
Share
More Decks by Tadashi Nemoto
See All by Tadashi Nemoto
Best Practice CI/CD Pipeline for Deploying Container Apps to AWS
tadashi0713
0
220
Scalable and cloud-native mobile game CI/CD environment using Unity
tadashi0713
0
140
Migrating your mobile CI/CD environment to a scalable cloud solution using CircleCI
tadashi0713
0
240
Speed matters: Advanced CI/CD techniques to improve development velocity, quality & security
tadashi0713
0
300
AWS Graviton 環境への CI _ CD パイプラインを CircleCI で実現しよう (AWS Fargate 編)
tadashi0713
0
360
10x deployment frequency using GitLab Flow and GitHub Actions on AWS ECS
tadashi0713
0
600
Creating parallelized Android UITest (Appium) environment using Azure, Docker and Android emulator
tadashi0713
0
4.1k
メルカリの開発スピードと品質を支える Selenium on Azure Kubernetes Service
tadashi0713
2
1.4k
Docker × Androidエミュレーターを使ったAppiumテスト環境
tadashi0713
3
4.7k
Other Decks in Technology
See All in Technology
Pythonで構築する全国市町村ナレッジグラフ: GraphRAGを用いた意味的地域検索への応用
negi111111
8
3k
kotlin-lsp の開発開始に触発されて、Emacs で Kotlin 開発に挑戦した記録 / kotlin‑lsp as a Catalyst: My Journey to Kotlin Development in Emacs
nabeo
2
380
AIがコードを書いてくれるなら、新米エンジニアは何をする? / komekaigi2025
nkzn
25
18k
今のコンピュータ、AI にも Web にも 向いていないので 作り直そう!!
piacerex
0
720
AIエージェントを導入する [ 社内ナレッジ活用編 ] / Implement AI agents
glidenote
1
300
Data & AIの未来とLakeHouse
ishikawa_satoru
0
610
次世代のメールプロトコルの斜め読み
hirachan
3
430
AI-ready"のための"データ基盤 〜 LLMOpsで事業貢献するための基盤づくり
ismk
0
130
設計は最強のプロンプト - AI時代に武器にすべきスキルとは?-
kenichirokimura
1
240
Digitization部 紹介資料
sansan33
PRO
1
5.9k
窓口業務を生成AIにおまかせ!Bedrock Agent Coreで実現する自治体AIエージェント!
rayofhopejp
0
270
AWS 環境で GitLab Self-managed を試してみた/aws-gitlab-self-managed
emiki
0
310
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
100
5.9k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
Building Adaptive Systems
keathley
44
2.8k
Stop Working from a Prison Cell
hatefulcrawdad
272
21k
Why Our Code Smells
bkeepers
PRO
340
57k
VelocityConf: Rendering Performance Case Studies
addyosmani
333
24k
Become a Pro
speakerdeck
PRO
29
5.6k
Side Projects
sachag
455
43k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
34
2.3k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
GitHub's CSS Performance
jonrohan
1032
470k
Optimizing for Happiness
mojombo
379
70k
Transcript
デプロイ頻度を10倍にした、 ブランチ戦略と GitHub Actions on AWS ECS Tadashi Nemoto
⾃⼰紹介 • 根本 征 (ねもと ただし) • 株式会社エクサウィザーズ • Platform
Engineer (DevOps Engineer) ◦ CI / CD 基盤の構築・改善・導⼊ ◦ 本番・検証環境の構築・運⽤ ◦ テスト⾃動化の導⼊・布教
CI / CD を導⼊していますか︖
その CI / CD パイプラインは 現在のプロダクト・開発組織に 最適でしょうか︖
State of DevOps Report 2019
State of DevOps Report 2018
State of DevOps Report 2018
https://tech.uzabase.com/entry/2021/01/28/190209
スタートアップでは変化するスピードがとても重要
None
デプロイ頻度(27回 / 2週間) 10倍以上のデプロイ頻度
アウトライン • これまでの CI / CD・デプロイフロー • 変えたこと ◦ Jenkins
→ GitHub Actions on AWS ECS ◦ Git Flow → GitLab Flow • 改善の効果 • これから
これまでの CI / CD・デプロイフロー
これまでのCI / CD・デプロイフロー • Hashicorp Nomad on AWS ◦ develop,
staging, production ◦ 簡単に複数の develop 環境が作れない • Git Flow ◦ チームによって使い⽅が多少異なる • Jenkins on AWS ◦ 本番環境へのデプロイは⼀部弊チームに依存
⼩さく・⾃律的に デプロイできるようにする
デプロイ頻度を上げる
改善したこと① Jenkins → GitHub Actions on AWS ECS
Jenkins • メンテナンスコストが⾼い ◦ バージョン・プラグインのアップデート ◦ マシンの追加・スケール ◦ 権限付与・セキュリティなど •
専任のメンバー・チームが必要 • ⾃律的なデプロイに向いていない
SaaS系 CI / CD ツール
デプロイ制限
GitHub Actions self-hosted runners
GitHub Actions self-hosted runners • GitHub Actions ではクラウド版とセルフホスト版を⽤意 • セルフホスト版は無料で利⽤可能(GitHub
ユーザー) • クラウド版同等の機能を利⽤可能 (Marketplace, Secret) • クラウド版とセルフホスト版を両⽴することが可能 ◦ デプロイはセルフホスト版、テストはクラウド版 • ワークフロー管理部分をマネージドにできる
GitHub Actions self-hosted runners on AWS ECS
https://techblog.exawizards.com/entry/2020/10/22/080000
改善したこと② Git Flow -> GitLab Flow
Git Flow
Git Flow • リリースタイミングが決まっている開発には有効 ◦ モバイルアプリ(1~2週間に1回) • 恣意的にリリースできる開発にはメリットが少ない ◦ API
/ Frontend をクラウドにいつでもデプロイできる • 不要なブランチ作業によってデプロイ頻度を下げる可能性 ◦ リリースブランチ・Hotfix ブランチ・Tag の作成
GitHub Flow
GitHub Flow 本番環境 ?環境 ?環境 • シンプルなブランチ管理 ◦ master /
feature ブランチ • リリース頻度を⾼くできる • リリース前の検証環境が課題 ◦ master ブランチ = production ◦ staging 環境︖ ◦ development 環境︖
既存の環境 (develop, staging, production) をうまく使いながら、 デプロイ頻度を上げたい
GitLab Flow • feature → master ブランチの関係 ◦ GitHub Flow
と同じ • リリースに必要なブランチを⽤意できる ◦ master ブランチ → staging 環境 ◦ production ブランチ → 本番環境 ◦ リリースするタイミングで merge Staging 環境 本番環境
Develop 環境へのデプロイ
リリースのための Pull Request を⾃動⽣成・更新 Staging 環境 本番環境
https://techblog.exawizards.com/entry/2021/01/21/111031
改善の効果
デプロイ頻度(4回 / ⽉)
デプロイ頻度(27回 / 2週間)
デプロイ頻度(27回 / 2週間) 10倍以上のデプロイ頻度
State of DevOps Report 2019
⼩さく・⾃律的にデプロイできるように
これから
継続的に計測・改善する
PRベースの環境構築 / self-hosted runners を使わない staging 環境 PR1 環境 PR2
環境
継続的テスティング / 継続的インスペクション
まとめ
まとめ • デプロイ頻度の向上はスタートアップ含めとても重要 • 2つの改善によって 10 倍以上のデプロイ頻度を実現した ◦ Jenkins ->
GitHub Actions on AWS ECS ◦ Git Flow -> GitLab Flow • 継続的な計測・改善