👨🏼‍🎨 🌺 🛀 構成管理（パート2、ツールの概要） 👩🏿‍🤝‍👨🏾 🧙🏿 🕵️

構成管理に関する記事の第2部を書く準備ができるまでに長い時間がかかりました。 10月8日（ Web Architect Workshop Day ）に開催されたPHPCONF 2009カンファレンスでマスタークラス「ソースコードリポジトリの整理方法」と話せるほど幸運だったという事実が、この事実に寄与しました。プレゼンテーションのために、レポートのテキストと同様に、プレゼンテーションが事前に準備されました。イベントの優れた組織にもかかわらず、会議プログラムに含まれるレポートの資料は一般に公開されませんでした。報酬として、プレゼンテーションで使用した資料を公開することにしました。構成管理に特化したこの記事（前の記事の論理的な続き）に加えて、プレゼンテーションスライドが公開されています。

この記事では、構成管理で使用されるツールについて説明します。したがって、まず、開発で使用されるツールがソフトウェアの作成プロセスにどのように影響するかについて焦点を当てたいと思います。

まず、各ツールを使用していくつかの特定のタスクを解決します。
第二に、問題の解決には、一連の要件を満たすためのツールの先行使用が含まれます。これを使用しないと、ツールは効果的ではないか、機能しません。
第三に、多くの場合、使用される多くのツールによって提起される一連の要件が完全に満たされていません。さらに、異なる機器の要件が互いに矛盾する場合があります。これはすべて、そのような補助具の使用の有効性が低下するという事実につながります。

ここで、開発中にプログラマが使用するツールはすべて、ツールとして使用されます。IDE、フレームワーク、バージョン管理システム、または別のテクノロジーです。各開発者は、明示的または暗黙的に、使用するツールを管理する問題に直面しています。ほとんどの場合、この種の問題の解決策は直感的なレベルで発生するか、開発プロセスのほとんどが構築される基本ツールの完全に意識的な選択が使用されます。単一のプラットフォームで使用されるほとんどのツールを組み合わせることのできる人はほとんどいませんが、これは確立された開発プロセスの構築に役立ちます。

構成管理で使用されるアプローチは、このような確立されたプロセスの構築に貢献する可能性があります。これは、ソフトウェアプロジェクトの作業材料の管理および制御方法、それに加えられた変更、および個々のタスクとプロジェクト全体のステータスに関する情報を決定する際の主な規律であるためです。前に述べたように（前の記事で）、それらは構成管理の関心の範囲に入ります（各項目は以下で個別に検討されます）。

バージョン管理
ビルド管理
単体テスト
静的コード分析
ドキュメント生成（phpDoc）
継続的インテグレーション
依存関係管理
データベース統合
バグ追跡（バグ追跡）およびタスク設定制御（問題追跡）

また、以前に言及されていないことから、構成管理自体が行うことにも注目できます。

リリース管理
配送の調整
確立された開発プロセスの編成
ソフトウェアプロジェクトの異なる部分間の相互作用の方法の調整

QMのプロセス（バージョン管理、ビルド管理など）とQMのタスク（リリース管理、消耗品の調整など）を明確に区別する必要があることに注意してください。英国のプロセスの重要な機能を特定するには、そのような各プロセス（および構成管理との関係）を個別に検討する必要があります。

バージョン管理

バージョン管理は、主要な構成管理プロセスです。開発中にバージョン管理を使用する必要がないことは、事実上ゼロです。ほとんどの開発者は、CVS、Subversion、VSSなどのバージョン管理システム（SLE）に精通しています。分散バージョン管理システムも人気を集めています：git、mercurial、bazaar。前述のバージョン管理システムは、開発者間の構成管理に関する概念の形成に大きな影響を与えます。このため、開発者は通常、リポジトリの思慮深い組織について考えません。最も単純で唯一のソリューションは、SLEサブバージョンを提供します。このソリューションは最も頻繁に使用されます：トランク、ブランチおよびタグへの分割。ほとんどのSubversionリポジトリでこのディレクトリ階層を見ることができますが、常に同じように使用されるとは言えません。最良の場合、branchsディレクトリに並行開発ブランチのいくつかのディレクトリを見ることができます。リポジトリの分岐ディレクトリ構造を作成する際の開発者の不安は理解できます。これは多くの場合、分岐間の変更のマージに関連する多くの問題の前兆となります。しかし、複数のバージョンを持つか、異なるプラットフォームで動作するアプリケーションのチーム開発では、合併を避けることはほとんど不可能です。しかし、合併を実行できる状況を規制することで、その数を最小限に抑えることができます。しかし、そのような規制を決定するには、リポジトリの維持に関連する現象を完全に理解する必要があります。

