Deployment Painをなくそう

開発生産性LT Night in 福岡
https://findy.connpass.com/event/296381/

Transcript

1. 1 Deployment Painをなくそう 2023.10.06 開発生産性LT Night in 福岡 @jimpei
2. 2 
 SIer -> Yahoo! JAPAN -> mercari (2021/08) 
 
 Help Center Team
 Software Engineer / Tech Lead
 
 濱村 甚平(@jinpeih)

3. 3 Deployment Painとは 今日話すこと 自チームの状態 Deploy頻度を計測する意味とは 02 03 01
4. 4 Deployment Painをなくそう
5. 5 Deployにどれぐらい抵抗がありますか？
6. 6 Deployにどれぐらい抵抗があるか 3ヶ月ぶりに20本分の機能改修差分を リリース手順書とチェックリストを作って 手動で2人体制で2時間かけて Deploy Deployが怖い、負担、面倒に感じる 例えば...
7. 7 そもそもDeployment Painとは • コードを本番環境にプッシュする際に感じる恐怖や不安の尺度 • デプロイが簡単で苦痛を伴わず、むしろ破壊的である度合い これが大きい場合、ソフトウェアの提供パフォーマンス、組織のパフォーマンス、組織 文化が低い可能性 ソフトウェアを迅速かつ安定して提供する能力を向上させる技術的なプラクティスは、 これ(本番Deployのストレスと不安)も軽減する https://dora.dev/devops-capabilities/cultural/wellbeing/ DORAによると
8. 8 チームの状態や取り組み
9. 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. 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. 11 Deploy数推移(2022/01 ~ 2023/10) ・フェーズごとにHelpに入って 　もらっていたので結構変動している ・立ち上げによるフェーズに左右され　てい る エンジニア推移 2022 2023 | 初期開発 機能拡充のための 設計期 機能拡充開発期 改善期
12. 12 Deploy数推移(2022/01 ~ 2023/10) ・D/D/Dが0.1以上あれば健全らしい ・向上してきているというよりは　　　フェー ズによって変動している ・改善期に入って安定してきている ・改善期より前は、大きな要件設計や技術 的な落とし込みにリソースを使っていた Deploy / Day / Developer 2022 2023 | 初期開発 機能拡充のための 設計期 機能拡充開発期 改善期
13. 13 チームの状態 • 技術 ◦ 自動テストへの信頼(+ ベースとなるよい設計 ◦ 監視への信頼 ◦ Deploy容易性(はやい・かんたん) ◦ リカバリ容易性(はやい・かんたん) • プロセス・組織 ◦ タスクが単一でリリース可能な粒度になっている ◦ チームで意思決定して(都度承認なしで)リリースできる • メンタル ◦ Deployする方が安心、逆にDeployの間が空くと怖い
14. 14 Deploy頻度を計測する意味とは
15. 15 Deploy頻度は正義か チーム構成 • Engineering Manager: 1人 • “Deploy頻度をあげるため” の取り組みはなにもしていない • ただ”安全で早くDeployし続けることできる環境”を意識している • チームの健康診断的に使う ◦ 数値が変化したときになにか問題が起きていないのかチェックする 計測はしているが、目標にはしていない
16. 16 なぜDeployしやすい環境を求めるのか チーム構成 • Engineering Manager: 1人 • DARAでは、Deployment PainはWellbeingのページにかかれている ◦ これが組織のパフォーマンスを向上させると信じてる Deployしやすい環境が、エンジニアの開発生産性をあげる
17. 17 なぜエンジニアの開発生産性をあげるのか チーム構成 • Engineering Manager: 1人 素早く価値提供し、ビジネス貢献するため
18. 18 Deploy頻度の高さは、価値提供の大きさなのか チーム構成 • Engineering Manager: 1人 • なにが一番の価値提供になるのかはわからない • 100回のDeployより、1回のDeployの方がインパクトが大きいこともある • 継続して価値提供するために、とにかく打席(仮説検証)を創出する 直接結びつくことはない
19. 19 まとめ
20. 20 まとめ チーム構成 • Engineering Manager: 1人 • Deploy頻度の数値が最終目標ではない • なりたい姿をイメージして、その状態の定量的な指標の一つとして定義 • Deploy回数を計測する→数値を見て状態に気づく→Painはなにか？を探る なぜ改善する必要があるのか • 仮説検証をたくさん早く回すために開発生産性をあげたい ◦ 開発生産性をあげるために、Deployment Painをなくしたい Deployment Painがない環境を目指そう なりたい姿・状態をイメージして、改善していく
21. 21 おわり 採用してます！
22. 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. 23 チケットサイズ • 改修内容をできるだけ細かな価値提供サイズに分解しチケットを細かくする ◦ PRはさらに適切で小さな単位で作ってReview＆Deployする 例えば... 何かの管理画面を作る場合 • 管理画面を開くことができる • 管理画面で情報を取得できる(＆閲覧できる) • 管理画面で情報を更新できる • など… できるようになること単位で作っていく(ケースバイケースではある
24. 24 参考 https://engineering.mercari.com/blog/entry/20221215-devstats/ https://speakerdeck.com/myaake/fu-gang-falsecxptimufalseshao-jie-t okai-fa-falsegong-fu