Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

すてにゃん

June 22, 2023
Tweet

More Decks by すてにゃん

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  4. 4
    今日話すこと

    View full-size slide

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

    View full-size slide

  6. 6
    チームの課題

    View full-size slide

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

    View full-size slide

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

    8

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    26

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide