【ITニュース解説】DSCI pipeline to build c++ project using cmake

ソフトウェア開発の現場では、プログラムの作成からテスト、そして実際に使えるようにするための工程を効率的に自動化することが非常に重要である。この自動化を実現する仕組みの一つがパイプラインであり、DSCIパイプラインは、特にC++プロジェクトをCMakeというツールを使ってビルドする際に役立つ。システムエンジニアを目指す初心者にとって、このような自動化の概念や具体的な実装方法を理解することは、今後のキャリアにおいて非常に価値があるだろう。

このDSCIパイプラインのプロジェクトは、明確なファイル構成を持っている。プロジェクトのルートディレクトリには、パイプラインの定義を格納する.dsciディレクトリと、具体的な処理を行うためのジョブディレクトリが配置されている。.dsciディレクトリの中には、パイプライン全体の流れを定義するjobs.yamlファイルと、C++プロジェクトのビルドに関する処理をまとめたbuild_jobディレクトリがある。また、ビルドされたアプリケーションをデプロイ（配布）するための処理を行うdeploy_jobディレクトリも存在する。このように、役割ごとにディレクトリが明確に分けられているため、プロジェクト全体の見通しが良く、各部分の役割を理解しやすい構造となっている。

DSCIエンジンがパイプラインとして認識し、実行する唯一のYAMLファイルが.dsci/jobs.yamlである。このファイルは非常にシンプルで、実行するジョブの識別子（ID）と、そのジョブの定義が格納されているディレクトリのパスを羅列するだけである。複雑な設定や、実行条件を記述する必要がなく、必要なジョブを定義された順序で実行するように指示するだけで済むため、初心者でも理解しやすく、管理が容易であるという特徴を持つ。この例では、build_jobとdeploy_jobという二つの主要なジョブがこのファイルで定義されている。

一つ目の主要なジョブは、C++プロジェクトをビルドするためのbuild_jobである。このジョブは、ソースコードのコンパイル、テスト、そして最終的な実行可能ファイルの作成という一連の工程を自動化する。build_jobディレクトリの中には、ジョブのデフォルトパラメータを定義するconfig.yamlファイルと、各タスクの実行順序を制御するjob.bashスクリプトがある。config.yamlでは、ソースコードの場所、ビルドファイルの生成場所、使用するCMakeジェネレータ（ビルドシステムを生成するツール）、ビルドの種類（リリース版かデバッグ版か）といった基本的な設定を記述する。これらの設定は、必要に応じてjobs.yamlファイルから上書きすることも可能だ。

job.bashスクリプトは、このbuild_jobの中核となる部分であり、複数の小さなタスクを適切な順序で実行する役割を担う。具体的には、「設定（configure）」「ビルド（build）」「テスト（test）」「パッケージング（package）」という四つのタスクが、このスクリプトによって順次実行される。

最初のタスクであるconfigureは、configure/task.bashスクリプトで定義されている。このタスクの目的は、C++プロジェクトのビルド設定を行うCMakeツールを呼び出すことだ。CMakeは、プロジェクトのソースコードを解析し、それをコンパイルするために必要なファイル（例えばUnix Makefilesなど）を生成するツールである。このスクリプトでは、config.yamlで定義されたパラメータ（ソースディレクトリ、ビルドディレクトリ、ジェネレータ、ビルドタイプ）を読み込み、それらの情報を使ってビルドファイルを一時的に格納するためのディレクトリを作成し、cmakeコマンドを実行する。これにより、ソースコードの場所とビルドの種類に応じた、コンパイル準備のための環境が整えられる。

次に実行されるのがbuildタスク（build/task.bash）である。このスクリプトは、configureタスクで準備されたビルド環境（ビルドディレクトリ）に移動し、cmake --build .コマンドを実行することで、実際にC++のソースコードをコンパイルし、最終的な実行可能なバイナリファイルを生成する。-- -j$(nproc)というオプションは、利用可能なCPUのコア数を最大限に活用し、複数のコンパイル処理を並行して実行することで、ビルド時間を短縮するための指示である。

