Deployment Previewを用意する流れで学んだ良い仕事の進め方

【非公式】PHPカンファレンス福岡全然野菜 [6/22] - connpass で話した内容です

Transcript

1. Deployment Previewを用意する 流れで学んだ良い仕事の進め方 id:stefafafan / @stefafafan 2023/06/22 【非公式】PHPカンファレンス福岡全然野菜 1
2. 自己紹介 • すてにゃん (id:stefafafan / @stefafafan) • 2015- 株式会社はてな ◦ Webアプリケーションエンジニア ◦ 最近はスクラムマスター、テックリードなど 2
3. 自己紹介 • 2023/5 に福岡に引っ越しました！ ◦ 福岡に引越した - stefafafan の fa は3つです ◦ 福岡のみなさまこれからよろしくお願いします 3
4. 4 今日話すこと
5. 今日話すこと • チームに存在していた課題 • 課題を解消するための手段の選択について • プロジェクトをどのようにして段階的に進めたか • プロジェクト終了後、1年弱経った今 5
6. 6 チームの課題
7. 前提 • コンテナ化されているWebアプリケーションを運用中 ◦ インフラは全体的にAWSで構成されている • 手元環境を除くとstaging環境、本番環境の2つが存在し ていた ▪ mainブランチの内容がstaging環境に自動デプロイされる 7
8. チームの課題 • 課題: Feature Branch のレビューが大変 ◦ デザインレビューができるメンバーが限られている ▪ ローカル環境で動かして確認するコストが大きい • どうにか解消できないか？ ◦ →Deployment Previewを最終的に作る流れになっ た 8
9. 9 課題を解消するための 手段の選択
10. 10 そもそも解決したい 課題は何か
11. 解決したい課題 • デザイナーが作ったFeature Branchの内容を簡単にレ ビューできるようにしたい ◦ 内容の確認ができれば何でも良い？ ▪ 思いつく選択肢を色々出してみよう！ 11
12. 選択肢の案出し • a. Feature Branch をマージして staging で確認する • b. 見た目の確認はスクショや動画で済ませる • c. 手元で動いているものを画面共有でレビュアーにみて もらう • d. Feature Branchの内容を自動でデプロイする 12
13. 要件のすり合わせ • スクショや動画での確認でも問題ないか？ ◦ 見た目だけでなく、挙動の確認を行いたいため不足する • staging での確認で問題ないか？ ◦ 修正が必要な場合の手戻りが大きいので望ましくない • 手元環境で動くものを画面共有で確認してもらうのは？ ◦ 必ずしも同期的にレビューできるとは限らないので望まし くない 13
14. 改善案の選択 • a. Feature Branch をマージして staging で確認する • b. 見た目の確認はスクショや動画で済ませる • c. 手元で動いているものを画面共有でレビュアーにみて もらう • d. Feature Branchの内容を自動でデプロイする 14
15. 手段の選択についてわかったこと • 課題があるから真っ先に解決のための実装に入るのでは なく、先に以下のようなことを整理することが大事 ◦ 1. 課題を正しく理解する ◦ 2. 要件を整理する ◦ 3. 効果やコストを元に手段を選択する 15
16. 16 プロジェクトをどのように して段階的に進めたか
17. 要件の詳細を詰める • 新しい環境を用意することは決まったが、詳細が未確定 ◦ 結局何を作ればいいんだっけ？ • 環境を必要とするのはエンジニアというよりデザイナー ・企画メンバーがメイン ◦ 職種に限定せず、要望をヒアリング 17
18. 要件の詳細を詰める • ヒアリングした結果決定した要件の一例 ◦ 開発環境をセットアップしていないメンバーでも確認で きる (企画職など) ◦ エンジニアでなくとも簡単にデプロイできる ▪ 可能ならP-Rが作られた際に自動的にデプロイ ◦ 社内メンバーしかみられないように認証がかかっている 18
19. 要件の詳細を詰める • トレードオフスライダーを設定 ◦ 何を重視するのかを決めるという意味 ◦ 今回は デリバリーや品質 >> コストやスコープ ▪ つまり、スコープを欲張りすぎずに、まずは「決まった期間 の中で用意できるものを作る」ことでチームと合意した 19
20. 技術選定 • 要件にマッチした技術選定をする必要がある • まずは社内外の事例をひたすらかき集めた 20
21. 技術選定 • 社内外の事例の一部 ◦ Vercel, Heroku, Netlify, Cloudflare Pages, … ◦ Amazon ECS をつかって自作 ◦ Google Cloud Run をつかって自作 21
22. 技術選定 • Vercel等のサービスが一見魅力的だった ◦ Deployment Previewに必要な諸々が作り込まれている • ただし、いくつかの要件についての実現可能性が不明だった ◦ 環境にユーザ認証をかけたい ◦ Deployment Previewも自前のDBに接続させたい、DBは 全公開させたくない ◦ カスタマイズしたい箇所がいくつかある 22
23. 技術選定 • 特定のサービスに依存させたくない、自作するか ◦ 社内ではAWSとGoogle Cloudは利用実績がある ▪ チームとしてはここまでAWSを主に使っていた ◦ Google Cloudに便利そうなグッズが揃っているし、 個人的にもこの機会に触っていきたい ▪ → Google Cloud でやってみよう！ 23
24. 技術選定 • Google Cloudで突然0から用意するには知識が足りない • 作り始めた後に無理だとわかったら時間が勿体無い • Proof of Concept (PoC) の作成から始めよう ◦ 実際に環境を用意する前段階の検証のこと 24
25. PoCの作成 • PoCを作る流れの一貫として、公式チュートリアルをい くつか試しつつ進めた ◦ クイックスタート: Cloud Run にデプロイする ◦ クイックスタート: Cloud Run から Cloud SQL for MySQL に接続する 25
26. PoCの作成 • やっているうちになんとなく動くようになった ◦ 細かいところは壊れているがとりあえずそれっぽい ページが動きましたというのをチームに共有して進め た 26
27. PoCの作成 • PoCを作ることで以下のメリットがあった ◦ Google Cloudの土地勘を獲得 ◦ Deployment Previewを実現できるという自信を得た • 細かいところ含め改めてどう用意するかのイメージがつ いた上で本実装に入れるようになった ◦ →このまま進めた結果無事環境が用意できた 27
28. 28 詳しい実装についてはブログを参照ください Cloud RunとIdentity-Aware ProxyとGitHub ActionsでPull Request ごとのDeployment Previewを実現する - Hatena Developer Blog
29. ここまでわかったこと • プロジェクトを進めるにあたって、以下のような段階を 踏むと良いことがわかった ◦ 1. 要件を詰めて曖昧なところを擦り合わせる ◦ 2. 技術選定の際は社内外の情報を広く集めた上で絞り 込むと良い ◦ 3. PoCを作ることによって不確実性が下げられる 29
30. 30 プロジェクト終了後、 1年弱経った今
31. 環境を用意した1年後の今 • Deployment Previewを用意したのは2022年の夏頃 ◦ もちろん用意した直後は成果物に満足している ◦ そのあとの運用についてはどうなのか？ 31
32. 環境を用意した1年後の今 • Deployment Previewは当たり前の存在として生活して いる ◦ 当初の狙いではなかったが、Dependabotの出したブ ランチも物によってはDeployment Previewでも眺め てみて良さそうならマージしている 32
33. 環境を用意した1年後の今 • そんなに運用に苦労はしていない ◦ 最初のうちは細かい設定がおかしくてCIが落ちたりし ていたがいまは比較的安定している 33
34. 環境を用意した1年後の今 • 新たな課題 ◦ 当初デリバリー優先で用意しなかった部分が足りてい なくて少し不便 ▪ サービスの管理画面を作るもののスコープから外していたけ ど、いまは確認したくなっている ▪ 本番では動いているAWS LambdaなどがGoogle Cloud製の 環境で動かず、確認ができない 34
35. 1年運用してわかったこと • 当初選んだ選択肢が運用していく中で影響してくる ◦ 1. 開発当初スコープから外したものは運用していく中 でほしくなることはある ◦ 2. 技術選定の結果も後に影響が出ることがある ◦ 3. 長く運用する場合「運用コスト」も設計において大 事な検討ポイントとなる 35
36. 36 まとめ
37. まとめ • プロジェクト開発において以下のポイントが重要 ◦ 課題や要件を正しく理解しよう ◦ 選択肢は出せるだけ出してから絞り込むと良い ◦ 時にはPoCなどを活用して不確実性を下げよう ◦ 長く運用する場合はN年後の状態をイメージして要件 を検討しよう 37