みなさんこんにちは。発送が遅れていた3Dスキャナが先日手元に届いて、早速いろいろと試しているところです。10万円しない3Dスキャナでこんなに簡単にスキャンができてしまうのは本当に夢のようです。良い時代と言えばそうなのですが、反面日本の製造業がこれに対抗できるのか？ とか、3DCG屋さんの今後の仕事の在り方にもどんどん影響を及ぼしていく（これに関してはだいぶ前から起きていますが）なぁと思うといろいろ複雑な気持ちにもなります。そんなことを思いながら、さらにもう一台いい感じのものをクラウドファンディングで見つけてしまったのでプレッジしちゃいました（テヘペロー。次に届くのは8月予定なのでこれも楽しみです。

CI（継続的インテグレーション）ツール

前回は、作成したプログラムのパッケージ化とテストの作成・実行を行いました。プログラムのパッケージ化とテストの実行をシステム化できたことで、次にできるのは、パッケージの作成とテスト、リリースを機械に任せて自動化することです。

作成したコードのテストを手動で実行するのも十分強力な手段ですが、複数人で開発しているときに全体のテストを実行したいであるとか、常にコードが壊れていないか確認するために定期的にテストを実行するようにしたいといった欲求が出てきた場合に対応するのが難しいです。また、人力でテストを実行していると、テストを実行する頻度が落ちてきて、遂にはテストの整備もされなくなってしまうという負のスパイラルに陥ることもよくあります。

テストの自動化は、個人で開発している場合にもメリットがあります。手元の開発環境でのみビルドやパッケージ化を行う場合、ファイルをリポジトリに追加し忘れていたり、開発環境だけにセットアップされたライブラリに依存したまま忘れていたりします。そのため開発環境が変わった場合に、プログラムがビルドできない問題や、手作業で行う作業が残ることで時間が経ってからパッケージ化の手順を再現できなくなる問題などが起きやすくなります。開発環境とは別にパッケージ化する環境を用意し、その手順をコード化しておくことで、このような問題にも対応できます。

パッケージ化やテストを自動化するために、開発者が変更をリポジトリに反映した段階で自動的にビルドとテストが実行される環境を構築します。これによりコードが変更される度にテストが実行されるので、既存のコードを壊してしまうような変更が行われても、すぐ発見できるようになります。これを CI（継続的インテグレーション／Continuous Integration）と呼びます。

「継続的インテグレーション？ 何だか難しそう！！」と思うかもしれませんが、何かのトリガーを発端にしてバッチ処理を行なっているだけです（と言い切ってしまうのは流石に乱暴ですが;;）。トリガーは「自分でボタンを押す」でも良いですし、「リポジトリへのコードのpush」でも良いのです。幸いにも我々は既にgitを使ってバージョン管理を行い、テストの自動化やパッケージを作成するための技術を手にしています。これらの基礎技術をベースに、トリガーを発動するしくみと、トリガーを元にバッチ処理をするしくみを積み重ねるだけでCIが可能になります。

最近はCIツールも様々なサービスとして提供されるようになり、自分でサーバを立てなくても簡単に環境構築ができるようになってきています。有名なものではCircleCI、GitLab、AWS CodeBuild、GCP Cloud Buildなどがあります。これらはサービスとして提供されているため、自分の環境にマッチするのであれば採用を検討してみるのも良いでしょう。当社では自前で構築したJenkinsを使用しています。Jenkinsを使う理由はいくつかあります。

まず、Windowsで簡単に動作させることができるというのが大きいです。日本の3DCG制作の現場ではWindowsが採用されているケースが多いため、我々はどうしてもWindows上で動くツールの開発をしなければいけないです。そのため、CIツールもWindows上で動作する必要があります。Jenkinsはこの条件をクリアしています。

次に、ローカル環境でサーバを構築できることです。最近は何をするにしても、クラウド上に構築されたサービスとして提供され、インターネットを介してアクセスすることが前提になっているシステムが多いです。これも、Windows環境で動作するツールを開発しなければいけない場合に問題となります。さらに、もうひとつの大きな問題として、ソフトウェアとライセンスがあります。DCCツール上で動作するツールを作成する場合、テストを実行するためにはDCCツールを動かす必要があり、どこかにあるライセンスサーバにアクセスしなければいけません。これに既存サービスで対応するのはかなり大変です。また、ソフトウェアによっては、クラウド上にあるシステムで動かすこと自体がライセンス違反になる場合もあります。

