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
Deployment Painをなくそう
Search
jimpei
October 06, 2023
Programming
3
620
Deployment Painをなくそう
開発生産性LT Night in 福岡
https://findy.connpass.com/event/296381/
jimpei
October 06, 2023
Tweet
Share
More Decks by jimpei
See All by jimpei
リモートだからこそ 懸念だし1on1
jimpei
3
580
文化が生産性を作る
jimpei
3
760
「コードがむずかしい」からの脱却
jimpei
43
18k
Other Decks in Programming
See All in Programming
Domain-Driven Transformation
hschwentner
2
1.9k
Serverless Rust: Your Low-Risk Entry Point to Rust in Production (and the benefits are huge)
lmammino
1
130
PHPのバージョンアップ時にも役立ったAST
matsuo_atsushi
0
170
CDK開発におけるコーディング規約の運用
yamanashi_ren01
2
180
Pulsar2 を雰囲気で使ってみよう
anoken
0
240
負債になりにくいCSSをデザイナとつくるには?
fsubal
10
2.5k
Formの複雑さに立ち向かう
bmthd
1
880
Honoのおもしろいミドルウェアをみてみよう
yusukebe
1
210
SwiftUI Viewの責務分離
elmetal
PRO
2
250
『GO』アプリ バックエンドサーバのコスト削減
mot_techtalk
0
150
『GO』アプリ データ基盤のログ収集システムコスト削減
mot_techtalk
0
130
データの整合性を保つ非同期処理アーキテクチャパターン / Async Architecture Patterns
mokuo
53
18k
Featured
See All Featured
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
12
980
Building Adaptive Systems
keathley
40
2.4k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.6k
Git: the NoSQL Database
bkeepers
PRO
427
64k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.3k
The Cost Of JavaScript in 2023
addyosmani
47
7.3k
Rebuilding a faster, lazier Slack
samanthasiow
80
8.8k
Building Your Own Lightsaber
phodgson
104
6.2k
Typedesign – Prime Four
hannesfritz
40
2.5k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
100
18k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Transcript
1 Deployment Painをなくそう 2023.10.06 開発生産性LT Night in 福岡 @jimpei
2 SIer -> Yahoo! JAPAN -> mercari (2021/08)
Help Center Team Software Engineer / Tech Lead 濱村 甚平(@jinpeih)
3 Deployment Painとは 今日話すこと 自チームの状態 Deploy頻度を計測する意味とは 02 03 01
4 Deployment Painをなくそう
5 Deployにどれぐらい抵抗がありますか?
6 Deployにどれぐらい抵抗があるか 3ヶ月ぶりに20本分の機能改修差分を リリース手順書とチェックリストを作って 手動で2人体制で2時間かけて Deploy Deployが怖い、負担、面倒に感じる 例えば...
7 そもそもDeployment Painとは • コードを本番環境にプッシュする際に感じる恐怖や不安の尺度 • デプロイが簡単で苦痛を伴わず、むしろ破壊的である度合い これが大きい場合、ソフトウェアの提供パフォーマンス、組織のパフォーマンス、組織 文化が低い可能性 ソフトウェアを迅速かつ安定して提供する能力を向上させる技術的なプラクティスは、
これ(本番Deployのストレスと不安)も軽減する https://dora.dev/devops-capabilities/cultural/wellbeing/ DORAによると
8 チームの状態や取り組み
9 チームとプロダクト紹介 チーム構成 • Engineering Manager(EM): 1人 • Product Manager(PdM):
1人 • Software Engineer ◦ FE: 1人(+1人) ◦ BE: 2人 • Tech Lead、Scrum Masterはメンバーで兼任 • FE/BEと分けているがクロスファンクショナルにタスクを取ることもある Help Center: お客さまの疑問やお困りごとの解消のための体験を提供する
10 Deploy数推移(2022/01 ~ 2023/10) 年間約500回Deploy (42/month, 2/day) ・mainブランチにマージ後リリースタ グを つけることによりDeploy ・立ち上げによるフェーズに左右され てい
る ・Four Key的にはEliteレベル 2022 2023 | 初期開発 機能拡充のための 設計期 機能拡充開発期 改善期 年間約500回Deploy (42/month, 2/day)
11 Deploy数推移(2022/01 ~ 2023/10) ・フェーズごとにHelpに入って もらっていたので結構変動している ・立ち上げによるフェーズに左右され てい る エンジニア推移 2022
2023 | 初期開発 機能拡充のための 設計期 機能拡充開発期 改善期
12 Deploy数推移(2022/01 ~ 2023/10) ・D/D/Dが0.1以上あれば健全らしい ・向上してきているというよりは フェー ズによって変動している ・改善期に入って安定してきている ・改善期より前は、大きな要件設計や技術 的な落とし込みにリソースを使っていた
Deploy / Day / Developer 2022 2023 | 初期開発 機能拡充のための 設計期 機能拡充開発期 改善期
13 チームの状態 • 技術 ◦ 自動テストへの信頼(+ ベースとなるよい設計 ◦ 監視への信頼 ◦
Deploy容易性(はやい・かんたん) ◦ リカバリ容易性(はやい・かんたん) • プロセス・組織 ◦ タスクが単一でリリース可能な粒度になっている ◦ チームで意思決定して(都度承認なしで)リリースできる • メンタル ◦ Deployする方が安心、逆にDeployの間が空くと怖い
14 Deploy頻度を計測する意味とは
15 Deploy頻度は正義か チーム構成 • Engineering Manager: 1人 • “Deploy頻度をあげるため” の取り組みはなにもしていない
• ただ”安全で早くDeployし続けることできる環境”を意識している • チームの健康診断的に使う ◦ 数値が変化したときになにか問題が起きていないのかチェックする 計測はしているが、目標にはしていない
16 なぜDeployしやすい環境を求めるのか チーム構成 • Engineering Manager: 1人 • DARAでは、Deployment PainはWellbeingのページにかかれている
◦ これが組織のパフォーマンスを向上させると信じてる Deployしやすい環境が、エンジニアの開発生産性をあげる
17 なぜエンジニアの開発生産性をあげるのか チーム構成 • Engineering Manager: 1人 素早く価値提供し、ビジネス貢献するため
18 Deploy頻度の高さは、価値提供の大きさなのか チーム構成 • Engineering Manager: 1人 • なにが一番の価値提供になるのかはわからない •
100回のDeployより、1回のDeployの方がインパクトが大きいこともある • 継続して価値提供するために、とにかく打席(仮説検証)を創出する 直接結びつくことはない
19 まとめ
20 まとめ チーム構成 • Engineering Manager: 1人 • Deploy頻度の数値が最終目標ではない •
なりたい姿をイメージして、その状態の定量的な指標の一つとして定義 • Deploy回数を計測する→数値を見て状態に気づく→Painはなにか?を探る なぜ改善する必要があるのか • 仮説検証をたくさん早く回すために開発生産性をあげたい ◦ 開発生産性をあげるために、Deployment Painをなくしたい Deployment Painがない環境を目指そう なりたい姿・状態をイメージして、改善していく
21 おわり 採用してます!
22 開発フロー Development → PR → Review → Merge to
main branch → Deploy to DEV → Release Tag → Deploy to Production • 基本的にmain branchにマージ = 本番Deployする ◦ いくつかのPRがまとめてDeployされることもある ◦ チケットのサイズやPRのサイズを調整して細かく開発&レビュー&リリース する ◦ まだ公開できない機能などはFeatureFlagを使って非公開状態でリリース する(DEV環境でのみ公開される) • 本番Deployしたものは翌日の朝会でデモ(ほぼ毎日 • 朝会にPdMもチームメンバーとして参加しているので常に合意が取れている状 態 詳細はチームメンバーのスライドで
23 チケットサイズ • 改修内容をできるだけ細かな価値提供サイズに分解しチケットを細かくする ◦ PRはさらに適切で小さな単位で作ってReview&Deployする 例えば... 何かの管理画面を作る場合 • 管理画面を開くことができる
• 管理画面で情報を取得できる(&閲覧できる) • 管理画面で情報を更新できる • など… できるようになること単位で作っていく(ケースバイケースではある
24 参考 https://engineering.mercari.com/blog/entry/20221215-devstats/ https://speakerdeck.com/myaake/fu-gang-falsecxptimufalseshao-jie-t okai-fa-falsegong-fu