組立管理

もう1つの重要な構成管理プロセスは、アセンブリ管理です。アセンブリ管理は、次に関するアクションの自動化です。

ソースコードのコンパイル
アプリケーションの展開
単体テストを実行する
データベースの初期化

アセンブリ管理ツールは、例外（make、nmake、cmake、rake）がありますが、アセンブリファイルは通常XML構文（Ant、Nant、Maven、MSBuild、Phing）を使用するという事実によって特徴付けられることに注意してください。通常、アセンブリ管理ツールには、次のようなアセンブリプロセスに固有のコマンドがあります。

グループファイル操作
編集
展開
バージョン管理システムとの相互作用

アセンブリ管理ツールのこれらおよびその他のプロパティにより、他の開発ツールと簡単に統合できます。アセンブリ管理ツールは、構成管理で自動化されるほとんどのプロセスへのリンクとして機能します。

単体テスト

単体テストは構成管理のプロセスに完全に帰することはできませんが、構成管理における単体テストの特別な役割を決定する非常に重要なプロパティがあります。したがって、解釈されたプログラミング言語で記述されたソフトウェアプロジェクトでの単体テストの使用により、アセンブリを管理する必要性に加えて、構成管理に対するより徹底的なアプローチの必要性が決まります。まず、リファクタリングが行われるはずの場所で単体テストが表示されます。第二に、単体テストの使用を決定するとき、十分なレベルで維持する必要があるプロジェクトのアーキテクチャーおよび論理的な整合性が通常考慮されます。つまり、ユニットテストを使用するという決定は、開発組織に関連する多くの追加プロセス（およびコスト）の導入を自動的に意味しますが、これはそれほど明白ではありません。

静的コード分析

大規模プロジェクトでアーキテクチャおよび論理の整合性をサポートすることに加えて、開発の初期段階で構文エラーを特定する必要があります。ソースコード内の構文エラーと論理エラーを特定することに加えて、多くの場合、コード規約への準拠を自動的に確認する必要があります。コンパイルされた言語ではほとんどのエラーがコンパイル段階で検出されるため、静的コード分析はインタープリター言語により関連しています。静的分析を実行して、ソースコードメトリックを収集し、それに応じてレポートすることができます。ソースコードの静的分析に使用されるライブラリの例は、表に示されているライブラリです。

プログラミング言語	楽器
Java	PMD Findbugs
C / C ++	Cppcheck 糸くず
C＃	Fxcop スタイルコップ ReSharper
Php	PHP_CodeSniffer Php sat PHP_Depend ピクシー
Python	パイチェッカーパイントパイフレーク
ルビー	ニラロディルーファスフレイフロッグ
プログラミング言語に依存しないツール	ラットヤスカ

ドキュメント生成

ソースコードとjavaDoc、phpDocなどのスタイルのコメントに基づくドキュメントの生成は、ライブラリ、再利用可能なコンポーネント、フレームワークなど、ソースコードを積極的に使用するプロジェクトに最もよく関連します。ドキュメントの生成に最もよく使用されるツールを表に示します。

特定のプログラミング言語向け	Php	phpDocumentor
	Java	ジャボック
	C ++	Cppdoc
	Python	pyDoc
	ルビー	RDoc
	デプリー	DelphiCodeToDoc
	C＃	Ndoc
特定のプログラミング言語を使用することを指向していない	酸素
	ROBODoc
	ツインテキスト

継続的インテグレーション

継続的インテグレーション（CI）は、統合の問題をできるだけ早期に特定して解決するために、頻繁に自動化されたプロジェクトアセンブリを実行するソフトウェア開発プラクティスです。開発者がアプリケーションの各部分で独立して作業する通常のプロジェクト（継続的インテグレーションのプラクティスを使用しない）では、インテグレーション段階が最終です。 CIを説明するウィキペディアの簡潔な記事で正しく指摘されているように、継続的な統合はどのプロジェクトにも適用できません。継続的インテグレーションの実践を実装するには、プロジェクトはいくつかの要件を満たす必要があります。