三つ目のタスクはtest（test/task.bash）である。コンパイルが成功し、実行可能ファイルが生成されたら、そのプログラムが意図通りに動作するかを確認する必要がある。このスクリプトはビルドディレクトリに移動し、ctest --output-on-failureコマンドを実行する。CTestはCMakeの一部として提供されるテストツールであり、C++プロジェクトのために書かれた単体テストを自動的に実行する役割を持つ。テストが失敗した場合でも、その詳細な出力が表示されるように設定されているため、問題の特定が容易になる。

ビルドジョブの最後のタスクはpackage（package/task.bash）である。このスクリプトは、ビルドされ、テストも完了した実行ファイルを、配布や次の工程で利用しやすい形式にまとめる役割を果たす。具体的には、ビルドディレクトリ内で生成された実行可能ファイル（例えばmyappという名前を仮定）をtar.gz形式に圧縮する。この圧縮されたファイルは「アーティファクト」と呼ばれ、~/artifacts/という特別な共有ディレクトリに保存される。この~/artifacts/ディレクトリは、DSCIによって自動的にマウントされ、異なるジョブ間でファイルやデータを共有するための場所として機能する。さらに、このpackageタスクでは、生成されたアーティファクトのパスを「状態」としてエクスポートする。これはupdate_stateコマンドを使ってJSON形式で行われ、後続のジョブがこの情報を読み取って利用できるようにするための、重要な連携メカニズムである。

二つ目の主要なジョブは、deploy_jobと呼ばれるデプロイジョブである。このジョブの目的は、前のbuild_jobで生成されたアーティファクトを利用して、そのアプリケーションを「デプロイ」（実際に使えるように配置する）することをシミュレートすることにある。deploy_jobディレクトリの中には、単一のデプロイタスクを実行するjob.bashスクリプトと、そのデプロイタスクをPythonで定義したdeploy/task.pyスクリプトがある。このデプロイジョブは、独自のconfig.yamlのような設定ファイルを持たず、前のジョブがエクスポートした「状態」のみを利用するという特徴を持つ。

deploy/task.pyスクリプトはPythonで記述されており、DSCIパイプラインが自動的に提供するconfig()関数を使って、前のジョブがエクスポートした状態を読み取る。具体的には、build_jobがエクスポートしたアーティファクトのパスを、cfg['_dsci_']['build_job']['artifact_path']という特定のパスを通じて取得する。このパスを受け取ったデプロイジョブは、そのアーティファクトの場所を知ることができるため、例えばパッケージリポジトリへのアップロード、リモートサーバーへのファイルコピー、クラウドサービスへの展開など、実際のデプロイ作業を行うことが想定される。今回の例では、簡潔さを保つために、受け取ったアーティファクトのパスを表示するだけで、実際のデプロイ処理はシミュレートにとどまっている。

このように、DSCIパイプラインは、BashスクリプトやPythonスクリプトといった汎用性の高いツールを活用し、複雑な設定を最小限に抑えながら、C++プロジェクトのビルドからテスト、そしてデプロイまでの一連の工程を自動化できる柔軟な仕組みである。jobs.yamlファイルがジョブのリストを記述するだけというシンプルな設計であり、各ジョブやタスクのロジックは、個別のスクリプトファイルに明確に分離されている点が特徴だ。これにより、特定のビルドシステムやCI/CDツールのドメイン固有言語（DSL）に深く依存することなく、標準的なシェルスクリプトやプログラミング言語の知識でパイプラインを構築・管理できる点が大きなメリットとなる。生成物であるアーティファクトや、ジョブ間で共有される状態の管理も、シンプルな仕組みで実現されており、異なるジョブ間でのデータ連携が容易に行える。システムエンジニアを目指す上で、このような自動化の仕組みを理解し、実際に活用できるスキルは、現代のソフトウェア開発において非常に価値が高いと言えるだろう。