Skip to content

MS_ConfigurationManagementTools

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 1 revision

構成管理ツール

概要

主要な構成管理ツールについて説明します。

構成管理一般

汎用的なリポジトリ

成果物の一元管理により開発・保守の効率が良くなる。

業務システム寄りのリポジトリ

データ項目辞書などを使用することで
用語の統一化も図ることが出来る。

ツール

前述の汎用的なリポジトリの範囲。

紹介するツール

  • SVN（Subversion）
  • VSS（Visual SourceSafe）
  • TFS（Team Foundation Server）
  • Git（Global Information Tracker）

異なる点

アクション VSS のコマンド SVN のコマンド
リポジトリのファイルをローカルに取得 最新バージョンの取得 更新
変更ロックの取得 チェックアウト なし（ロックをかけない）
ローカルとリポジトリ間の差分抽出 プロジェクトを選択して「相違点の表示」 リポジトリとの同期化
ローカルの変更をリポジトリに反映 チェックイン コミット

  • ロック動作の違い
    近年主流となっている SVN と TFS は、VSS の既定の排他ロックの動作と異なる。

    • 動作モデル

      • 排他ロックするツールは、排他ロックによりコンフリクトを防止する（ロックモデル）。
      • 排他ロックしないツールは、コンフリクトをマージで対応する（マージ修正モデル）。

    • 動作モデルの変更方法

      • VSS 2005 でも排他ロックを使用しないモードを使用できる。
      • SVN では needs-lock 属性を付与することにより排他ロック動作が可能。

      crossroad's Blog Subversionでファイルのロックを強制する
      http://bagineer.blog59.fc2.com/blog-entry-33.html

移行メモ（誤字）: 移行元の「排他ロックを使用しなモード」を
「排他ロックを使用しないモード」に修正した。

  • ブランチ動作の違い

    • VSS 上でブランチを作成した場合、

      • 共有と言う仕組みを使用し、変更が無い限り同じ母体を共有できる共有モデル。
      • 共有を解除すると、別のファイルとして管理されるようになる。

    • SVN 上でブランチを作成した場合、

      • 差分の仕組みを使用し、変更が無い限り同じ母体を使用する仕様。
      • 変更を開始すると、母体からの差分として管理（差分データのみ保持）。

    • TFS：Git および TFVC（未調査）を使用可能

    • Git：分散型バージョン管理システムであり、結構違うので、比較しません。

補足（「ロックモデル」と「マージ修正モデル」の本質）: この対比は
ツールの違いというより、開発の進め方の違いである。

【ロック モデル（VSS 既定）】★
   ・編集前に「予約」する
   ・利点：コンフリクトが【原理的に起きない】
   ・欠点
       - 【並行作業ができない】
       - ロックしたまま帰宅・退職 → 誰も触れない
       - オフラインで作業できない
   → 現在も有効なのは
     【マージできないファイル】に限られる
       画像、Excel、バイナリの設計書、
       ゲームのアセット など ★

【マージ修正モデル（SVN / Git）】
   ・自由に編集し、後で統合する
   ・利点：並行作業ができる
   ・欠点：コンフリクトの解決が要る
   → テキスト（ソースコード）なら
     【圧倒的にこちらが有利】★

【現在の落としどころ】
   ・Git でも【Git LFS の file locking】で
     特定ファイルだけロックできる ★
     → 「テキストはマージ、バイナリはロック」
       という併用が実務的

SVN（Subversion）

概要

サーバ

  • 集中型（クライアント・サーバ型）
  • ファイル共有だけではなく HTTP（WebDAV）でもアクセスできる。

クライアント

  • TortoiseSVN が使用できる。

    • IDE との連動が無くても十分に使用できる。

  • IDE アドオンとしては以下のものがある。

    • Eclipse：Subversive
    • Visual Studio：AnkhSVN

  • Diff ツールの WinMerge と連動させることができる。

リンク

補足（SVN の現況）: 「近年主流」という当時の位置付けは変わったが、
プロジェクトとしては健在である。

【Apache Subversion】★
   ・Apache Software Foundation で【現在も保守中】
   ・1.14 系が LTS（2020年〜、2033年までサポート表明）
   ・「終わった技術」ではないが、
     新規採用は大きく減った

【クライアントの現況】
   ・【TortoiseSVN】… 現在も更新されている
   ・【AnkhSVN】… 【開発終了】（VS 2019 が最後）★
     → 現在の VS には SVN 連携がない
     → コマンドライン or TortoiseSVN を併用する
   ・【Subversive / Subclipse】（Eclipse）… 低調

【WinMerge】
   ・現在も更新されている（日本発の OSS）
   ・Git の difftool / mergetool としても設定できる ★
       git config --global merge.tool winmerge

VSS（Visual SourceSafe）

