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

by すてにゃん

Slide 1

Slide 1 text

Deployment Previewを用意する流れで学んだ良い仕事の進め方 id:stefafafan / @stefafafan 2023/06/22 【非公式】PHPカンファレンス福岡全然野菜 1

Slide 2

Slide 2 text

自己紹介 ● すてにゃん (id:stefafafan / @stefafafan) ● 2015- 株式会社はてな ○ Webアプリケーションエンジニア ○ 最近はスクラムマスター、テックリードなど 2

Slide 3

Slide 3 text

自己紹介 ● 2023/5 に福岡に引っ越しました！ ○ 福岡に引越した - stefafafan の fa は3つです ○ 福岡のみなさまこれからよろしくお願いします 3

Slide 4

Slide 4 text

4 今日話すこと

Slide 5

Slide 5 text

今日話すこと ● チームに存在していた課題 ● 課題を解消するための手段の選択について ● プロジェクトをどのようにして段階的に進めたか ● プロジェクト終了後、1年弱経った今 5

Slide 6

Slide 6 text

6 チームの課題

Slide 7

Slide 7 text

前提 ● コンテナ化されているWebアプリケーションを運用中 ○ インフラは全体的にAWSで構成されている ● 手元環境を除くとstaging環境、本番環境の2つが存在していた ■ mainブランチの内容がstaging環境に自動デプロイされる 7

Slide 8

Slide 8 text

チームの課題 ● 課題: Feature Branch のレビューが大変 ○ デザインレビューができるメンバーが限られている ■ ローカル環境で動かして確認するコストが大きい ● どうにか解消できないか？ ○ →Deployment Previewを最終的に作る流れになった 8

Slide 9

Slide 9 text

9 課題を解消するための手段の選択

Slide 10

Slide 10 text

10 そもそも解決したい課題は何か

Slide 11

Slide 11 text

解決したい課題 ● デザイナーが作ったFeature Branchの内容を簡単にレビューできるようにしたい ○ 内容の確認ができれば何でも良い？ ■ 思いつく選択肢を色々出してみよう！ 11

Slide 12

Slide 12 text

選択肢の案出し ● a. Feature Branch をマージして staging で確認する ● b. 見た目の確認はスクショや動画で済ませる ● c. 手元で動いているものを画面共有でレビュアーにみてもらう ● d. Feature Branchの内容を自動でデプロイする 12

Slide 13

Slide 13 text

要件のすり合わせ ● スクショや動画での確認でも問題ないか？ ○ 見た目だけでなく、挙動の確認を行いたいため不足する ● staging での確認で問題ないか？ ○ 修正が必要な場合の手戻りが大きいので望ましくない ● 手元環境で動くものを画面共有で確認してもらうのは？ ○ 必ずしも同期的にレビューできるとは限らないので望ましくない 13

Slide 14

Slide 14 text

改善案の選択 ● a. Feature Branch をマージして staging で確認する ● b. 見た目の確認はスクショや動画で済ませる ● c. 手元で動いているものを画面共有でレビュアーにみてもらう ● d. Feature Branchの内容を自動でデプロイする 14

Slide 15

Slide 15 text

手段の選択についてわかったこと ● 課題があるから真っ先に解決のための実装に入るのではなく、先に以下のようなことを整理することが大事 ○ 1. 課題を正しく理解する ○ 2. 要件を整理する ○ 3. 効果やコストを元に手段を選択する 15

Slide 16

Slide 16 text

16 プロジェクトをどのようにして段階的に進めたか

Slide 17

Slide 17 text

要件の詳細を詰める ● 新しい環境を用意することは決まったが、詳細が未確定 ○ 結局何を作ればいいんだっけ？ ● 環境を必要とするのはエンジニアというよりデザイナー・企画メンバーがメイン ○ 職種に限定せず、要望をヒアリング 17

Slide 18

Slide 18 text

要件の詳細を詰める ● ヒアリングした結果決定した要件の一例 ○ 開発環境をセットアップしていないメンバーでも確認できる (企画職など) ○ エンジニアでなくとも簡単にデプロイできる ■ 可能ならP-Rが作られた際に自動的にデプロイ ○ 社内メンバーしかみられないように認証がかかっている 18

Slide 19

Slide 19 text

要件の詳細を詰める ● トレードオフスライダーを設定 ○ 何を重視するのかを決めるという意味 ○ 今回はデリバリーや品質 >> コストやスコープ ■ つまり、スコープを欲張りすぎずに、まずは「決まった期間の中で用意できるものを作る」ことでチームと合意した 19

Slide 20

Slide 20 text

技術選定 ● 要件にマッチした技術選定をする必要がある ● まずは社内外の事例をひたすらかき集めた 20

Slide 21

Slide 21 text

技術選定 ● 社内外の事例の一部 ○ Vercel, Heroku, Netlify, Cloudﬂare Pages, … ○ Amazon ECS をつかって自作 ○ Google Cloud Run をつかって自作 21

Slide 22

Slide 22 text

技術選定 ● Vercel等のサービスが一見魅力的だった ○ Deployment Previewに必要な諸々が作り込まれている ● ただし、いくつかの要件についての実現可能性が不明だった ○ 環境にユーザ認証をかけたい ○ Deployment Previewも自前のDBに接続させたい、DBは全公開させたくない ○ カスタマイズしたい箇所がいくつかある 22

Slide 23

Slide 23 text

技術選定 ● 特定のサービスに依存させたくない、自作するか ○ 社内ではAWSとGoogle Cloudは利用実績がある ■ チームとしてはここまでAWSを主に使っていた ○ Google Cloudに便利そうなグッズが揃っているし、個人的にもこの機会に触っていきたい ■ → Google Cloud でやってみよう！ 23

Slide 24

Slide 24 text

技術選定 ● Google Cloudで突然0から用意するには知識が足りない ● 作り始めた後に無理だとわかったら時間が勿体無い ● Proof of Concept (PoC) の作成から始めよう ○ 実際に環境を用意する前段階の検証のこと 24

Slide 25

Slide 25 text

PoCの作成 ● PoCを作る流れの一貫として、公式チュートリアルをいくつか試しつつ進めた ○ クイックスタート: Cloud Run にデプロイする ○ クイックスタート: Cloud Run から Cloud SQL for MySQL に接続する 25

Slide 26

Slide 26 text

PoCの作成 ● やっているうちになんとなく動くようになった ○ 細かいところは壊れているがとりあえずそれっぽいページが動きましたというのをチームに共有して進めた 26

Slide 27

Slide 27 text

PoCの作成 ● PoCを作ることで以下のメリットがあった ○ Google Cloudの土地勘を獲得 ○ Deployment Previewを実現できるという自信を得た ● 細かいところ含め改めてどう用意するかのイメージがついた上で本実装に入れるようになった ○ →このまま進めた結果無事環境が用意できた 27

Slide 28

Slide 28 text

28 詳しい実装についてはブログを参照ください Cloud RunとIdentity-Aware ProxyとGitHub ActionsでPull Request ごとのDeployment Previewを実現する - Hatena Developer Blog

Slide 29

Slide 29 text

ここまでわかったこと ● プロジェクトを進めるにあたって、以下のような段階を踏むと良いことがわかった ○ 1. 要件を詰めて曖昧なところを擦り合わせる ○ 2. 技術選定の際は社内外の情報を広く集めた上で絞り込むと良い ○ 3. PoCを作ることによって不確実性が下げられる 29

Slide 30

Slide 30 text

30 プロジェクト終了後、 1年弱経った今

Slide 31

Slide 31 text

環境を用意した1年後の今 ● Deployment Previewを用意したのは2022年の夏頃 ○ もちろん用意した直後は成果物に満足している ○ そのあとの運用についてはどうなのか？ 31

Slide 32

Slide 32 text

環境を用意した1年後の今 ● Deployment Previewは当たり前の存在として生活している ○ 当初の狙いではなかったが、Dependabotの出したブランチも物によってはDeployment Previewでも眺めてみて良さそうならマージしている 32

Slide 33

Slide 33 text

環境を用意した1年後の今 ● そんなに運用に苦労はしていない ○ 最初のうちは細かい設定がおかしくてCIが落ちたりしていたがいまは比較的安定している 33

Slide 34

Slide 34 text

環境を用意した1年後の今 ● 新たな課題 ○ 当初デリバリー優先で用意しなかった部分が足りていなくて少し不便 ■ サービスの管理画面を作るもののスコープから外していたけど、いまは確認したくなっている ■ 本番では動いているAWS LambdaなどがGoogle Cloud製の環境で動かず、確認ができない 34

Slide 35

Slide 35 text

1年運用してわかったこと ● 当初選んだ選択肢が運用していく中で影響してくる ○ 1. 開発当初スコープから外したものは運用していく中でほしくなることはある ○ 2. 技術選定の結果も後に影響が出ることがある ○ 3. 長く運用する場合「運用コスト」も設計において大事な検討ポイントとなる 35

Slide 36

Slide 36 text

36 まとめ

Slide 37

Slide 37 text

まとめ ● プロジェクト開発において以下のポイントが重要 ○ 課題や要件を正しく理解しよう ○ 選択肢は出せるだけ出してから絞り込むと良い ○ 時にはPoCなどを活用して不確実性を下げよう ○ 長く運用する場合はN年後の状態をイメージして要件を検討しよう 37