LabVIEWにおけるソフトウェア構成管理 (SCM)

多くの開発者は、開発者同士が互いの変更を上書きしたり、リビジョンを追跡できなかったりという、管理されていない環境にフラストレーションを感じてきました。大量のファイルや複数の開発者を管理することは、どのような環境でも難題です。このため、大規模な開発プロジェクトでは以下の目標を達成するために構成管理ツールが使用されています。

1. 一元的なコードリポジトリにアクセスできるようにする
2. 同じアプリケーションの複数のバージョンを管理し、追跡する
3. 複数の開発者を管理する
4. 変更が行われたタイミングと変更の影響を特定する
5. 競合する変更を検出し、解決する
6. コードの最新バージョンを配布し、デプロイする
7. コードの以前のバージョンをバックアップし、保存する
8. 再利用ライブラリを管理し、配布する

ツールと手法の選定は、特定のプロジェクトまたはチームにとっての前述の目標の重要性および達成の必要度によって大きく変わります。  効果的な構成管理を行うには、まずアプリケーション階層をよく整理します。 LabVIEWアプリケーションにおけるファイルとフォルダの整理の詳細については、「Best Practices for Managing NI LabVIEW Applications Using the Project Explorer」を参照してください。

開発チームが小規模であるシンプルなアプリケーションでも、ファイル管理とリビジョン管理を行う高度なツールからメリットを得られることに気づく必要があります。  このような理由から、ソースコード管理は、ありとあらゆる開発プロジェクトに対し、ほぼ必ず推奨されているものです。

プロジェクトの複雑性やチームの規模に関係なく、ソースコード管理は重要です。LabVIEWファイルを追跡、保存、管理するのに使用できるさまざまなソースコード管理ツールが、いろいろなベンダから販売されています。 販売されているツールは、Subversionなどの無償で使いやすいソリューションから、PerforceやMicrosoft Team Foundation Serverなどエンタープライズレベルのライフサイクル管理ソリューションまで、多岐にわたっています。

LabVIEWとソースコード管理の統合は、さまざまなアプローチで実現できます。VIのファイル形式はバイナリですが、他の環境で適用されるのと同じ手法をVIなどのLabVIEWのファイルタイプにも適用することは、可能なだけでなく必要でもあります。ただし、適用するには、ソースコード管理クライアントをカスタム構成する必要があります。

図1はソースコード管理のチェックイン/チェックアウトモデルを示す

図1は、チームベースのプロジェクトの開発プロセスがソースコード管理によって改善される例を示しています。 開発者は、単にコードをコピーするのでなく、ソースコード管理を使用してコードをチェックアウトするようになりました。 チェックアウトにより、開発者がソースコードを変更する意図があることが、SCCプロバイダに通知されます。通知により、他の開発者は、ファイルが更新されたタイミングを簡単に知ることができ、リポジトリから最新バージョンをすぐに取得できるようになりました。

SCCインタフェースの動作と制限は、管理者が自由に設定できます。 たとえば、管理者は、開発者が変更したい意図を示した場合にコードをロックするように設定できます。 また、複数の開発者が同時にコードをチェックアウトできるようにも設定できます。複数の開発者が加えた変更を1つのコードに結合する必要が生じた場合には、SCCを使用してファイルの2つのコピーがリポジトリに存在してもよいように設定することで、結合を行うことができます。 また、VIでこのようなタイプの競合を解決するには、自動結合ツールを使用できます。

LabVIEWプロフェッショナル開発システムはMicrosoft SCC対応の環境であるため、標準のAPIを介してほとんどのソースコード管理ツールと統合できます。

LabVIEWで使用されている多くの他社製ソースコード管理プロバイダの中で、PerforceとSubversionが広く普及しています。

Perforceも、Microsoft API対応なのでLabVIEW内に統合できます。それには、LabVIEW Professionalバージョンに搭載されているカスタムコマンドラインプロバイダを使用します。 LabVIEW内にPerforceを統合することで、標準APIよりも多くの高度な機能を使用できるようになるため、メリットがいくつもあります。 

Subversionは人気のあるオープンソースソリューションの1つですが、Microsoft SCCの標準APIには対応していません。 しかし、Subversionは、いくつかの基本構成が必要なグラフィカルディファレンシング（相違点認識）ユーティリティおよびグラフィカルマージユーティリティを実行するために、Tortoiseクライアントを介してLabVIEW環境内に呼び出しを行うよう設定することができます。また、この統合用に販売されている他社製品も次のようにいろいろあります。

• TortoiseSVN Tool for LabVIEW from JKI Software
• TSVN Toolbar for LabVIEW from Viewpoint Systems

LabVIEWとソースコード管理ツールの統合には、基本的に2つのアプローチがあります。つまり、LabVIEWを使用して環境内からSCCの機能を呼び出すか、ディファレンシングやマージなどの操作を実行するためにSCCツールでLabVIEW内に呼び出しを行うかのいずれかです。 

Microsoft SCC APIを呼び出すようにLabVIEWを構成する

