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
デプロイ完全自動化から1年で起きたこと /ikyu-deploy
Search
minato128
February 09, 2017
Programming
2
4.9k
デプロイ完全自動化から1年で起きたこと /ikyu-deploy
CI/CD NIGHT LT
https://teamspirit.connpass.com/event/49323/
minato128
February 09, 2017
Tweet
Share
More Decks by minato128
See All by minato128
Cloudflare Use Cases at CADDi
minato128
2
490
Azure Monitoring with Datadog Part 1
minato128
0
170
IIS URL Rewrite のユニットテストをしよう! /iis-url-rewrite-unit-test
minato128
1
870
新メール配信基盤への移行 /ikyu-mail-platform
minato128
7
5.8k
Other Decks in Programming
See All in Programming
Playwrightはどのようにクロスブラウザをサポートしているのか
yotahada3
7
2.3k
詳しくない分野でのVibe Codingで困ったことと学び/vibe-coding-in-unfamiliar-area
shibayu36
3
4.3k
GitHub Actions × AWS OIDC連携の仕組みと経緯を理解する
ota1022
0
240
ソフトウェア設計の実践的な考え方
masuda220
PRO
3
470
(Extension DC 2025) Actor境界を越える技術
teamhimeh
1
220
ABEMAモバイルアプリが Kotlin Multiplatformと歩んだ5年 ─ 導入と運用、成功と課題 / iOSDC 2025
akkyie
0
320
どの様にAIエージェントと 協業すべきだったのか?
takefumiyoshii
2
600
あなたの知らない「動画広告」の世界 - iOSDC Japan 2025
ukitaka
0
380
AI Coding Meetup #3 - 導入セッション / ai-coding-meetup-3
izumin5210
0
580
Web フロントエンドエンジニアに開かれる AI Agent プロダクト開発 - Vercel AI SDK を観察して AI Agent と仲良くなろう! #FEC余熱NIGHT
izumin5210
3
390
AIエージェント時代における TypeScriptスキーマ駆動開発の新たな役割
bicstone
4
1.5k
Чего вы не знали о строках в Python – Василий Рябов, PythoNN
sobolevn
0
160
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Learning to Love Humans: Emotional Interface Design
aarron
274
40k
Documentation Writing (for coders)
carmenintech
75
5k
Mobile First: as difficult as doing things right
swwweet
224
10k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
850
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.2k
How GitHub (no longer) Works
holman
315
140k
Rails Girls Zürich Keynote
gr2m
95
14k
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
Side Projects
sachag
455
43k
Balancing Empowerment & Direction
lara
4
680
Fireside Chat
paigeccino
40
3.7k
Transcript
デプロイ完全自動化から1年 で起きたこと 株式会社一休 株式会社一休 宿泊事業本部システム開発部 飯迫 正貴 2017/02/09 CI/CD NIGHT
LT
背景 背景
背景 • 2015/10 デプロイ完全自動化 – master branch merge • =>
Staging deploy – release branch merge – release branch merge • => Production deploy – 本番デプロイは週2回から4回に(当番制) • 2016/0x~ クラウド移行に向けて取組み を開始
詳しくはこちらで https://speakerdeck.com/kensuketanaka/ikyu-deploy-flow
前提 • スコープは宿泊システム • GHE => Jenkins => Data Center
• Git リポジトリは n GB – 軽量化の取組み中 – https://speakerdeck.com/kensuketanaka/ikyu- storage-improvement storage-improvement • 同じリポジトリでデザインデプロイも行っている • デザインデプロイとは? – デザイナーが使うデプロイフロー – 差分でリアルタイムデプロイ – d/xxxx branch を対象として Jenkins 側で処理させてい る • システムは f/xxxx branch
デプロイ完全自動化から 1年で起きたこと デプロイ完全自動化から 1年で起きたこと
序章 • 2016/04 – @kentana20 人事異動 – CI/CDまわりのメンテが引き継がれる – CI/CDまわりのメンテが引き継がれる
• かなり属人化していた • 2016/06 – 宿泊のエンジニアが急に増える
人が増えると • コミット/マージ数も増える • Staging 環境が常時デプロイ状態になる – Staging環境で動作確認ができない – システムデプロイ中はデザインデプロイがで
– システムデプロイ中はデザインデプロイがで きないので、デザイナーも困る – 鳴り止まないE2Eエラー
人が増えると • 本番デプロイ切り戻しも増える • WEBサーバーを前半後半に分けてデプロ イしていて自動化されているが、切り戻 しは手動で行っていた しは手動で行っていた – 当番制ではあるが、自動化された部分以外は
メンテナに頼りがち – 酷いときは週の半分くらいデプロイトラブル 対応 • つらい • 自分の仕事ができない
ひとりじゃ抱えきれない ひとりじゃ抱えきれない
そこで そこで
#deploy-working-group 結成 • 2016/09 – 各チームからひとり選出 – CI / CD
まわりの属人化を防ぐ – タスク分散 – タスク分散 – レビュー
デプロイワーキンググループ
デプロイワーキンググループ
やったこと やったこと
Staging デプロイ高速化 • そもそも遅すぎた – 30分以上かかっていた • リソース配置がSYNCサーバー頼み • Production
より簡素な仕組み • リファクタリング – Jenkins Job – Script (JS/Ruby) – Script (JS/Ruby) – symlink の活用 – ついでに Production も高速化 • SYNCサーバーからの脱却 • @midnight git gc • 最終的に15分で終わるように • 高速化ではないが、デプロイトリガーも見直し – master branch merge ではなく、数時間ごとの定期実行に変更 – こっちのほうが Staging 環境が安定する
失敗に強くする • デプロイ切り戻しの自動化 – ロールバック Job を作成 • リトライできるように –
Jenkins Job チェーンがリトライでリカバリーで きなかった きなかった • GitHub payload を同じファイルに常に上書きして後 続処理でも参照していた • ファイル名にビルド番号を付与して後続に渡すように 変更 – design_payload.[ビルド番号].json • 資料整備・共有 – 口頭での周知も
資料整備・共有
その他 • Selenium E2E • ユニットテスト • ブランチデプロイ環境 • GHEアップデートによる
payload 内容変更 • COM問題 GHEアップデートによる payload 内容変更 • COM問題 など デプロイだけでなく CI/CD まわりの大小さま ざまな問題に対応
一方、他のアプリは 一方、他のアプリは
順調にクラウドへ • 新しく作っているサービス – .NET Core – GitHub => Circle
CI => AWS – リリース済み • 既存の Classic ASP • 既存の Classic ASP – GitHub => AppVeyor => AWS – 検証終了 – リリース直前 • 既存の ASP.NET MVC / Web API – GitHub => AppVeyor => AWS – 検証終了 – リリース直前
まとめ まとめ
まとめ(と得た教訓) • 継続的改善 – 改善スコープの見極め大事 • (クラウド化などで)解決する見込みがある領域に安易に踏み 込まない – コスパを考える
• CI / CD は目的ではない グループで取り組む CI / CD は目的ではない • グループで取り組む – ひとりだとつらすぎる – 属人化も防ぎたい • CI / CD はできるだけシンプルな構成に保つ • 複雑化するとメンテも大変 • アプリケーションもできるだけシンプルな構成に保つ • aka デフォルト厨 / サンプルアプリケーションのような構成 • PaaS に載せられる状態がよい