モジュールのビルドと配置

本ドキュメントの利用は、https://github.com/kae-made/kae-made/blob/main/contents-license.md に記載のライセンスに従ってご利用ください。

データ構造とロジックの実装が記述されたテキストファイルをコンパイルし、コンパイルされたファイル群とライブラリファイル群をリンクする一連の過程をビルドと呼びます。ビルドの過程は全て、決められた文法に従ってスクリプト化され、ビルド支援ツールにより自動化されます。機能追加やバグフィックスにより、データ構造やロジックの実装コードに変更が生じた場合は、再ビルドが行われます。膨大なテキストファイルから構成される大規模なソフトウェアの場合、毎回全てのビルドを行っていると、ビルド実行のためのコンピューティングリソースと多大な時間がかかってしまい、非効率です。ビルドのスクリプトは、更新されたテキストファイルが影響を及ぼす範囲のみビルド実行するように記述し、無駄なコンピューティングリソースや時間を費やさないようにしましょう。

ビルドスクリプトによる自動化

ビルドのスクリプト記述は、Linux系では、make（とconfigure）の Makefile や cmake の CMakeLists.txt の利用が一般的です。Makefile や CMakeLists.txt の記述方法は、欲しい成果物と、その成果物を得るために必要な項目やルール、成果物の構築方法を記述していくというスタイルで、手続き型のプログラミング言語の様な必要な処理を順番に書いていくようなスタイルとは全く異なります。筆者は1990年初頭にMakefileにチャレンジした時に、「ほう、処理の自動化の記述方法でこんなやり方もあるのか」と感銘を受けたことを覚えています。手続き型言語しか使ったことのないソフトウェア技術者にとって、Makefile や CMakeLists.txt の記述は、若干敷居は高いかもしれませんが、習得することをお勧めします。

Visual Studio でソフトウェア開発を行う場合（C++ の場合は Makefile、CMakeLists.txt が使われる場合もある）、プロジェクトを作成すると、ProjectName.xproj という拡張子（x の部分はプログラミング言語やプロジェクトの種類によって変わる）のファイルが自動作成され、このファイルの中にビルド方法が定義されています。手書きで .xproj ファイル群を書いて、msbuild というコマンドを使って独自のビルド環境の構築も可能です。

サードパーティ製ライブラリのインストールと作業の自動化

Linux 系 OS で、オープンソースなどサードパーティが提供するライブラリを使ったC/C++ のプログラムを作成する場合は、ビルドを行う前に、ライブラリを利用するためのヘッダーファイルやライブラリファイルを、apt コマンドなどを使ってOSにインストールする作業が必要です。サードパーティが提供するライブラリを使う場合は、使用するライブラリの適切なバージョンを選択しなければなりません。また、複数のライブラリを使う場合は、ライブラリ間の依存関係、バージョンの整合性やインストールの順番などにも気を配ります。

AI でよく使われる Python の場合は、Python 自身のバージョンや、AI フレームワークライブラリ間の依存関係、各ライブラリのバージョン、ライブラリが実行可能な CPU アーキテクチャなど、利用可能な組み合わせで問題が発生しがちです。Python のスクリプト内で import するライブラリのインストールについても、単に pip コマンドでインストール可能なものもあれば、Wheel を使ってのインストール、apt コマンドでの事前の必要なライブラリのインストール、更には、インストールの順番などにも注意が必要です。Python スクリプトを実行可能にするまでの設定手順を確立したら、一連の設定処理を自動化する仕組みを作ることをお勧めします。

このように、実行ファイルを動かすために OS への様々なライブラリのインストールが必要で、その作業を自動化したい場合は、Docker コンテナでの実行が適して言います。Docker の場合、一連の処理作業を Dockerfile で全て記述し、OS へのライブラリの一連のインストール処理や設定、アプリの起動までを自動化できます。
Docker の利用に限らず、実行ファイルやライブラリファイルのビルド（ビルドを行うための事前処理を含む）、及び、実行プラットフォーム上への配置と実行は、スクリプトファイルを作成して、自動化できるようにしておきます。

Linux 系 OS の場合は、UNIX 時代から伝統的に使われている Shell Script、Windows 系の場合は、MS DOS の時代から使われているバッチファイル形式や、今風なら PowerShell を使って、一連の処理を記述し、処理の自動化が行えます。

IoTソリューションを、「概念モデリング教本」で解説したソフトウェア開発プロセスで開発した場合、アプリケーションドメインの概念モデルは、分割され、IoTソリューションを構成する、IoT機器、現場のサーバー、クラウドサービス、ダッシュボード、PC、スマートフォンなどなどの、それぞれの実行プラットフォームに適したサービスドメインと実装技術の組合せが選択され、設計で定義された実装ルールに従いコード化されて、それぞれで動くソフトウェアに変換されます。

DevOps