概要

サポート

既に旧バージョンとなっており、サポートが切れている。

  • マイクロソフト プロダクト サポート ライフサイクル
    https://learn.microsoft.com/ja-jp/lifecycle/

    • VSS6（延長も含めてサポート切れ）
    • VSS2005（メインストリーム：2012/07/10 に終了、延長：2017/07/11）

  • 単体ライセンス提供終了
    [Information] Visual SourceSafe 単体ライセンス提供終了のお知らせ
    　- Visual Studio サポート チーム blog - Site Home - MSDN Blogs
    http://blogs.msdn.com/b/jpvsblog/archive/2011/12/22/information-visual-sourcesafe.aspx

    2011 年 12 月末日をもって、Visual SourceSafe 2005 （以下、VSS 2005）の
    単体ライセンスの提供を終了（MSDN で入手・使用可能）

問題点

  • ユーザ毎にライセンス料がかかる

  • 機能面

    • オフラインでは基本的にチェックアウトできない。

    • LAN 上でのファイル共有をベースとしていて、
      それ以外の環境（Internet 経由等）では使えない。

    • TFS と比べて機能的に劣る。

リンク

補足（VSS が残っている現場への注意）: 延長サポートも 2017 年 7 月に終了
しており、現在は完全にサポート外である。

【放置した場合のリスク】★
 ① 【リポジトリ破損時に復旧手段がない】
     → 後述の比較表にあるとおり、
       VSS は【トランザクションを持たない】
     → ネットワークの瞬断・クライアントの強制終了で
       DB が壊れることが実際にある ★
 ② 新しい OS / VS で動作保証がない
 ③ 【共有フォルダを見られれば中身が読める】
     → セキュリティ監査で必ず指摘される

【移行の選択肢】
   ・履歴が要る    → vss2git / VSS2Git 等の変換ツール
                     （完全再現は難しい。要検証）★
   ・履歴が要らない → 最新版だけを新規リポジトリに投入し、
                     VSS は【読み取り専用で凍結保存】
     → 実務ではこちらを選ぶことが多い

【まず今日できること】★
   ・VSS の共有フォルダを【バックアップする】
   ・Analyze ユーティリティで整合性を確認する

TFS（Team Foundation Server）

概要

TFS を導入することにより、

  • バージョン管理システムだけでなく、
  • ALM（アプリケーション ライフサイクル管理）ソリューションとしての機能も
    導入＆連携させることができる。
    1. 自動ビルド・システム
    2. 作業項目管理
    3. プロジェクト管理
    4. コミュニケーション基盤

VSSとの比較

バージョン管理システム単体では（VSS と比べ）以下の機能が追加されている。

  • シェルブ
  • チェックイン・ポリシー

連携

費用の違い

VSS単体の場合

  • VSS ライセンス × クライアント台数

TFS 単体の場合

  • CAL × クライアント台数

  • サーバ・ライセンス

    • Windows Server
    • SQL Server、TFS

  • SQL Server に無償の Express を使用した場合

    • データベースサイズが Express Edition では 4GBytes となる。
    • SQL Server 2008R2 から Express Edition でも 10G の容量まで。

MSDN を使っている場合は

  • Pro 以上のエディションで CAL は付属する。
  • サーバライセンスも MSDN の範囲で使用できる。
  • 従って、VSS、TFS にアクセスする人全てが MSDN の Pro 以上のエディションを
    持っている場合、別途ライセンスを購入することなく VSS、TFS を利用できる。

TFS Express

クライアント・ツール

Visual Studio のチーム・エクスプローラからのソースのアクセスが基本になる。

Visual Studio 以外のツールでは、

  • コマンドラインツール (tf コマンド)
  • Eclipse プラグイン(Team Explorer Everywhere)

からのソース管理が可能となっています。
その他の GUI ツールに関しては見つけることができませんでした。

移行メモ（誤字）: 移行元の「Vusial Studio」を
「Visual Studio」に修正した。

補足（TFS の現在：Azure DevOps Server への改称）: 製品名も
位置付けも変わっているため、本節の記述は歴史的資料として読む必要がある。

【改称と現況】★
   2005〜2018  Team Foundation Server（TFS）
   2018        Visual Studio Team Services（VSTS、クラウド版）
               → 【Azure DevOps Services】に改称
   2019        TFS →【Azure DevOps Server】に改称 ★
   現在        Azure DevOps Server 2022 等が提供中

【TFVC の扱い】★
   ・Azure DevOps でも【新規作成が制限】された
   ・新規プロジェクトの既定は Git
   → 「TFVC を選ぶ理由」は
     既存資産の維持以外にほぼない

【Team Explorer Everywhere も終了】
   ・Eclipse プラグインは【開発終了】
   → Eclipse から使うなら Git で繋ぐ