選定したソースコード管理プロバイダがMicrosoftのAPIに対応している場合は、プロバイダをインストールした後で、開発者が開発環境内からソースコード管理の機能を使用できるようにLabVIEWを構成することができます。この統合を提供する目標は、開発者がファイルのチェックインとチェックアウトなどの一般的なタスクを実行できるようにすること、および別個のクライアントを起動したりLabVIEW開発環境を終了したりせずにファイルの現在の状態を確認できるようにすることです。 

ソースコード管理プロバイダによっては、独自の機能や高度な機能を実行するためにクライアントの使用が必要になる場合もあります。しかし、開発者はほとんどの時間において、それらの操作をLabVIEW内から実行できる必要があります。

統合を構成するには、Tools → Source Controlの順に選択します。この機能は、LabVIEWプロフェッショナル開発システムのみで選択できます。お使いのコンピュータにインストールされていてLabVIEWでサポートされているソース管理プロバイダならどれでも、自動的にオプションダイアログの値が入力されます。

図2は、LabVIEW内へのソースコード管理の統合を有効化するためのメニューオプションを示す

ソースコード管理を使用することで、ハードドライブに対応するファイルがあるリソースをプロジェクトエクスプローラで管理できます。このようなリソースとしては、VI、ドキュメント、画像、プロジェクトファイルがあります。要件ドキュメントは、開発者がドキュメントの変更を追跡してリビジョン履歴を確認できるように、ソースコード管理に頻繁に保存されます。これは、認定されている開発手法としては特に重要です。その理由は、要件の変更がコードによってカバーされたことを開発者が示す必要がよく出てくるためです。要件管理の最善策の詳細については、こちらをご覧ください。

既存のLabVIEWプロジェクト内にソースコード管理が構成されている場合は、以前に保存されたVIをプロジェクトに追加すると、ソースコード管理にその新しいファイルを追加することを求めるプロンプトが表示されます。このプロンプトは既存のファイルについてのみ表示されます。新しいVIは、保存されるまではディスク上に対応するファイルを持たないため、ソースコード管理には追加できません。開発時にプロジェクトにファイルを追加すると、新しいリンクが作成され、プロジェクトファイルが変更されます。プロジェクトファイルは、慎重に管理する必要があるので、次のセクションでさらに詳しく説明します。

ソースコード管理でプロジェクトファイルを管理する

アプリケーションのプロジェクトファイル、つまり*.lvprojファイルは、ソースコード管理リポジトリに保存することをお勧めします。このファイルには、ファイルの場所からの相対パスを使用した、プロジェクトエクスプローラ内の物理リソースへのリンク、特定のプロジェクトに固有の設定、およびビルド仕様などの仮想項目が含まれています。すべての開発者は、最新の依存項目とリソースをすべて保持するために、*.lvprojファイルの最新バージョンを持つ必要があります。

プロジェクトにおいてファイルを追加したりファイル名を変更したりすると、*.lvprojファイルの内容が変更されるため、このファイルをチェックアウトして、新しいリビジョンをSCCプロバイダに送信する必要があります。ファイル内容の変更は*.lvprojファイルを使用するすべての開発者に影響するため、開発中には変更を行わないでください。どうしても変更を行う必要がある場合は一度に1人のユーザーのみが行い、他のすべての開発者は変更が完了したらすぐにこのファイルの最新リビジョンを入手する必要があります。ただし、そのようにできない場合は、別の方法があります。

理想としては、アプリケーションのフレームワークを開発前に決定しておき、将来のコードと機能のためのプレースホルダを作成しておきます。ただし、フレームワーク、ひいては*.lvprojファイルの内容に影響するような変更を余儀なくされる場合もあります。このような変更はアプリケーション全体のリンクに影響する可能性があるため、安易に行わないでください。お勧めする手法は、このような変更を開発プロセス外で、しかもオフラインで行うことです。つまり、すべてのファイルをデポにチェックインし、チェックアウトできないようにロックすることです。また、該当する新しいコードが要件ドキュメントに記載され、ファイルの追加理由が記述されていることも確認する必要があります。

さらに別の方法として、.lvprojファイルのコピーを独自に作成する開発者も大勢います。 この方法は通常、それぞれ自己完結した別々のセクションにアプリケーションを区切ることができる場合にのみ推奨されます。アプリケーションを別々の構成要素に編成するには、プロジェクトライブラリ (.lvlib) を使用することもできます。

VIのソースコードはバイナリであるため、比較およびマージを行う特別なユーティリティを使用する必要があります。 これらのユーティリティは開発環境内から呼び出すこともできれば、コマンドラインから呼び出すこともできます。これは、ソースコード管理ユーティリティから自動的に呼び出せることを意味します。 

図3は、開発者がファイルの2つのコピー間で行われたすべての変更を確認できるようにするグラフィカルディファレンシング（相違点認識）ツールを示す

環境内で統合がアクティブになっている場合は、プロジェクトエクスプローラの右クリックメニューから'差異を表示'を選択できます。しかし、多くの開発者はこの機能をソースコード管理クライアント内から呼び出すことを選択するかもしれません。

詳細情報

Configuring Source Control for Command-Line Integration with LVCompare.exe

