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