【ライセンス面の変化】★
   ・TFS Express（5 人無償）
     → 【Azure DevOps Services の無償枠】に置き換わった
       （5 ユーザーまで無償、Git は無制限）
   ・Visual Studio サブスクリプションに
     Azure DevOps の権利が付く点は当時と同様

【SQL Server Express の容量制限】
   ・本文の「10G」は現在も同じ（→ [SQL Server Express](MS_SQLServerExpress)）
   ・オンプレの Azure DevOps Server で
     Express を使うと【早晩当たる】★

参考

＠IT

Microsoft

Git（Global Information Tracker）

OSSホスティング・サービス

GitHub

GitLab

GitBucket（MS_GitBucket.md）

補足（「Global Information Tracker」について）: この展開は
公式の正式名称ではない点を補っておく。

【Git という名前の由来】★
   ・Linus Torvalds 本人の説明では
     「git」は英国スラングで【「間抜け」「嫌なやつ」】
     → 「自分にちなんで名付けた」と冗談めかして述べている
   ・man ページには複数の解釈が併記されており、
     その中に
       "Global Information Tracker"
       （機嫌が良いときの解釈）
       "Goddamn Idiotic Truckload of sh*t"
       （壊れたときの解釈）
     が挙げられている ★
   → 【後付けのバクロニム（逆頭字語）】であり、
     正式名称ではない

参考

比較

Team Foundation Server 2010 Visual SourceSafe 2005
アーキテクチャ ● N 階層構造で DB を分離可能。
● リポジトリには SQL Server を使用		 ● 2 階層構造。
● リポジトリに Windows の共有フォルダを使用
遠隔地からのアクセス ● HTTP 経由でのリモートアクセス
● 遠隔地オフィスにバージョン管理用のキャッシュを設置することでネットワーク負荷を軽減
● 専用ツール以外にも Web ブラウザによるアクセス機能をサポート		 専用ツールから HTTP 経由による簡易リモートアクセス
セキュリティ ● 多重防御による完全なセキュリティ構造
● プロジェクトをはじめ、ファイルレベルまでアクセス権の設定が可能		 ● リポジトリにアクセスするための権限設定のみ
● 共有フォルダは Explorer などで読み取り可能
信頼性 SQL Server のストアドプロシージャを採用しており、
操作失敗時にはロールバックなどで既存内容を確実に維持		 ● トランザクション処理が非サポートであるため操作失敗時などにロールバックができない
● チェックイン時に DB 容量の確認を行わないため、稀にリポジトリが破損することがある
スケーラビリティ ● 同時使用ユーザーは 2000 名以上で設計
● DB 容量の制限は特にない (SQL Server Express を選択の場合は、その制限に依存)		 ● 同時使用ユーザーは 20 名程度で設計
● DB 容量の制限は 3 ～ 5 GB

移行メモ（体裁・誤字）: 上表は移行元で PukiWiki のヘッダ行が
空セルから始まる形式（||Team Foundation Server 2010|...|h）だったため、
GitHub の表形式に整えた。
セル内の &br; は <br> に変換している。
また「バージョン管理用のキャッシュが設置する」を
「キャッシュを設置する」に修正した。

補足（この比較表は「販促資料」である点に注意）: 出典が
Microsoft の VSS → TFS 移行キャンペーン ページであることは、
原文にも明記されている。

【読み方】★
   ・VSS 側の記述は【意図的に不利に書かれている】
     → ただし「トランザクション非サポート」
       「共有フォルダが読める」等は
       【事実として正しい】
   ・「同時 2000 名以上」「20 名程度」は設計上の目安であり、
     実測値ではない

【現在の視点で見ると】
   ・この表の TFS 側の優位点は、
     そのまま【Git + ホスティング サービス】でも成り立つ
       - HTTP アクセス、細かい権限、
         トランザクション（Git はオブジェクト単位で不変）
   ・つまりこの表は
     「VSS を捨てる理由」としては今も有効だが、
     【移行先が TFS である理由】にはもうならない ★
   → 移行先は [Git](MS_Git) / [GitHub](MS_GitHub) を検討する
     （→ [SVN vs Git vs TFS](MS_SVNvsGitvsTFS)）

移行

移行メモ（リンク切れ）: 本ページの参考リンクのうち、
msdn.microsoft.com / blogs.msdn.com / support.microsoft.com/kb/ /
microsoft.com/ja-jp/dev/campaign/ は、
Microsoft のサイト再編により到達しないものが多い。
また d.hatena.ne.jp（はてなダイアリー）は 2019 年にサービス終了し、
はてなブログへ移行済みのものと消失したものがある。
記録として残す。

Tags: 移行, .NET開発, ツール類, 構成管理ツール, CI

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally