Clever Geek Handbook

構成管理（パート1、入門）

優れたソフトウェアを開発する方法は？ 大規模で複雑なソフトウェア製品を開発する必要性が、特定の時点で存在するテクノロジーのレベルに常に依存していたことは、秘密ではありません。 しかし、既存の開発アプローチを調査および分析しても、高品質プログラムの「正しい」開発に関する最も単純な質問に答えることはできませんでした。 私が自分に提起した最も簡単な質問の1つは、リリースされたソフトウェア製品にバージョン番号を割り当てる方法の質問でした。 確かに多くは、これが大企業のアプリケーションだけでなく、初心者のプログラマ、学童、学生のペンを超える最も単純なアプリケーションにも適用されることに同意するでしょう。 バージョンを割り当てる意味は、プログラムが実験をやめ、有用なことを始めたときに生じます。 しかし、実験的なバージョンのプログラムでさえ、一意の識別子を割り当てることは理にかなっています。 バージョン番号の変更は、一貫した開発アプローチを反映しており、一方では開発中のプログラムによって提起された要件を表し、他方では、共通の基本機能またはソースコードベースの形式で以前のバージョンに関連しています。 大規模なソフトウェアを開発する方法についてはもう質問しませんが、プログラムにバージョンを割り当てる方法を想像してみてください。 はい、しかしこれらの問題の関係は何ですか？ 実際に非常に大きい。



ソフトウェアプロジェクトの開発を開始する前に、かなりの数の質問を解決する必要があります。資金調達先、プロジェクトに携わる人の数、設定する時間枠、リスク、その他多数。 しかし、これは管理職からのものです。 プログラマーの立場から、他の種類の質問が解決されます。アーキテクチャ、データベースの設計、UMLダイアグラムの描画などです。 しかし、理論的には1日を5分間で飛ぶことです。 上記のすべてのステップをプロジェクトの開発の段階「0」と見なすと、実際にはソフトウェアプロジェクトは開発の段階番号「1」から始まります。 これは完全に正しいとは限りませんが、開発が始まる前に提起された質問の1つを高い確率で答えることが不可能な場合、何をすべきでしょうか？ 何らかの形でそのような答えがあったとしても、ソフトウェア製品は進化的な変化を受けます-要件は変化する傾向があります。 したがって、どのソフトウェアプロジェクトも、結果として製品のバージョンが異なる困難な形式化された影響を受けやすく、これから逃れることはできません。



柔軟な方法論（アジャイル方法論）は、組織的な手段によってそのような問題を解決しようとすることで知られており、これは非常に成功していると言わざるを得ません。 しかし、これは組織レベルです。 プログラマーレベルには、わずかに異なるタスクと問題が含まれます。 それらがまったく解決されていないということはできませんが、私の意見では、そのような解決策の欠点は、それらがすべて異なって解決されることです。 同じ人でも、異なるプロジェクトの場合でも、同じタスクは異なる方法で解決されます。 私の意味を理解し、プログラマーの観点からアジャイル開発へのアプローチの本質を強調するために、通常使用されるアプローチをリストします。

  1. バージョン管理
  2. 自動ビルド
  3. 単体テスト
  4. 静的コード分析
  5. ソースベースのドキュメント生成（javaDoc、phpDoc、Doxygenなど）
  6. 継続的インテグレーション
通常、何らかのバージョン管理システムを使用しないと開発は完了しません。 他のすべてのアプローチは、個々のプロジェクトに適用される場合とされない場合があります。 すでに開発中のシステムの詳細、他の多くの要因に依存していますが、その主なものは、すべてのアプローチを管理する能力、必要なスキルとリソースの可用性、開発中のシステムの品質を確保する必要性です。



判明したように、ソフトウェアエンジニアリングには、方法論に縛られることなくこの種の組織的なタスクを扱う別の分野があります。これは構成管理です。 構成管理は、ソフトウェアプロジェクトの作業材料の管理と制御方法、それに加えられた変更、および個々のタスクとプロジェクト全体のステータスに関する情報を決定する際の主な分野です。 プロジェクトの成功の大部分は、構成管理プロセスがどれだけうまく確立されているかによって決まります。これは、構成管理がうまく機能しない場合、プロジェクトを保存し、埋めることができます。



IEEE 610用語集では、構成管理について、技術的および管理的な指示（指示）と制御（監視）を適用するための規律として説明しています。構成要素の機能的および物理的特性の識別と文書化。 これらの特性の変更を制御（管理）します。 変更の処理とその実装状況に関する記録（保存）と報告 高度な要件への準拠のチェック（検証）。



しかし、これは非常に正式な定義です。 これが何を意味するのかを理解するために、プログラマが毎日の義務で対処しなければならないソフトウェア製品とツールをリストします。

たまたまこの問題に夢中になったので、構成管理の方法と手段を研究する卒業証書全体を書きました。 また、構成管理に使用されるすべてのツール（より正確には、それらのサブセット）を1つのプラットフォームに結合できる方法を開発することも判明しました。 コミュニティが興味深いと思われる場合は、一連の記事を執筆し、形式化されたバージョン管理方法に到達した経緯を説明し、その本質を少なくとも部分的に伝えようと考えています。 これは次の2つの理由で役立つと思います。

  1. 言及したツールとツールについて少しお話します。つまり、構成管理のコンテキストで言う「空撮」については、開発ツールの一般的なモザイクにおけるそれらの場所の説明をしようと思います。
  2. 最後に、ソフトウェアリリースにバージョン番号を割り当てる際にどの原則に従うべきかを示します。この問題を現在よりも透明にしようと思います（多くの人が疑っています）。
以降の記事への関心を喚起するために、この方法の本質について少しお話しします。 構成管理は主にソースコードリポジトリの保守に基づいているため、すべての構成管理ツールの作業を調整するために、リポジトリを保守するためのルールを形式化する必要があると考えるのは理にかなっています。 これは、構成管理プラットフォームの任意の構成要素（アセンブリツール、継続的統合ツール、そしてもちろん人々）で採用された契約を使用できるように行う必要があります。 したがって、リポジトリは構造化され（各リポジトリディレクトリは、このディレクトリにある特定のコンテンツクラスに対応します）、ディレクトリの命名パターンが定義されます。 ディレクトリテンプレートの1つは、x.x.xという形式のテンプレートです。xは数字です。 より正確には、パターンは\d+\.(\d+|x)\.(\d+|x)(_.*)?



という形式の正規表現で記述されてい\d+\.(\d+|x)\.(\d+|x)(_.*)?



。 このようなテンプレートは、誰もが慣れている最も一般的なアセンブリとリリースの命名システムに対応しています（例：1.0.2、2.3.5、3.10.23）。 私の方法で命名にこのアプローチを使用することの違いは、特定の時点からの命名システムの各数字の変更の依存関係が正式に記述されていることです。



続く



参照：

  1. svnbook.red - bean.com -Subversionについて
  2. martinfowler.com/articles/continuousIntegration.html-継続的統合とは
  3. www.swebok.org-ソフトウェアエンジニアリング知識体系のガイド。 ソフトウェアエンジニアリングに関する本。その章の1つは、構成管理に特化しています。 無料でダウンロードできます。
  4. www.cmcrossroads.comは、構成管理に関連する問題の議論に焦点を当てたコミュニティです。


More articles:


All Articles