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
450
Azure Monitoring with Datadog Part 1
minato128
0
160
IIS URL Rewrite のユニットテストをしよう! /iis-url-rewrite-unit-test
minato128
1
850
新メール配信基盤への移行 /ikyu-mail-platform
minato128
7
5.7k
Other Decks in Programming
See All in Programming
PHPで始める振る舞い駆動開発(Behaviour-Driven Development)
ohmori_yusuke
2
230
Select API from Kotlin Coroutine
jmatsu
1
190
既存デザインを変更せずにタップ領域を広げる方法
tahia910
1
240
今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025
tkikuc
20
3.7k
Code as Context 〜 1にコードで 2にリンタ 34がなくて 5にルール? 〜
yodakeisuke
0
110
Enterprise Web App. Development (2): Version Control Tool Training Ver. 5.1
knakagawa
1
120
アンドパッドの Go 勉強会「 gopher 会」とその内容の紹介
andpad
0
270
AIコーディング道場勉強会#2 君(エンジニア)たちはどう生きるか
misakiotb
1
260
A2A プロトコルを試してみる
azukiazusa1
2
1.2k
システム成長を止めない!本番無停止テーブル移行の全貌
sakawe_ee
1
150
Beyond Portability: Live Migration for Evolving WebAssembly Workloads
chikuwait
0
400
たった 1 枚の PHP ファイルで実装する MCP サーバ / MCP Server with Vanilla PHP
okashoi
1
210
Featured
See All Featured
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Building an army of robots
kneath
306
45k
VelocityConf: Rendering Performance Case Studies
addyosmani
331
24k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.4k
Embracing the Ebb and Flow
colly
86
4.7k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Visualization
eitanlees
146
16k
Git: the NoSQL Database
bkeepers
PRO
430
65k
Designing Experiences People Love
moore
142
24k
Bash Introduction
62gerente
614
210k
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 に載せられる状態がよい