プロローグ
ソフトウェア開発における構成管理とは何ですか？ なぜ必要なのですか？ この質問に完全かつ明確に答えることができる人はほとんどいないと思います。 ほとんどの場合、彼ら自身が使用するバージョン管理システムを思い出します。 誰かがバグ追跡について言及しています。 誰かが、CMのトップがお気に入りのバージョン管理システムでブランチを成長させていると考えています。 そして、だれかが一般に脇に出て、ITILについて話し始め、会社にインストールされているすべてのソフトウェアのパラメーターをデータベースに書き込む方法について話し始めます。
これを見るのは少し奇妙で、少し面倒です。 実際、私はSCMで合計約5年間、そのうち3年間、モトローラのインテグレーターとして、携帯電話用ソフトウェアの開発プロジェクトの1つで働いていました。 途中で、このトピックに関する多くの資料を読んで、IBM Rational ClearCaseの最も強力なバージョン管理システムの1つを使用するなど、素晴らしい実践的な経験を得ました（プロファイルのlinkinを参照）。 その結果、それが実際に何であるかという特定の不可欠な画像-ソフトウェア構成管理が私の頭の中で形成されました。
そして、私は同志からの記事を見ました。彼はSMについて話し始めました。 彼のスピーチは、特定のツールとネーミング構成について、わずかに異なる流れで行われました。 したがって、私たちの記事のトピックと重複しないように彼と一緒に書き留めて、私はソフトウェア構成管理と呼ばれるものの基本について書くことにしました。
今、私はすでに約5万文字の素材を書いています-これらはHabrの約5-7の平均投稿です。 そして、書き込みプロセスは継続します。 私はここに少しの頻度で書いたものを投稿し、質問や議論が尽きたので、新しいメモを投稿します。
タスクは、一般的なCMの概要、CMが解決するタスク、および使用されるテクニックを提供することです。 特定のバージョン管理システムやツール全般については説明しません。これはネットワーク上で大量に行われます。 タスクは、すべてのツールに共通する基本を示すことです。
行きましょう。
CMとは何か、なぜ必要なのか
構成管理
最初に、この単語がヘッダーに表示されるため、 構成が何であるかを判断しましょう。 構成は、作業成果物のバージョンのコレクションです。 キーワードは「製品バージョン」です。
どのプロジェクトにも作業成果物があります。これには、マーケティング文書、最終製品の要件、ソースコード、テスト、補助ツールなどがあります。 作業成果物と見なされるものはプロジェクトによって異なります（定義は次の注で説明します）。 さらに、各製品は時間の経過とともに変化し（これは開発の意味です）、これらの変化を何らかの形で考慮する必要があります-誰が、いつ、何を正確に、そしてなぜ彼がそれをしたのか。 つまり、製品のバージョンがどのように表示されるかを検討してください。
バージョンとは、変更履歴に関係なく、いつでも復元できる作業成果物の状態です。
したがって、 構成管理は作業成果物スイートとそのバージョンの管理です。 このプロセスはCMの範囲です。
英文学では、 SCMと略されるSoftware Configuration Managementという用語を使用しています 。 さらに、表示を簡単にするために、構成管理という用語と略語CMを使用します（「siem」と読みます）。
スキーム1.要素、それらのバージョン、およびセクション構成。
CMは、ソフトウェア開発方法論の基本プラクティスの1つです。 SEI CMM / CMMI（Capability Maturity Model Integration）では、確立された構成管理プロセスの存在は、組織がCMM / CMMIレベル2証明書を取得するための必要条件であると言えば十分です。
CMMモデルによると、レベル2は最も最小の初期の成熟レベルであることに注意してください。 レベル1は、少なくとも1つの開発プロジェクトを正常に完了した「自動」組織を受け取ります。 したがって、CMの存在は認証の最小要件です。 ところで、第2レベルでは、特に、要件をテストおよび管理するための確立されたプロセスが必要です。 これは、CMMI標準の観点から、適切な構成管理が有能なテストおよび要件管理と同様に重要であることを示唆しています。
それでは、CMの価値は何ですか？
責任CM
構成管理は、プロジェクトのライフサイクルのすべての段階で機能します。 動作中の製品（たとえば、ソースコードを含むファイル）が表示されました-CMの活動の分野に該当します。 製品の変更が始まりました（機能を作成中です）。つまり、CMは変更を制御し、必要に応じて制御自体を自動的に実行する手段を提供する必要があることを意味します。 作業を開発チームまたはさらにいくつかに分割する必要がありました-プロジェクトCMは作業用のルールとツールを提供します。 顧客に提供するものがあります-CMは開発製品とそのリリースを安定させるためのルールを決定します。 任意のリリースにロールバックする必要があります-これもCMの作業です。 変更や文書化されたポリシーの指標が必要でした-誰に頼るべきかを理解しています。
だから、まず第一に、CMは作業成果物の識別に責任があります。 さらに制御されるものを決定する責任があります。 次の記事では、これについて詳しく説明します。
製品が強調表示され、チームは作業を開始します。 作業の過程で、得られた結果を定期的に安定させ、開発の下で特定の線を引き、開発のベースとなる基盤を決定する必要があります。 これはすべてCM'aの範囲にも含まれています。
さらに、CMは一般に変更要求の追跡と呼ばれるものを担当します。 この領域のほとんどは、バグ追跡システムとして知られています。 結局のところ、変更は自発的に行われるべきではありません-それぞれが登録され、適切な方法で割り当てられ、監視される必要があります-最終製品に入るまでです。 ここでも極端なCMのままです。 製品に変更を加え、それらを追跡する必要があります-バージョン管理が機能し始めます。 何も失われることはありません-CMは警戒しています。
変更管理およびバージョン管理ツールは、大規模なチームで開発を並列化するための条件を作成します。 これは、これらのツールを説明した後、開発者に責任を共有し、各開発者の活動領域を制限できる手順を文書化したためです。
さて、そして、いつものように、「測定できないものを制御することはできません」-（c）De Marco。 メトリック-それらについてもいくつかの言葉が言われます。 測定値がある場合、形式化があります。 言い換えれば、CMに関連するすべてのものを文書化するとよいでしょう。 これについても簡単に説明します。
それでは、構成管理のタスクは何ですか？
これは：
- 作業成果物の識別。
- 作業結果の安定化とさらなる作業の基礎の決定。
- 変更要求の追跡。
- バージョン管理;
- 開発の並行性を確保する。
- メトリックの収集と適用されたメソッドの形式化。
もう少し理論を読み、責任範囲の用語と正式な説明に興味がある人は誰でも、CMM / CMMIの標準（最後のリンクを参照）を参照する必要があります。 確かに、それは常に明確であるとは限らず、ほとんど常に乾燥して退屈です。
開始するには十分です。 次のパートでは、管理する製品と構成の定義方法に焦点を当てます。 また、コンポーネント開発、製品ライン、SMとの関係についても触れます。
視野を広げるためのリンク：
- en.wikipedia.org/wiki/Software_configuration_management Wikipediaのソフトウェア構成管理。
- www2.computer.org/portal/web/swebokソフトウェアエンジニアリングの知識の本。
- www.sei.cmu.edu/cmmi SEI CMMI Webサイト。
- www.cmcrossroads.com CMは、構成管理コミュニティを横断します。
継続する。
UPD ：労働者のリクエストにより、第2部へのリンク： habrahabr.ru/blogs/pm/67839