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.6k
デプロイ完全自動化から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
Azure Monitoring with Datadog Part 1
minato128
0
120
IIS URL Rewrite のユニットテストをしよう! /iis-url-rewrite-unit-test
minato128
1
730
新メール配信基盤への移行 /ikyu-mail-platform
minato128
7
5.3k
Other Decks in Programming
See All in Programming
最古の関数型言語「Lisp」ことはじめ / lisp_in_kamiyama
uhooi
1
190
feature環境をGitHub ActionsとCloudFormationでいい感じに管理する
nealle
2
310
はしめてのプログラミングとロボット制御
watawatavoltage
0
290
Xcode 16のPreviewModifierと@Previewableを活用した効率的なプレビュー方法の考察
ojun9
2
160
3 Effective Rules for Success with Signals in Angular
manfredsteyer
PRO
0
120
みんなのオブザーバビリティプラットフォームを作ってるんだがパフォーマンスがやばい #mackerelio #srenext
ne_sachirou
0
380
CSC307 Lecture 11
javiergs
PRO
0
240
Namespace on read
tagomoris
2
370
Terraformテスト入門
msato
0
540
From Spring Boot 2 to Spring Boot 3 with Java 22 and Jakarta EE
ivargrimstad
0
1.9k
さきがけから振り返るアーキテクチャ刷新 / Reflecting on the Architectural Renewal from the Vanguard
nrslib
2
780
生成AIをkintoneに連携してみた
hideg
0
230
Featured
See All Featured
Embracing the Ebb and Flow
colly
81
4.3k
Into the Great Unknown - MozCon
thekraken
20
1.3k
What the flash - Photography Introduction
edds
65
11k
How to name files
jennybc
67
96k
Raft: Consensus for Rubyists
vanstee
134
6.5k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
226
52k
A Philosophy of Restraint
colly
200
16k
Bash Introduction
62gerente
607
210k
A designer walks into a library…
pauljervisheath
201
24k
Large-scale JavaScript Application Architecture
addyosmani
506
110k
How GitHub Uses GitHub to Build GitHub
holman
471
290k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
189
16k
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 に載せられる状態がよい