AnyTechの赤川です。
AnyTechでは、「手軽に試せる流体解析AIパッケージ」としてDeepLiquid Lite（以下、Liteと記載）というものを提供しております。DeepLiquid Liteはブラウザベースで稼働するソフトウェアとなっており、その開発メンバーとして参画しています。
今回は、我々が開発に利用している技術を紹介する第一弾として、CI/CDをどのようにしているかを紹介しようと思います。
CI/CDとは
まず簡単にCI/CDとは何かをここでまとめておきましょう。
CIとはContinuous Integrationの頭文字をとったものです。変更されたコードの品質をチェックするためのテストの実行であったり、コードのフォーマットのチェックなど色々なことを自動化することができます。
CDとはContinuous Deliveryの頭文字をとったものです。CDでは、ステージング環境へのデプロイや自動リリースプロセスなどが一般的に含まれているかと思います。
それぞれの詳しい解説については、さまざまな場所で説明されているのでここでは割愛させていただきます。
AnyTechではソースコードの管理をGitHubを用いて実施しているため、CI/CDについてはGitHub Actionsを利用して実施しています。GitHub Actionsについて詳しくは以下を参照ください。
CIをどのように利用しているか
次に、Liteを開発する上でどのような背景がありCIを利用しているかを説明させていただきます。
まずLiteの技術背景について簡単に説明させていただきます（それぞれより深い内容は別途紹介記事を執筆予定です）。2023/11時点ではLiteはフロントエンドとバックエンドから構成されており、それぞれ専用のDockerコンテナを立ち上げることで動作する仕組みとなっています。また、バックエンド内には個別の役割を持つ複数のコンテナ（以下、サーバと記載）が起動する仕組みになっています。そして、Liteは現時点ではオンプレミスサーバ（以下、物理サーバと記載）上で動作するソフトウェアとなっています。
上記を踏まえた上で、まずはCIをどのように導入しているかを説明させていただきます。上述のように、Liteは複数のサーバをベースとしたソフトウェアになっています。そのため、サーバごとの品質を保つために、以下を実行するためのワークフローをGItHub Actionsにて定義しています（サンプルはバックエンドのPythonサーバに対して適用しているものの例であり、一部省略しています）。
- スペルチェッカーを導入し、コード内で利用される単語をチェック（cspellを利用しています）
- uses: streetsidesoftware/cspell-action@v1 with: files: "xxx/**" root: "xxx" incremental_files_only: false config: "xxx/cspell.yml"
- ソースコードのフォーマットをチェックし、修正が必要な場合はエラーとなる仕組みになっています。例えばバックエンドはPythonを利用して開発されており、PEPに従うようにチェックが入るようになっています（なお、precommitの仕組みを入れているのでGitHubにpushされる前にフォーマットチェックは実行されていますが、検知漏れがあってはいけないので実施しています）。
- run: poetry run flake8 working-directory: xxx
- サーバごとにテストコードが用意されており、全てのテストコードが通ることが要求されます。
- run: poetry run pytest
PRが作成された際に自動的にCIが実行されるようになっており、CIが成功するまではPRがマージされることはありません。CIを導入することにより、開発されたコードの品質が一定担保されることにより、ロールバックが起こる可能性も減り、かつコード品質を維持した開発を実施できています。
CDをどのように利用しているか
次にCDをどのように利用してるかを説明します。まず前提として、Liteは上述のように物理サーバ上に構成される構成となっています。また、顧客ごとにセキュリティポリシーがあるため、外部ネットワークへの接続ができない場合も多くあります。そのため、CDを用いて直接物理サーバにデプロイすることは現時点では実施していません。
LiteはDockerコンテナを複数起動してサーバを構築し、それらを物理サーバで動かす構成にしています。物理サーバに対してコンテナイメージをデプロイする必要があるのですが、コンテナイメージを手動で作成しようとするとかなり手間がかかるので、CDでは主に各サーバをイメージとして配布できる形式にするための一連のワークフローが実装されています。概略としては以下のようなものが実装されています。
- コンテナイメージを格納するためにGCSとの連携を実行
- コード難読化処理を適用
- Dockerイメージをビルドしファイルに落とし込む
- GCSにアップロードする
また、CD実行時はパラメータを指定することにより、顧客の構成にあったコンテナイメージが自動的に構築されるようになっています。
まとめ
今回は、Lite開発についてどのようにCI/CDを適用しているかを説明させていただきました。CIを導入する前後を比較すると、コードの品質維持であったり、テストコードが実行されないまま開発が進むことを防ぐことができ、結果として開発ペースおよび品質維持がよりできていると考えています。またCDを利用することで、dockerイメージの管理であったりビルドプロセスを手動でする必要がなくなり、別の作業に時間を割くことができるようになり開発ペースが向上していることを実感しています。
CI/CDを構築したことがない方にとっては最初はハードルが高いと感じるかもしれませんが、導入するのとしないのとでは大きな差があると思いますので、ぜひ導入してもらえたらなと思います。
