HEXA BLOG
ヘキサブログ
インフラ
HEXA BLOGその他インフラ2015.2.18
Jenkinsでのビルドパイプライン構築~導入編 なぜビルドの自動化は必要なのか?~
お久しぶりです 寒さが続く今日このごろ、いかがお過ごしでしょうか<img style="margin-left: 3px; margin-right: 3px; vertical-align: middle;" alt="" src="https://hexadrive.jp/hexablog-mae/wp-content/plugins/typepad-emoji-for-tinymce/icons/01/sun.gif" width="16" height="16" /> 私は未だに寒くて寒くてたまりません・・・<img style="margin-left: 3px; margin-right: 3px; vertical-align: middle;" alt="" src="https://hexadrive.jp/hexablog-mae/wp-content/plugins/typepad-emoji-for-tinymce/icons/07/shock.gif" width="16" height="16" /> 立春とは何だったのか・・・ まだまだ真冬じゃないか<img style="margin-left: 3px; margin-right: 3px; vertical-align: middle;" alt="" src="https://hexadrive.jp/hexablog-mae/wp-content/plugins/typepad-emoji-for-tinymce/icons/10/sign03.gif" width="16" height="16" /> と、内心思って喜怒哀楽の怒りと哀しみを強めに楽しんでいるノブです<img style="margin-left: 3px; margin-right: 3px; vertical-align: middle;" alt="" src="https://hexadrive.jp/hexablog-mae/wp-content/plugins/typepad-emoji-for-tinymce/icons/07/catface.gif" width="16" height="16" /> さて今回もJenkinsのお話をしていきます。 前回は<a href="https://hexadrive.jp/hexablog/others/infra/3701/">Jenkinsの設定を覗いていきました</a>が <span style="color: #ff0000;"><strong>「設定だけ覗いても使ってなきゃ意味わかんねーよ<img style="margin-left: 3px; margin-right: 3px; vertical-align: middle;" alt="" src="https://hexadrive.jp/hexablog-mae/wp-content/plugins/typepad-emoji-for-tinymce/icons/10/sign03.gif" width="16" height="16" />」</strong></span>って感じなので 実際に超基本的なパイプラインを構築してみようかと思います。 ・・・がその前に<strong><span style="color: #ff0000;">「そもそもCIツールって何のために必要なのか?メリットは?」</span></strong>というところが 弊社のブログでは<a href="https://hexadrive.jp/hexablog/creative/24523/">機能やざっくりとした概要・利点</a>は 語られているのですが、「なぜ必要?」という具体的なところはあまり語られていないので 先にその辺を語らせて頂いて、次回からビルドパイプライン構築の解説をさせていただきます。 <span id="more-4972"></span> プログラマーがよく使う「ビルド」という言葉は <em>「ソースコードをコンパイルして実行ファイル(いわゆる成果物)を作成する」</em> の意味で使われるかと思います。 Jenkinsはそのビルドを自動化してくれるCIツール、 つまり「ビルドの自動化」を支援するツールです。 「その程度なら手動でもよくね?」とか思いますが、それがよろしくない理由が大きく3つあります。 <strong><em>①ビルドに時間がかかる</em></strong> ざっくりとした言葉で集約しましたが、具体例をいくつか挙げます。 <em>例1)</em> チームルールとして<br /> 「Debug構成とRelease構成のビルドが通らないとバージョン管理システムにアップしちゃダメ」 というルールを設定したとします。 1つのビルドに5分かかったとしてそれを2構成、10分かかります。 最初のうちは真面目にやるかもしれませんが、私達はロボットではなく人間です。 その決まりを忘れて、あるいは怠けて、または時間短縮したいという欲望などで 決まりを無視してバージョン管理システムにアップしてしまうかもしれません。 もし、アップされたコードが原因でビルドエラーや実行時エラーが出たらどうでしょうか? <span style="color: #ff0000;">大人数で開発していると原因を突き止めたり、いつから起こっているのかも追うのが大変になります<img style="margin-left: 3px; margin-right: 3px; vertical-align: middle;" alt="" src="https://hexadrive.jp/hexablog-mae/wp-content/plugins/typepad-emoji-for-tinymce/icons/07/bearing.gif" width="16" height="16" /></span> <span style="color: #ff0000;">たったそれだけなんですが、それで大きなロスに繋がる可能性だってあるのです。</span> <em>例2)</em> 成果物(納品物)を作らないといけない場合、 自動化システムを作っていない場合は、誰かの席(主にプログラマー)で成果物を作ることになります。 つまりその誰かの時間を成果物を作る時間として毎回拘束しないといけなくなります。 そうなってしまうとその誰かだけが作業のロスをしてしまいます。 <span style="color: #ff0000;">「同じような作業なのに誰かがしないといけない・・・<img style="margin-left: 3px; margin-right: 3px; vertical-align: middle;" alt="" src="https://hexadrive.jp/hexablog-mae/wp-content/plugins/typepad-emoji-for-tinymce/icons/07/coldsweats02.gif" width="16" height="16" />」 結構ストレスの原因だったりします。</span> <strong><em>②環境に依存しているソースコードが混ざっているかもしれない</em></strong> 表題どおりですが、バージョン管理システムにアップされているものが 常にビルドができる、正常動作すると言うのは理想ですが現実で叶えるのは結構難しいです。 新しいシステムの追加や依存ソフトウェアの追加、現場はいつだってめまぐるしく変わります。 いざ、バージョン管理システムにアップされている最新のデータを取得してビルドした時に <span style="color: #ff0000;">自分の環境では動くのに、他ではビルドエラーが出たり実行時エラーが出てしまう・・・<img style="margin-left: 3px; margin-right: 3px; vertical-align: middle;" alt="" src="https://hexadrive.jp/hexablog-mae/wp-content/plugins/typepad-emoji-for-tinymce/icons/07/wobbly.gif" width="16" height="16" /> 結構あります。</span> <em><strong>③ソフトウェアにおける「ビルドの自動化」は色んな意味を含む</strong></em> これも表題どおりですが具体的な「ビルドの自動化」は以下の様なものの自動化もこの言葉に含まれます。 <strong>・ソースコードをコンパイルして成果物を作成する ・リソースをゲームで使用するデータへコンバートする(いわゆるデータビルド) ・実行テストを行う(いわゆるQAチェック)</strong> etc... ゲーム作りはゲームのプログラムはもちろん、データや実行テストいろんなものを 複合的かつ複雑にからみ合って出来ているのです。 <span style="color: #ff0000;">時間にもコストにも上限があります。 その中ですべてを手動で行うにはそれ相応の人数とリスクが必要なのです。</span> ①②は共有台を用意して自動でビルドを走らせるだけで、 個人に対する負担やチェックコスト、クオリティ維持の面でかなり変わってきます。<br /><span style="color: #ff0000;"><strong>「間違わないこと」は大事ですが、「間違いがすぐに気付ける環境」はもっと大事なのです<img style="margin-left: 3px; margin-right: 3px; vertical-align: middle;" alt="" src="https://hexadrive.jp/hexablog-mae/wp-content/plugins/typepad-emoji-for-tinymce/icons/10/sign03.gif" width="16" height="16" /></strong></span> ③に関してはプロジェクト次第ですが自動化を取り入れれば効果は高いです。 <strong><span style="color: #ff0000;">自動化した分だけソフトウェア開発やバグ潰しに注力できるのですから<img style="margin-left: 3px; margin-right: 3px; vertical-align: middle;" alt="" src="https://hexadrive.jp/hexablog-mae/wp-content/plugins/typepad-emoji-for-tinymce/icons/10/sign03.gif" width="16" height="16" /></span></strong> 上記の3つの不満はJenkinsを導入して、うまくビルドパイプラインが構築できれば かなり改善できます<img style="margin-left: 3px; margin-right: 3px; vertical-align: middle;" alt="" src="https://hexadrive.jp/hexablog-mae/wp-content/plugins/typepad-emoji-for-tinymce/icons/10/up.gif" width="16" height="16" /> ここまで色々メリットに近いことを述べてきましたが あまり語られないデメリットを少しだけ紹介しようと思います。 私が思うに細かいことを含めれば色々ありますが 大きいところで言うと<strong><span style="color: #ff0000;">「自動化ツールの保守、メンテナンス、拡張に担当者が必要」</span></strong> ということだと思っています。 当たり前といえば当たり前ですが、これは人手が足りないと そうも言っていられないのが正直な所ではないかと思います。 自動化ツールの担当者兼ソフトウェアプログラマーという方も少なくないかと思います。 自動化ツールの結果がなんかおかしい+プログラムで新しい実装がほしいという要望は 常にあり、特に開発初期、中期は同時に要望が飛んでくることも少なくないかと思います。 そんな時に1人に負荷が集中してしまうとパンクしてしまいます<img style="margin-left: 3px; margin-right: 3px; vertical-align: middle;" alt="" src="https://hexadrive.jp/hexablog-mae/wp-content/plugins/typepad-emoji-for-tinymce/icons/07/crying.gif" width="16" height="16" /> これの改善策は色々ありますが、個人的に思っているのは <strong><span style="color: #ff0000;">「ビルドの自動化はソフトウェア開発における重要な役目の一つ」</span></strong>だと 周りに認識してもらうことが一番の近道だと思っています。 「担当者を増やす」「ドキュメントを充実させる」などの具体的な対処策も重要だとは思いますが そもそも必要と感じてくれなければやる意味はないのです<img style="margin-left: 3px; margin-right: 3px; vertical-align: middle;" alt="" src="https://hexadrive.jp/hexablog-mae/wp-content/plugins/typepad-emoji-for-tinymce/icons/07/think.gif" width="16" height="16" /> どんな仕事でもそうですが、<strong><span style="color: #ff0000;">環境が変われば品質やモチベーションも変わってくると私は思っています。</span></strong> 色々長々と書いてしまいましたが、導入編はここまでです。 (もっと簡潔にまとめたいのですが、文章力が弱くてすみません・・・<img style="margin-left: 3px; margin-right: 3px; vertical-align: middle;" alt="" src="https://hexadrive.jp/hexablog-mae/wp-content/plugins/typepad-emoji-for-tinymce/icons/07/coldsweats01.gif" width="16" height="16" />) 次回は基本的なビルドパイプラインの構築をやっていこうと思います! それでは~<img style="margin-left: 3px; margin-right: 3px; vertical-align: middle;" alt="" src="https://hexadrive.jp/hexablog-mae/wp-content/plugins/typepad-emoji-for-tinymce/icons/04/paper.gif" width="16" height="16" />
CATEGORY
- about ヘキサ (166)
- 部活動 (6)
- CG (18)
- プロジェクトマネジメント (1)
- 研修 (5)
- 美学 (1)
- いいモノづくり道 (230)
- 採用 -お役立ち情報も- (149)
- プログラム (188)
- デザイン (99)
- ゲーム (274)
- 日記 (1,104)
- 書籍紹介 (113)
- その他 (875)
- 就活アドバイス (20)
- ラーメン (3)
- ライフハック (25)
- イベント紹介 (10)
- 料理 (23)
- TIPS (7)
- 怖い話 (3)
- サウンド (5)
- 子育て (1)
- 筋トレ (1)
- 商品紹介 (21)
- アプリ紹介 (31)
- ソフトウェア紹介 (33)
- ガジェット紹介 (12)
- サイト紹介 (10)
- 研究・開発 (34)
- 回路図 (4)
- アナログゲーム (40)
- 交流会 (21)
- 報告会 (3)
- インフラ (25)
- グリとブラン (6)
- カメラ (9)
- クラフト (27)
- 部活 (14)
- 画伯 (15)
- カレー (6)
- 音楽(洋楽) (6)
- 映画・舞台鑑賞 (43)
- 飼育 (5)
- いぬ (8)
- ねこ (19)
ARCHIVE
- 2024年
- 2023年
- 2022年
- 2021年
- 2020年
- 2019年
- 2018年
- 2017年
- 2016年
- 2015年
- 2014年
- 2013年
- 2012年
- 2011年
- 2010年
- 2009年
- 2008年
- 2007年