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をGASで継続的に改善したら幸せになった
Search
ああうえ
February 21, 2019
Technology
3
1.6k
CIをGASで継続的に改善したら幸せになった
ああうえ
February 21, 2019
Tweet
Share
More Decks by ああうえ
See All by ああうえ
iOS Apple Dev Tutorialsとpointfreeのモダン実装を比較する
kwzr
1
410
エンジニアとデザイナーがわかる iPadの画面サイズ対応入門
kwzr
0
100
react-reconcilerでオレオレReact Nativeを作ろう!
kwzr
1
2.1k
iOS・Androidで使える デザインシステムをどう実装するか
kwzr
3
5.2k
Apple Pencilと左利き対応
kwzr
5
2k
BitriseでUIの差分検出
kwzr
0
1.4k
Other Decks in Technology
See All in Technology
AWS CDKでデータリストアの運用、どのように設計する?~Aurora・EFSの実践事例を紹介~/aws-cdk-data-restore-aurora-efs
mhrtech
4
630
小規模に始めるデータメッシュとデータガバナンスの実践
kimujun
3
560
クライアントサイドでよく使われる Debounce処理 をサーバサイドで3回実装した話
yoshiori
1
140
サイバーエージェントにおける生成AIのリスキリング施策の取り組み / cyber-ai-reskilling
cyberagentdevelopers
PRO
2
180
[JAWS-UG金沢支部×コンテナ支部合同企画]コンテナとは何か
furuton
3
230
オーティファイ会社紹介資料 / Autify Company Deck
autifyhq
9
120k
日経電子版におけるリアルタイムレコメンドシステム開発の事例紹介/nikkei-realtime-recommender-system
yng87
1
480
LeSSに潜む「隠れWF病」とその処方箋
lycorptech_jp
PRO
2
120
生成AIとAWS CDKで実現! 自社ブログレビューの効率化
ymae
2
320
プロダクトチームへのSystem Risk Records導入・運用事例の紹介/Introduction and Case Studies on Implementing and Operating System Risk Records for Product Teams
taddy_919
1
160
君は隠しイベントを見つけれるか?
mujyun
0
270
omakaseしないための.rubocop.yml のつくりかた / How to Build Your .rubocop.yml to Avoid Omakase #kaigionrails
linkers_tech
3
710
Featured
See All Featured
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Teambox: Starting and Learning
jrom
132
8.7k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
27
1.9k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
790
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
32
1.8k
Side Projects
sachag
452
42k
Unsuck your backbone
ammeep
668
57k
Done Done
chrislema
181
16k
Scaling GitHub
holman
458
140k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
Bash Introduction
62gerente
608
210k
Transcript
CIをGASで継続的に 改善したら幸せになった CI/CD Test Night #3 pixiv Inc. kwzr /
Kazumasa Kawazure 2019.02.21
2 自己紹介 • kwzr / Kazumasa Kawazure ◦ Twitter :
@_kwzr_ • ピクシブでpixiv Sketch iOSの開発 ◦ 以前はいろんなiOS・Androidアプリの開発 • 情熱大陸に映り込んだことがある ◦ オレは情熱大陸出たことあるけど、キミは ? kwzr モバイルアプリエンジニア
• 2018年1月からBitriseに移行 ◦ 社内ライブラリなどを含めて21個のアプリが登録 ◦ 毎週約300回以上のビルド ◦ Org Standard Plan(最大6並列ビルド)
◦ 社内配布方法の変更 • サーバーサイドやWebフロントのことはわかりません ◦ Circle CIとGitLab CIを使っているはず 3 ピクシブのモバイルCI事情について
• 2018年1月からBitriseに移行 ◦ 社内ライブラリなどを含めて21個のアプリが登録 ◦ 毎週約300回以上のビルド ← どうやって取っているの ◦ Org
Standard Plan(最大6並列ビルド) ← どうやって決めたの ◦ 社内配布方法の変更 ← なに • サーバーサイドやWebフロントのことはわかりません ◦ Circle CIとGitLab CIを使っているはず 4 話すこと
• Jenkinsの介護がつらく、CIサービスを探していた ◦ 新しいXcodeが出たらインストールが必要 ◦ VPNを繋がないと見れない。特にスマホからアクセスしたい時に面倒 ▪ 社員以外の人にCIの結果を見てもらうのが難しかった ◦ 自作の配布ページを作ってそこから社内配布していた
▪ メンテあまりされていない ▪ アプリによってはDeployGateを使っていた 5 Bitriseに移行した流れ
• 言わずと知れたモバイルアプリ向け CIサービス • GUIでワークフローやトリガーを操作できる。 UIがかわいい(重要) • 他CIサービスと比べても比較的安価 • アプリの配布機能もある(Deploy
to Bitrise.io) • とてもよい! 6 Bitriseとは
• 最初はOrg Standard Plan(最大3並列)を導入 • 弊社、アプリの数が多い ◦ 参考: モバイルアプリエンジニア約20人 :
iOS・Androidアプリ 13個 • アプリのフルビルド時間は10-20分くらい掛かってとても長い • 思い思いにビルドを走らせると、最大 3並列ビルドだと頻繁に詰まる!! • → プラン変えよう! 7 移行してわかってきた問題
• Google Apps Script(GAS)とBitrise.io API v0.1を使用 ◦ Bitrise.io APIはまだWIPらしいけど、だいたい動いてる •
始業時間前に前日のビルドを集計して、スプレッドシートに記録 ◦ ビルド回数・ホールド時間・ビルド時間等 ◦ https://github.com/kvvzr/bitrise-collect ◦ 2018年2月から取ってる 8 まずは計測しよ...
• 手軽にデプロイできる • WebHookからの起動や、スケジューリングができる • 計測したいので、SpreadSheetに書き出したい • 普段使っている、慣れているもので要件を満たしていたらなんでも良さそう 9 なぜGAS?
• 置かれている状況による ◦ 金の弾丸が使えるなら、良いやつを選べば良さそう (適当) ▪ おそらく、稟議の起案理由に妥当なことを書く必要 ◦ 計測した結果を使って、状況に合うコスパの良いプランを選ぶ •
1日の総ホールド時間を基準にすることにした ◦ ホールド時間 = ビルド開始時間 - ビルド実行(トリガー)時間 10 何を見てプランを決めるか?
11 総ホールド時間の推移(2018/08-2018/12)
12 総ホールド時間の推移(2018/08-2018/12) Org Elite Plan 最大3並列ビルド 2 week trial ホールド時間減ってる
• Org Elite Planはハイスペックなマシンが使えるプラン ◦ 毎ビルド5分以上早く終わるようになってすごい! ▪ しかし、まだそこそこ詰まる ◦ 値段がOrg
Standard Planの倍 ◦ スペック上げるより、並列数増やしたほうが良さそう 13 計測してわかったこと
14 総ホールド時間の推移(2018/08-2018/12) Org Standard Plan 最大6並列ビルド 導入 狙い通り、ホールド時間がほ ぼ0になった
• 何を減らしたいのか ◦ 待ってる時間の人件費換算? (でも待ってる間別の作業できるし ... • 気持ち!!!!!!!1(のすり減り) ◦ ホールド待ちは他のプロジェクトが原因なのでヘイトが溜まる
◦ 自分のプロジェクトのビルドが遅いのは、ある程度自分でなんとかできる • → 並列数を上げるだけで、コスパよく気持ちの良い開発ができるように! ◦ 金の弾丸があれば、Elite Planを湯水のごとく使おう 15 総ホールド時間を基準にした理由
16
• 「ビルドして」トリガー ◦ Bitriseは現状Pushしたときに発火するトリガーのみ ◦ 定期的にチームや社内向けにアプリを配布したい!けど ◦ 配布物を作るビルドは長いので、必要なときだけ走らせたい! ▪ ユニットテストだけPushで走らせる
▪ だいたい半分くらいの時間 • 社内配布アプリの一覧ページ(あまりうまく機能しなかった) 17 その他の取り組み事例
18 とても便利
• GitHubのPRにコメントしたら、ビルドが走るようにする ◦ ポイントはPRトリガーとして実行すること ▪ PRにコメントするステップでPRの番号が取れない ◦ GitHub Actions使いたい 19
トリガーをGASで自作 「ビルドして」だった らAPI叩く WebHook Pull Request 結果を通知 GAS Bitrise
20 https://gist.github.com/kvvzr/8be18b134b3da1828bf0905df2625d40
• comment-on-github-pull-request っていうコミュニティステップ作った ◦ https://github.com/kvvzr/bitrise-step-comment-on-github-pull-request • PRに配布物へのリンク(QRコード)が紐づくと、過去のあの変更でどうなったか、追いやす くて良い ◦ Slackだけに流すと探すのが大変
21 宣伝: GitHubにコメントするステップ
• Bitriseはいいぞ • 置かれている環境によって計測してプランを検討しよう ◦ 他社がどういうプラン使っているのか調べても出てこなくてつらかった ◦ ワークフローに無駄がある場合もある。計測すると気付ける • GASなどを使えば計測もトリガーも手軽に自作できる
• ステップも簡単に作れるので、秘伝のタレを持っていたらステップ化しよう! スライド中にあるBitriseの価格は2019年2月21日のものです 22 まとめ