Configuring Source Control for Command-Line Integration with LVMerge.exe

Configure Graphical Diff for use with TortoiseSVN

複数のプロジェクトやアプリケーションの複数のバージョンでコードを再利用する場合は、再利用ライブラリの開発工数と、再利用ライブラリのデプロイ先となるアプリケーションの開発工数を個別に管理する手法を適用すると、メリットが得られます。これらのライブラリを使用先のプロジェクトから分離して、それらを別々に管理および開発できるようにすると便利です。 アプリケーションの複数のバージョンを保持する場合に、これらのライブラリを必要に応じてアップグレードしたりダウングレードしたりできるようにすることも重要となる場合があります。 これは特に、ライブラリへの変更をアプリケーションの複数のコピーにデプロイしなければならない場合に重要となります。

LabVIEWプロジェクトライブラリ

LabVIEWプロジェクトライブラリは、アプリケーションの大きなセクションをカプセル化できます。 プロジェクトライブラリファイル (.lvlib) は、ファイルセットへのリファレンスを含んでいるため、ネームスペースを提供しており、アクセススコープを定義することができます。 ネームスペースは、プロジェクトライブラリの名前でファイルの名前を修飾することで、同じ名前の依存項目を呼び出すときに起きる競合を防止します (たとえば、initialize.viという名前の機能を共有する複数の計測器ドライバについて考えてみてください)。 また、プロジェクトライブラリは、定義されているAPIを強制的に使用させることで、非公開の機能への直接アクセスを防止するのにも使用できます。 プロジェクトライブラリは、1つのパックプロジェクトライブラリ (.lvlibp) に組み立てることができます。.lvlibpは、必要なすべての依存項目を含んだ、バージョン固有の編集不能な形式の単一ファイルです。 

LabVIEWプロジェクトライブラリを使用してコードを共有する

VI Package Manager

VI Package Manager (VIPM) は、LabVIEWに再利用ライブラリを配布、デプロイするのに推奨できるソリューションです。 VI、ツール、プロジェクトライブラリのコレクションを、VIパッケージと呼ばれる単一のファイルに組み立てることができます。組み立てたファイルは、VI Package Manager環境内からインストール、アンインストール、バージョン管理することができます。このパッケージの消費者は、どのライブラリバージョンがインストールされていて、インストール済みのLabVIEWで利用可能かを簡単に確認できます。また、VIPM (VI Package Manager) がパッケージの互換性を識別し、必要なすべての依存項目がシステムにインストールされていて利用可能かどうかも識別できるため、インストール手順が効率化されます。 

図4は、VIPMパッケージがAPIの依存項目をカプセル化しているため、パレットやツールメニューの項目を簡単にインストールできることを示す

高度な構成管理機能用には、VIPMのProfessionalバージョンとEnterpriseバージョンが販売されています。VIPM Professionalは、LabVIEWプロジェクトファイルをスキャンすることで、現在使用されている再利用ライブラリを特定し、その情報を構成ファイルに保存して、この構成を簡単に再現できるようにします。 Enterpriseバージョンは、大規模な社内ネットワークでパッケージを配布、交換するための、非公開の社内リポジトリを作成、管理するのに使用できます。

VI Package Managerの概要

能力成熟度モデルは、CMMまたはCMMIとも呼ばれ、ソフトウェア開発と構成管理のベストプラクティスを定めています。CMMは、開発手法の継続的な改善と反復に関するフレームワークを定義しており、この手順の成熟度を5段階で評価、識別します。CMMIは主に、開発手法の厳密性を識別するためのメトリックとして、またプロジェクトの開発合計時間と欠陥数を押し下げるために、大規模組織内で使用されます。

1.なぜ組込のソースコード管理がLabVIEWから削除されたのでしょうか。

NIは、開発者が構成管理と変更管理を実施する際に、業界標準のソースコード管理プロバイダを活用できるようにするため、他社のソースコード管理プロバイダとの統合を提供しています。

2.LabVIEWには、他社製ソフトウェアが不要になる組込のソース管理ツールが搭載されていますか。

LabVIEW 8.xには、LabVIEWの旧バージョンとは違って、組込のソース管理ツールは搭載されていません。しかし、SubversionやCVSなど無償のオープンソースオプションを含む数多くの他社製オプションが、LabVIEW 8.xでテスト済みです。

3.LabVIEWのどのバージョンが他社製ソース管理ソフトウェアと統合されていますか。

LabVIEWプロフェッショナル開発システム (PDS) は、他社製ソース管理ソフトウェアを統合する機能を備えています。

4.同じVIの異なるバージョン間の競合を解決できるLabVIEWの「マージ」機能はありますか。

そうですまた、グラフィカルディファレンシング（相違点認識）機能もあります。

5.LinuxまたはMac OSを使用する場合には、どのようなソース管理オプションがありますか。

LinuxまたはMacでLabVIEWを実行する場合は、LabVIEW環境内からソース管理を利用するために、ソース管理プロバイダとしてPerforceを使用する必要があります。ただし、プロバイダ自体を使用してソース管理機能にアクセスすれば、どのソース管理プロバイダもLabVIEWで使用できます。