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
レベル1の開発生産性向上に取り組む − 日々の作業の効率化・自動化を通じた改善活動
kesoji
0
270
システム成長を止めない!本番無停止テーブル移行の全貌
sakawe_ee
1
220
CDK引数設計道場100本ノック
badmintoncryer
2
360
なぜ適用するか、移行して理解するClean Architecture 〜構造を超えて設計を継承する〜 / Why Apply, Migrate and Understand Clean Architecture - Inherit Design Beyond Structure
seike460
PRO
3
790
初学者でも今すぐできる、Claude Codeの生産性を10倍上げるTips
s4yuba
16
12k
GitHub Copilot and GitHub Codespaces Hands-on
ymd65536
2
150
NEWT Backend Evolution
xpromx
1
110
Goで作る、開発・CI環境
sin392
0
260
MDN Web Docs に日本語翻訳でコントリビュートしたくなる
ohmori_yusuke
1
130
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
810
AI時代の『改訂新版 良いコード/悪いコードで学ぶ設計入門』 / ai-good-code-bad-code
minodriven
22
9k
Node-RED を(HTTP で)つなげる MCP サーバーを作ってみた
highu
0
120
Featured
See All Featured
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.5k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
47
9.6k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
The World Runs on Bad Software
bkeepers
PRO
69
11k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Testing 201, or: Great Expectations
jmmastey
43
7.6k
Done Done
chrislema
184
16k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
20
1.3k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
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 に載せられる状態がよい