さらに、OSのサービスではなくデスクトップアプリとして実行することも可能というのが非常に有難いです。OSのサービスとして実行される場合、GUIを表示することができないので、GUI付きのソフトウェアを実行できません。DCCツールには一応GUIなしモードが実装されている場合もありますが、GUIありのものと挙動がちがったり、エラーメッセージが問答無用でダイアログに表示されたりといったことが多々あります。特にサードパーティのプラグインを使用した場合にこの問題に突き当たることが多いです。このような場合でもデスクトップアプリとして実行していれば対応できます。このあたりは、レンダーサーバ構築でも似たようなことがありますね。

※余談ですが、Deadlineのプラグインのコードを読むと、世界中から集められたドロドログチャグチャな問題に対応するためにゲロを吐きながら対応した涙ぐましい努力の跡を目の当たりにすることができます。広く使われているプラグインでも平気でエラーメッセージをダイアログに表示していて、レンダーファーム上で実行すると処理が止まってしまうので逐一対応していたりします。

CD（継続的デリバリー）

CIができるようになると、コミットをするたびに動作確認のとれた成果物が生成されるようになります。そうなると、"あれ？ これをそのまま新バージョンとしてリリースできるようになるんじゃ！？！？” と考えるのはごく自然なながれです。これを行うのがCD（継続的デリバリー／Continuous Delivery）です。

流石にここまでやるには一山も二山（百山？）も超える必要はありますが、コードをコミットする度に新バージョンのソフトウェアがリリースされるようになるというのは、すごくないでしょうか。バージョン管理は当たり前、CI/CD環境まで整えて日々開発をしているチームと、バージョン管理なにそれ？ ツールのリリース時には適当に手動で動作確認をして終了としているチームがまともに戦えるわけがないのは火を見るよりも明らかです。

CI/CDがプログラムに与える影響

テストを書いたり、CI/CDを継続していくと、テストやCI/CDをやりやすいプログラムと、そうでないプログラムがあるということに気づきます。このちがいは、やりたいことをどのようにして実現するかというプログラムの構想段階で決まる部分も多いので、経験が少ない場合、そもそもプログラムを書く前から敗北していた……なんていうこともよくある話です。本連載の第36回で言及したGUIと処理の分離のお話も、このあたりの経験を積むと身に染みて（身を削りながら？）理解することができます。

また、テストがやりやすかったり、CI/CDにのせやすいプログラムというのは、ほかのプログラムから使いやすいプログラムということでもあります。これが嬉しいのは、複数のプログラムをまとめて処理の自動化を行うような場合でも、スムーズに処理を取り込むことができる点です。コードを書きながらテストを回し、その結果をフィードバックすることで、より良い設計や構造に修正する機会を得ることができ、さらに良いプログラムを開発するきっかけになるというメリットがあります。

まとめ

今回はCI/CDについてざっくりと紹介していきました。これらの内容を実践するとなると、けっこう大変なのでなかなか難しいですが、便利に使えそうなところを拾い集めて使うだけでも十分だと思います。毎度のことですが、CI/CDについて詳しく書くと数百ページの本ができてしまうほど語るべき内容が多いので、ここでは表層をサラッとお伝えすることしかできません。ぜひ、本記事に出てきたキーワードを手がかりにご自分で調べてみてください。

もちろん、自分たちがどこまでやるべきかを見極めるのもとても大切なことです。一度きりの使い捨てのコードであればバージョン管理システムを使わないこともざらにありますし、ある程度の規模があったとしても、コスト的にCI/CDをするまでもないという判断をすることもあるでしょう。最近はやりのRPAのように、非プログラマが日常業務をサクッと自動化することを目的とするために、テストのしやすさは問わないという選択肢もあります。ただ、選択肢として並べたうえで取捨選択するのと、そもそも選択肢にも上がらないのとでは大きなちがいがあります。

次回は実際にJenkinsを使って自動ビルド／テスト環境を構築していきます。
第45回の公開は、2022年8月を予定しております。