Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Deployment Previewを用意する流れで学んだ良い仕事の進め方
Search
すてにゃん
June 22, 2023
Technology
0
1.2k
Deployment Previewを用意する流れで学んだ良い仕事の進め方
【非公式】PHPカンファレンス福岡全然野菜 [6/22] - connpass
で話した内容です
すてにゃん
June 22, 2023
Tweet
Share
More Decks by すてにゃん
See All by すてにゃん
dotfiles について話したい #湘なんか
stefafafan
2
350
意義から考えるObservability入門 #srenext
stefafafan
2
1.1k
高橋メソッド風の発表を生成するCLIツールをPHPで作った #phpcon_odawara
stefafafan
1
450
令和最新版 ソフトウェアエンジニアのためのDJ入門、あるいはDJに学ぶ仕事術 #ya8
stefafafan
2
490
一番やさしいDJ入門 2024
stefafafan
6
1.8k
『Goサブ会』によるチームを超えた知見展開、あるいは hatena.go に対する期待 #hatenago
stefafafan
0
1.9k
開発チーム横断タスクフォース 「Goサブ会」の 運用事例と今後の展望
stefafafan
0
710
Team Topologies輪読会とScrapboxの活用
stefafafan
1
290
チーム開発における様々なボトルネックの整理 / Organization of bottlenecks in Team Development
stefafafan
0
2.9k
Other Decks in Technology
See All in Technology
Wantedly での Datadog 活用事例
bgpat
1
410
大幅アップデートされたRagas v0.2をキャッチアップ
os1ma
2
520
組織に自動テストを書く文化を根付かせる戦略(2024冬版) / Building Automated Test Culture 2024 Winter Edition
twada
PRO
11
3.3k
NilAway による静的解析で「10 億ドル」を節約する #kyotogo / Kyoto Go 56th
ytaka23
3
370
Storage Browser for Amazon S3
miu_crescent
1
130
非機能品質を作り込むための実践アーキテクチャ
knih
2
660
レンジャーシステムズ | 会社紹介(採用ピッチ)
rssytems
0
150
新機能VPCリソースエンドポイント機能検証から得られた考察
duelist2020jp
0
210
あの日俺達が夢見たサーバレスアーキテクチャ/the-serverless-architecture-we-dreamed-of
tomoki10
0
420
LINEヤフーのフロントエンド組織・体制の紹介【24年12月】
lycorp_recruit_jp
0
530
Qiita埋め込み用スライド
naoki_0531
0
350
PHPからGoへのマイグレーション for DMMアフィリエイト
yabakokobayashi
1
160
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1030
460k
The Language of Interfaces
destraynor
154
24k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
247
1.3M
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
RailsConf 2023
tenderlove
29
940
Rebuilding a faster, lazier Slack
samanthasiow
79
8.7k
How STYLIGHT went responsive
nonsquared
95
5.2k
How to Ace a Technical Interview
jacobian
276
23k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
The World Runs on Bad Software
bkeepers
PRO
65
11k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Transcript
Deployment Previewを用意する 流れで学んだ良い仕事の進め方 id:stefafafan / @stefafafan 2023/06/22 【非公式】PHPカンファレンス福岡全然野菜 1
自己紹介 • すてにゃん (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 for MySQL に接続する 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