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.8k
デプロイ完全自動化から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
460
Azure Monitoring with Datadog Part 1
minato128
0
160
IIS URL Rewrite のユニットテストをしよう! /iis-url-rewrite-unit-test
minato128
1
860
新メール配信基盤への移行 /ikyu-mail-platform
minato128
7
5.7k
Other Decks in Programming
See All in Programming
新メンバーも今日から大活躍!SREが支えるスケールし続ける組織のオンボーディング
honmarkhunt
5
7.9k
顧客の画像データをテラバイト単位で配信する 画像サーバを WebP にした際に起こった課題と その対応策 ~継続的な取り組みを添えて~
takutakahashi
1
120
iOS 26にアップデートすると実機でのHot Reloadができない?
umigishiaoi
0
130
GitHub Copilot and GitHub Codespaces Hands-on
ymd65536
2
150
PHPで始める振る舞い駆動開発(Behaviour-Driven Development)
ohmori_yusuke
2
410
RailsGirls IZUMO スポンサーLT
16bitidol
0
190
ISUCON研修おかわり会 講義スライド
arfes0e2b3c
1
450
MCPを使ってイベントソーシングのAIコーディングを効率化する / Streamlining Event Sourcing AI Coding with MCP
tomohisa
0
140
『自分のデータだけ見せたい!』を叶える──Laravel × Casbin で複雑権限をスッキリ解きほぐす 25 分
akitotsukahara
2
640
20250704_教育事業におけるアジャイルなデータ基盤構築
hanon52_
5
870
#QiitaBash MCPのセキュリティ
ryosukedtomita
1
1.4k
ニーリーにおけるプロダクトエンジニア
nealle
0
880
Featured
See All Featured
Making the Leap to Tech Lead
cromwellryan
134
9.4k
Automating Front-end Workflow
addyosmani
1370
200k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
6
310
The World Runs on Bad Software
bkeepers
PRO
69
11k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
Testing 201, or: Great Expectations
jmmastey
43
7.6k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Gamification - CAS2011
davidbonilla
81
5.4k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
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 に載せられる状態がよい