ソースコードとアセンブリに必要なすべてのものは、ソースコードリポジトリまたは簡単にアクセスできる場所に保存されます。
リポジトリからのコピー操作、プロジェクト全体のアセンブリおよびテストは自動化されており、外部プログラムから簡単に呼び出すことができます。

通常、継続的な統合ツールは、リポジトリ更新イベントが発生したときにビルドをトリガーするように構成されます。ビルドプロセスに展開フェーズが含まれているため、継続的な統合を調整して、テストチームがアプリケーションの作業用コピーとテスト用コピーを保持できるようにすることができます。開発中、そのような継続的統合ツールは、CruiseControl、phpUnderControl、Xinc、CruiseControl.rb、TeamCity、Apache Continuum、Hudson、Parabuild、Atlassian Bambooなどとして使用できます。

データベース統合

構成管理タスクを検討する際に別の場所を占める重要な問題は、データベース統合です。ほとんどの場合、データベースはアプリケーションの不可欠な部分です。アジャイル手法を使用した開発には、プログラムコードの継続的な改善だけでなく、データベースの構造とその機能も含まれます。通常、これは並行して行われます。プログラムコードの変更に伴い、フィールドタイプ、フィールド名、関数、トリガー、データベースインデックスが変更されます。プロジェクトのライフサイクル中のデータベースの進化は、プログラムコードの進化に似ており、構成管理の対象としてデータベースを検討する場合とほぼ同じ機能を備えています。データベースの構成管理とデータベースのバージョン管理は、プログラムコードの構成管理と比較して大きな違いがありますが、これはプロジェクト管理の不可欠な部分であり、データベース統合プロセスに反映されます。 SQLアプリケーションは、多くの場合、アプリケーション内のアプリケーションと見なされ、バージョン管理される別のプロジェクトに割り当てられます。バージョン管理データベースで使用される識別要素には、DML（データベース操作言語）とDDL（データベース定義言語）の2種類があります。 DMLは、データの操作に使用されるSQLのサブセットです。フェッチ、挿入、削除、更新（CRUD操作）。 DDLはSQLのサブセットでもありますが、テーブル、インデックス、トリガー、整合性制約などの作成など、データベースの構造を記述するために使用されます。データベース統合を整理するときは、DMLとDDLの成果物を分離し、それらを個別に管理することをお勧めします。

問題追跡

システム（タスク設定制御システム）を使用する傾向は、そのようなシステムがソフトウェアプロジェクト管理ツールを統合する試みがますます頻繁に行われていることを示しています。多くの場合、これは直接ではなく間接的に発生します-さまざまなプラグインのリリース（バージョン管理システムとの統合、javaDoc、phpDocまたはDoxygenドキュメントの表示など）。ただし、CRM（変更要求管理）に関連する機能の基本セットにも、改善が必要な要素があります。このような要素には、たとえばバージョンの命名があります。ただし、問題追跡システムだけでなく、バージョン管理や刑法の他のプロセスでも特定の規則を使用する必要があるため、標準化されたバージョン名を使用できません。

アジャイル

柔軟な方法論の使用を含むソフトウェア開発へのアプローチには、構成管理の組織に最も大きな影響を与える多くの特徴的な特性があります。これらのプロパティは次のとおりです。

変化する要件
反復性
継続的な配信。

構成管理プロセスを検討する場合、これらのプロパティは、特定のプロセスの個々のコンポーネントまたはステージの1つで取得した結果に表示する必要があると想定されています。

おわりに

この記事では、構成管理の一部であるプロセスについて詳しく説明することなく説明します。各プロセスを保証するために、多くの選択肢から選択できる個別のツールが使用されます。ツール自体の不均一性、およびそれらが解決するタスクの違いにより、最大限の統合と効果を達成することは困難であることが指摘されました。次の記事では、これについて-追加の形式化（ソースコードリポジトリの組織化）を導入して、刑法で使用されるツールをより効率的に使用する方法について説明します。

続く

参照：

構成管理（パート2、ツールの概要）