Go to Qiita Advent Calendar 2024 Top
LoginSignup
32
11

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@shibukawa(Yoshiki Shibukawa)inフューチャー株式会社

DevOpsがあるなら、DevBuildがあってもいい

Last updated at Posted at 2017-10-05

今日もジムにいって疲れてポエムな気分なので。コーディングはいちおうしてますけどね。SVGで複数行テキストとかテキストの背景色を付ける話とかjQueryでループしながら直前に要素を挿入して無限ループでハマった話とか興味ないですよね？

なぜこう思ったのか。

JavaScriptのビルドは難しい

何かと話題になるJavaScript。コードを書き始める前の準備が壮大すぎて、やりたいことを忘れるぐらいです。あるあるですね。

僕なんかはもうツール設定がいやなので、Babel使わずに、コンフィグレスで使えるbrowserifyという組み合わせが好きなんですが、とはいえ、ツリーシェイキングでサイズ削減とか、SPAのページごとの遅延ダウンロードみたいな凝ったことをしようとしたらそれなりに手間暇かかるわけです。

もちろん、開発中はホットリロードしたいでしょうし、minifyスキップして、Chromeしか開発に使わないからES6のままBabel使わずに高速ビルドしたり、本番では当然紳士の身だしなみとしてminifyしてBabelで淑女（古いIE）への優しい心遣いを見せたいところですよね。linterオプションとかもバッチリキメたいですよね。

当然CIではクリーンビルドでパッケージングしてデプロイするし、もちろんCircle CIでガンガンテストも回しちゃおうとか当たり前ですよね？

でも当たり前じゃないです。

なかなかつらいです。

C/C++のビルドは難しい

C/C++のビルドは簡単です。

ただし、IDEでぽちっとやってできる範囲にする、あるいは自分が実行する環境のみに限定するならです。ライブラリ？rpmとかMacPortsとかにがんばってもらいましょう。

間違っても、マルチプラットフォームとか夢見ちゃいけません。あるいは、コマンドラインとIDEの両方でビルドしようとか、なるべくシステムに組み込みの共有ライブラリを使ってあげようとか、そういうことはやっちゃいけません。クロスコンパイルなんてもってのほかです。

それでもマルチプラットフォームにしたい場合は、ビルドツールが登場するわけですが、大抵のビルドツールは環境ごとの差分を吸収することに全力を注いでいます。闇です。例えばこんな闇があります。

この手のビルドツールも、それ単体で成り立っているわけではなく、CMakeなんかはMSBuildだったり、Visual Studioのプロジェクトだったり、GNUmakeだったり、XCodeのプロジェクトを生成したりして、そいつが最終的なビルドをしたりします。QMakeもそうですね。僕もかつて、ビルドツール作成を夢見て作ったことはありますが、それはそれは辛かったです。

かといって、CMakeを使えば幸せになるかというとそうでもなく、GUIアプリだったら、ビルド時にメタデータでバージョン埋め込んだり、開発者の名前を入れたりというのはOSごとに作法が違うのでいろいろ頑張らないといけない。あと、WiXなり、NSISなり、.dmgなりのいろんなインストーラが作れるのだけど、なかなかまとまった情報もない。そもそもそいつが完全なプログラミング言語だったりするので、自分が書きたいアプリケーションのために他のコードを書かされている気持ちになります。CMakeつらくて、CMakeの設定ファイルを生成するツールを作ったこともあります。Bazelとか使うと幸せになれるんですかね？

地味にめんどいのが、Windows。Qtをインストールすると、Qtのツールにパスが通ったbatファイルが生成されて、起動するとパス設定されたコマンドプロンプトが起動します。VC++を入れると、VC++のツールにパスが通ったbatファイルが生成されて、起動するとパス設定されたコマンドプロンプトが起動します。で、両方のパスを通すには・・・どうするんでしょうね。いつも手で設定を書いて、ConEmuでQt+VCの設定で起動できるようにしています。VC++とかのパス問題も、コンテナを作ってその中では環境変数汚し放題で全部パスを通してビルド環境を作るみたいになればいいんですかね。

はてさて、クロスコンパイルはどうするのがいいんでしょうね。最近だといろんなコンパイラ全部入りのDockerイメージがあります。それを使って、依存ライブラリをきちんと用意して、きちんといろいろな環境用にCMakeでクロスコンパイルを・・・というのにチャレンジしたいところだけど、C++が必要になるときには時間がないし、なかなか試せない。MSさんはVSCodeもいいけど、mac/Linux用のWindowsバイナリが作れるクロスコンパイラのVC++を出してください・・・

Build Engineer

こういう仕事はBuild Engineerという名前が海外ではついていたりするんですが、日本じゃ全然知られてないですよね。バズワードでもなんでもいいけど、こういう仕事にスポットがあたって、そういうのが得意な人が、じゃんじゃん活躍してくれるとみんな幸せになれそうです。開発環境好きな人はいますし。なるべその人にはそっちに時間を使えるようにしてあげる。開発環境よりもアプリケーション書きたい人にはコード書く時間をいっぱいあげる。ロールとして分けてあげたほうが人事の評価とかもしやすくなりそうな気がします。

「最近のJavaScript難しい」を因数分解すると、「環境構築難しい」と「プログラミング自体はクラスとか使えるようになって楽になった」「型チェックやLintによって助けられる部分が増えた」にはなるはず。環境構築専任の人にそこの部分のタスクを丸投げする、外注する、その部分のドキュメントをがんばって他の人のツラミを減らしてあげるとか、そういった努力が可能になるはずです。

なにしろ、この手のビルドツールというのはサンクコストが高すぎて（特にC++）、一度設定したらそれを使い続けることになりがちです（特にC++）。ビルドできる環境を整えるまでが時間がかかったり（特にC++）もしますし、ちょっとした要求の変更でビルドの設定がどんどん秘伝のタレみたいになります（特にC++）。そういうののリフレッシュにきちんとコストをかけて整えていくのも大事ですよね。

10/8追記

ゲーム関係は特に、クロスプラットフォーム同時開発だったり、プログラマー以外のアーティストやシナリオ、プランナーなどが入力したデータの目視確認環境を作ってあげたり、自動テストの仕組みを作り込むのにそれなりの時間とノウハウが必要だったり、ビルドエンジニアが活躍できる素地はかなり高い。そもそも、AAAタイトルだと、スタッフロールを見ると、プログラマーの10倍ぐらいアーティストがいる、というのも当たり前だったりするので、その9倍の人にサービスする仕事、という意味では費用対効果は大きいですね。

32
11
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
32
11

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?