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
何も考えずにCIや継続的デリバリーしたら辛くなった話.pdf
Search
ota42y
September 14, 2014
0
2.9k
何も考えずにCIや継続的デリバリーしたら辛くなった話.pdf
ota42y
September 14, 2014
Tweet
Share
More Decks by ota42y
See All by ota42y
バックログを導入し やっぱやめた話
ota42y
0
250
PFNにある2つのKubernetes
ota42y
10
5.4k
ゼロから作るDeep Learning 2 3章 word2vec 3.1〜3.2
ota42y
1
470
Q&A for How to use OpenAPI3 for API developer
ota42y
0
2.5k
How to use OpenAPI3 for API developer (RubyKaigi 2019)
ota42y
5
21k
How should we face with microservices (我々はマイクロサービスとどう向き合うべきか)
ota42y
20
4.7k
DeepLearningの本番環境にSageMakerを利用してる話
ota42y
1
6.3k
検索結果の良さを計測して定量的に改善していく
ota42y
3
2.4k
Flutterを広めるために技術同人誌を作った話
ota42y
1
1.6k
Featured
See All Featured
Code Review Best Practice
trishagee
65
17k
Become a Pro
speakerdeck
PRO
26
5k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Side Projects
sachag
452
42k
Writing Fast Ruby
sferik
628
61k
Done Done
chrislema
181
16k
Visualization
eitanlees
146
15k
GitHub's CSS Performance
jonrohan
1030
460k
Typedesign – Prime Four
hannesfritz
40
2.4k
Designing for Performance
lara
604
68k
The Invisible Side of Design
smashingmag
298
50k
Music & Morning Musume
bryan
46
6.2k
Transcript
何も考えずにCIや 継続的デリバリーしたら ⾟辛くなった話
継続的インテグレーション
CIのススメ リポジトリのコミットを監視して⾃自動実⾏行行 実行指示 コミットフック 定期実行
CIのススメ リポジトリのコミットを監視して⾃自動実⾏行行 テストやテストサーバに⾃自動デプロイ等 実行指示 コミットフック 定期実行 デプロイ テストサーバ
継続的デプロイのススメ たとえば毎⽇日のように、 細かく新機能をデプロイしていく⼿手法 本番サーバ 開発 deploy 一日に何回もぐらいのペースで繰り返す
Inspec'on Deploy Test Build CI (継続的インテグレーション) 本番サーバ 開発 deploy
一日に何回もぐらいのペースで繰り返す
Inspec'on Deploy Test Build CI (継続的インテグレーション) 本番サーバ 開発 deploy
一日に何回もぐらいのペースで繰り返す
┗(^o^ )┓ ┏┗ 最近は CIや継続的デリバリーが 流流⾏行行ってるらしいぞ
┏( ^o^)┛ ┛┓ このスマホアプリも 導⼊入しよう
┗(^o^ )┓ ┏┗
┏( ^o^)┛ ┛┓
┗(^o^ )┓ ┏┗
┏( ^o^)┛ ┛┓
三┏( ^o^)┛ 三 ┛┓ ヤルゾ
三┏( ^o^)┛ 三 ┛┓ | | § | |
| | | § | | ___§___ | Jenkins | ▼▼▼▼▼▼▼
§ § § § ティウンティウンティウン §
| | .§ | | | | |. §◎| | __◎§__◎ | Jenkins ◎_ | ▼◎▼ ▼◎ ▼◎
討ち死にました
何が起きたか 違う環境の⼿手法を、 ⼿手法ベースで持ってきたことで、 不不整合を起こして死んだ。
Job割り当てで死ぬ Jobを分割して平⾏行行ビルドできる! アップロードします
Job割り当てで死ぬ Jobを分割して平⾏行行ビルドできる! アップロードします アップロードします
Job割り当てで死ぬ Jobを分割して平⾏行行ビルドできる! アップロードします アップロードします アップロードします アップロードします アップロードします
Job割り当てで死ぬ Jobを分割して平⾏行行ビルドできる! アップロードします アップロードします アップロードします アップロードします アップロードします 同時に 送るな!!!
Job割り当てで死ぬ Jobを分割して平⾏行行ビルドできる! アップロードの平⾏行行処理理は⼤大体出来ない アップロードします アップロードします アップロードします アップロードします アップロードします 同時に 送るな!!!
Job割り当てで死ぬ ビルドしました ビルドしました ビルドしました ビルドしました ビルドしました
Job割り当てで死ぬ ビルドしました ビルドしました ビルドしました ビルドしました ビルドしました アップロードします
Job割り当てで死ぬ アップロード処理理だけ別Job化で排他制御 ビルドしました ビルドしました ビルドしました ビルドしました ビルドしました アップロードします
Job割り当てで死ぬ アップロード処理理だけ別Job化で排他制御 ビルドしました ビルドしました ビルドしました ビルドしました ビルドしました アップロードします DEAD LOCK
Job割り当てで死ぬ JenkinsはJobキューの制御が弱く 特定のキューのみ別の優先度度とか出来ない
Job割り当てで死ぬ JenkinsはJobキューの制御が弱く 特定のキューのみ別の優先度度とか出来ない ビルドしました ビルドしました ビルドしました ビルドしました 同時実⾏行行数4の場合
Job割り当てで死ぬ JenkinsはJobキューの制御が弱く 特定のキューのみ別の優先度度とか出来ない ビルドしました ビルドしました ビルドしました ビルドしました 実行待ちです… 同時実⾏行行数4の場合
Job割り当てで死ぬ JenkinsはJobキューの制御が弱く 特定のキューのみ別の優先度度とか出来ない 終了マダー? 終了マダー? 終了マダー? 終了マダー? 実行待ちです… 同時実⾏行行数4の場合
Job割り当てで死ぬ JenkinsはJobキューの制御が弱く 特定のキューのみ別の優先度度とか出来ない 終了マダー? 終了マダー? 終了マダー? 終了マダー? 4個以上同時には 処理出来ません
同時実⾏行行数4の場合
Job割り当てで死ぬ JenkinsはJobキューの制御が弱く 特定のキューのみ別の優先度度とか出来ない ビルドしました ビルドしました ビルドしました ビルドしました 同時実⾏行行数5に増やした
Job割り当てで死ぬ JenkinsはJobキューの制御が弱く 特定のキューのみ別の優先度度とか出来ない ビルドしました ビルドしました ビルドしました ビルドしました 同時実⾏行行数5に増やした ビルドしました
Job割り当てで死ぬ JenkinsはJobキューの制御が弱く 特定のキューのみ別の優先度度とか出来ない ビルドしました ビルドしました ビルドしました ビルドしました 実行待ちです… 同時実⾏行行数5に増やした ビルドしました
解決策 Jenkinsはノード事にJob制御が出来るため アップロード専⽤用ノードを作る
ビルドしました ビルドしました ビルドしました ビルドしました アップロードします 解決策 ビルド数4 ビルド数1 Node-‐A Node-‐B
リリースできなくて死ぬ
リリースできなくて死ぬ 継続的デリバリーでは 細かい単位でユーザに対してリリースする 手動デプロイ サーバ 自動デプロイ ユーザ 1⽇日1回~∼1⽇日何回も
リリースできなくて死ぬ スマホアプリは、直接配信ではなく、 プラットフォームに対して配信する 手動デプロイ 自動デプロイ ユーザ
リリースできなくて死ぬ 新バージョン出来た リリース作業 ユーザ
リリースできなくて死ぬ 新バージョン出来た リリース作業 ユーザ 公開: 最⼤大24時間 公開: 最⼤大24時間
リリースできなくて死ぬ 新バージョン出来た リリース作業 ユーザ 公開: 最⼤大24時間 審査: ⼀一週間程度度 公開: 最⼤大24時間
そもそも不不可能… (´́・_̲・`̀)
⽬目的を考える そもそも継続的デリバリーの何がいいの?
⽬目的を考える そもそも継続的デリバリーの何がいいの? リリース ユーザ
⽬目的を考える そもそも継続的デリバリーの何がいいの? リリース ユーザ ユーザの反応を⾒見見て直す
⽬目的を考える そもそも継続的デリバリーの何がいいの? リリース ユーザ ユーザの反応を⾒見見て直す ユーザの反応を、素早く得ることで、 作りすぎ等を避け、より早く ユーザにとっていいものを作れる
実際のユーザは無理理でも、 フィードバックをくれる⼈人なら意味がある 解決策 手動デプロイ 自動デプロイ
実際のユーザは無理理でも、 フィードバックをくれる⼈人なら意味がある 解決策 手動デプロイ 自動デプロイ 企画職や 別部署の⼈人
実際のユーザは無理理でも、 フィードバックをくれる⼈人なら意味がある 解決策 手動デプロイ 自動デプロイ 企画職や 別部署の⼈人
ビルドが⻑⾧長すぎて死ぬ
ビルドが⻑⾧長すぎて死ぬ テストは5分-‐‑‒10分、10分超えると⻑⾧長い (Rails本体ぐらい巨⼤大だと15-‐‑‒20分前後) 実行指示 コミットフック 定期実行 デプロイ テストサーバ
ビルドが⻑⾧長すぎて死ぬ ビルドに最低30分かかってた
ビルドが⻑⾧長すぎて死ぬ ビルドに最低30分かかってた タイミングが悪いと… ×××をビルドして!!!! コミットビルドと定期ビルド を実⾏行行中ですので、 1時間後に開始予定です
つらい… (´́・_̲・`̀)
⽬目的を考える そもそも何故詰まるほどビルドするのか? 定期的にデリバリーするため& 動かなくなった時に、素早く検知するため。 バグの早期発⾒見見で開発の効率率率を上げる為 →やっぱり待ち時間が⻑⾧長いのはまずいよね
解決策 待ち時間を早くするには ・ビルド時間を減らす ・並⾏行行処理理をする
解決策 待ち時間を早くするには ・ビルド時間を減らす ・並⾏行行処理理をする コードで頑張るには ⼿手間がかかる
解決策 待ち時間を早くするには ・ビルド時間を減らす ・並⾏行行処理理をする コードで頑張るには ⼿手間がかかる 複数台ビルドで 待ち時間短縮
解決策 待ち時間を早くするには ・ビルド時間を減らす ・並⾏行行処理理をする コードで頑張るには ⼿手間がかかる ⾦金金で解決! 複数台ビルドで 待ち時間短縮
解決策 待ち時間を早くするには ・ビルド時間を減らす ・並⾏行行処理理をする コードで頑張るには ⼿手間がかかる ⾦金金で解決! 複数台ビルドで 待ち時間短縮
分散ビルド、静的リンク等も模索中… Xcodeは分散できないけど
まとめ この⼿手法いいよ!っていうのを 考えなしに持ってくるのと失敗する なんのためにやってるのか、⽬目的を考え、 ⼀一番あった⼿手法にきちんと落落とし込むべき 導⼊入は⼤大変だけど、 効果はかなり⾼高い気がする