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
310
意義から考えるObservability入門 #srenext
stefafafan
2
1.1k
高橋メソッド風の発表を生成するCLIツールをPHPで作った #phpcon_odawara
stefafafan
1
370
令和最新版 ソフトウェアエンジニアのためのDJ入門、あるいはDJに学ぶ仕事術 #ya8
stefafafan
2
410
一番やさしいDJ入門 2024
stefafafan
6
1.7k
『Goサブ会』によるチームを超えた知見展開、あるいは hatena.go に対する期待 #hatenago
stefafafan
0
1.8k
開発チーム横断タスクフォース 「Goサブ会」の 運用事例と今後の展望
stefafafan
0
650
Team Topologies輪読会とScrapboxの活用
stefafafan
1
250
チーム開発における様々なボトルネックの整理 / Organization of bottlenecks in Team Development
stefafafan
0
2.8k
Other Decks in Technology
See All in Technology
分析者起点の企画を成功させた連携面の工夫
lycorptech_jp
PRO
1
220
【shownet.conf_】ShowNet伝送改めShowNet APN 2024
shownet
PRO
0
320
How CERN serves 1EB of data via FUSE
ennael
PRO
0
16k
Rubyはなぜ「たのしい」のか? / Why is Ruby a programmers' best friend? #tqrk15
expajp
4
1.7k
Report of JAWS PANKRATION 2024, a global online event using Amazon IVS
yoshimi0227
1
130
Pythonを活用したLLMによる構造的データ生成の手法と実践
brainpadpr
3
220
KDD2024参加報告
cyberagentdevelopers
PRO
1
200
ガバメントクラウド開発と変化と成長する組織 / Organizational change and growth in developing a government cloud
kazeburo
2
380
リスクから学ぶKubernetesコンテナセキュリティ/k8s-risk-and-security
mochizuki875
1
260
入門 バックアップ
ryuichi1208
13
4.2k
Oracle GoldenGate 23ai 導入Tips
oracle4engineer
PRO
1
200
10Xでのデータ基盤の変遷とこれから: データマネジメントのリアル 〜BtoB企業3社の歩みとこれから〜
10xinc
6
1.2k
Featured
See All Featured
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
What's new in Ruby 2.0
geeforr
341
31k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
44
2k
Code Reviewing Like a Champion
maltzj
519
39k
Mobile First: as difficult as doing things right
swwweet
222
8.8k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
125
18k
Building Better People: How to give real-time feedback that sticks.
wjessup
360
19k
Ruby is Unlike a Banana
tanoku
96
11k
How to train your dragon (web standard)
notwaldorf
87
5.6k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
30
2.6k
A Philosophy of Restraint
colly
202
16k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
7
560
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