IT システムは、リリース後、機能追加、障害対応などにより、継続的に更新が行われます。更新のたびにビルドが行われ、運用されているシステムの全部、あるいは一部が置き換えられます。ビルドと配置の自動化の仕組みは、運用開始後の再配置も含まれていなければなりません。昨今の IT システムでは、運用しながら開発が継続されていくようなスタイルは一般的になっています。この様な開発運用スタイルを、DevOps と呼び、最近では、DevOps を実践するための支援ツールやサービスが各社から提供されており、利用可能です。
例えば、マイクロソフトは、Azure DevOps というサービスを提供しており、ビルドと配置の自動化だけでなく、変更のトリガーとなる機能要求や障害情報、テスト、バージョン管理、開発計画、開発者間のコミュニケーション支援も支援する機能を提供しています。

２～４人程度の超小規模開発の場合は、この手のツールやサービスが無くても、DevOpsにおける推奨プラクティスを実践できるかもしれません。しかし、大勢の開発者が開発に携わるような中・大規模なソフトウェア開発では、可能な限り DevOps を実践するためのプラクティスを自動化するツールやサービスの利用を推奨します。ビジネス戦略の支援やビジネスプロセスの自動化を目的としたソフトウェアを開発する手段として IT 技術を活用しないのはナンセンスです。IT 技術の恩恵を受けずに、多大なコストをかけて、精神論を背景にした膨大な手作業を規定した分厚い開発プロセスマニュアルの作成と、大勢の開発者に浸透させる労力、そして、規定したプロセスが守られているかをチェックし従わせる労力にかかるコストは、支援ツールの導入にかかるコストの何十倍もかかるものです。

構成管理

データ構造とロジックがプログラミング言語に従ってコード化され、適度に分割されて記述されたテキストファイル群と、ビルドのプロセスが記述されたテキストファイル群、及び、実行プラットフォームへの配置方法が記述されたテキストファイル群は、それぞれの事情に応じて、それぞれのタイミング、頻度で更新されていきます。それぞれのファイルが更新された時に更新内容の記録とバージョンの付与、及び、ビルドで生成されたライブラリファイルや実行ファイルの記録とバージョン付け、及び、ビルド時に使われたファイル群のバージョンセットへのラベル付けを行い、物理モジュールの履歴を管理することを“構成管理”と言います。構成管理ではテキストファイルに加えて、アプリケーション画面で使われる画像ファイルや様々な設定ファイル、ビルドに必要なバイナリデータファイル等も同様にバージョン付けと更新時の履歴が保存されます。

構成管理では、単に物理モジュールの更新履歴を管理するだけでなく、誰が、いつ、何の目的で更新したかという情報も併せて保持されます。
ソフトウェアの開発では、コーディングと、テスト、運用は同時並行的に行われていくので、開発者の手元にあるテキストファイル群と、テストや運用で使われているライブラリファイルや実行ファイルをビルドした時のテキストファイル群の構成と中身は、大抵の場合一致しません。また、複数チームで並行開発を行っており、あるチームが作成したライブラリを別のチームが使うような場合も、ライブラリ開発者の手元にあるテキストファイル群と別のチームで使われているライブラリファイルをビルドした時点のテキストファイル構成も異なります。そのため、テストや運用、別チームの開発作業において、ライブラリや実行ファイルの実行中に障害が発見された場合の障害原因を調べるために、開発担当者の手元にあるその時点での開発中のテキストファイル群ではなく、使われているライブラリや実行ファイルをビルドした時点のテキストファイル構成に戻さなければなります。
この様な作業は、構成管理システムが無ければ、不可能です。構成管理システムは、複数チーム間での開発成果物の共有、進捗管理、障害管理、品質管理等の基盤であり、現代のITシステム開発においては、構成管理システムは必須のアイテムです。
加えて、次の節で紹介するリファクタリングの作業でも必須のアイテムです。

当然のことながら、構成管理システムは開発に携わるすべての開発関係者が共有するものなので、各開発者の好みによって選択されたツールやサービスの利用は許容されるものではなく、その開発に参加する全ての開発者が、同一の構成管理システムを利用しなければなりません。
構成管理システムは、開発者各人が個々人の開発成果物の構成管理を行うためのツールと、複数の開発者間で共有するためのサービスから成り立ちます。

個人的な構成管理のツールとしては、Git がデファクトになって久しいので、今時のソフトウェア開発者は、Git の基本的な使い方ぐらいは覚えておくようにしましょう。また、複数の開発者間での共有は、Git をベースにした、GitHub をはじめとするいくつかのサービスが利用できます。

構成管理用のツールは、UNIX 時代の SCCS、RCS から、CVS、SVN、ClearCase、VSS、TFS など Git がデファクトで利用されるまで、様々なツールが利用可能でしたが、いまだデファクトの構成管理ツールが確立していなかった2000年代は、構成管理システムをきちんと活用していた開発組織はそれほど多くなかったというのが筆者の印象です。2020年代の現時点では、全てのソフトウェア開発組織は、構成管理システムを正式に採用していると信じています。もしも、そのような構成管理システムは使っていない、ということであれば、その組織が、デジタルトランスフォーメーションやデジタルツインという言葉を使う資格はありません。

ソフトウェアを構成するプログラムコードは、書いて動けばそれで終わりではありません。運用・保守・機能拡張を継続的に行うためには、プログラムの継続的なメインテナンスが欠かせません。次の章では、メインテナンスのプラクティスである、「リファクタリング」について解説します。