※ 左右のカーソルキーでもページ繰りができます(但しブラウザ依存)
情報発信系活動:
コミュニティ系活動
本資料では、以下の点について、ざっくり触れたいと思います。
正式には、 「ソフトウェア構成管理」 (Software Configuration Management: SCM) と言います。
「ラショナル統一プロセス」 (Rational Unified Process: RUP) では、 「構成および変更管理」 (Configuration and Change Management: CCM) などとも呼ばれます。
では「構成」とはなんでしょう?
大雑把に言うならば:
「構成管理」=「変更履歴管理」+「品質管理」
『パターンによる構成管理』で言うところの「品質管理」は、 継続的インテグレーション (Continuous Integration: CI) が主眼。
ラショナル統一プロセスで言うところの「品質管理」は、 障害 (bug) /要求 (issue) 追跡が主眼。
一般的には、以下のように考えておいて問題はありません。
「構成管理」≒「変更履歴管理」
以降の記述では、 「構成管理」の「変更履歴管理」面に焦点を絞って進めます。
SCM ツールは、以下の情報を記録します。
良くある誤解 (1):
自分一人の作業だから、構成管理なんて必要無い
寧ろ、誰もフォローしてくれないからこそ、構成管理が必要
バックアップとしての履歴記録
rm *~
rm *
履歴情報の利用
「実績」記録によるライフログ
複数人での共同作業の場合、 『同じファイルの同じ場所を、異なる内容で修正』してしまうような、 作業における「衝突」 (conflict) の危険が常に存在します。
SCM ツールは、 記録された履歴情報を元に、 作業における衝突を検出し、 両者の成果を統合する手助けをします。
よくある誤解 (2):
SCM ツールがなくても、同等の事は出来るでしょ?
それは、「ナイターシーズン真っ盛りの 19:00 以降の番組」 を EPG 無しで予約録画するのに等しい無謀さです。
あるいは、「C 言語を習得するのが面倒」だからといって、 アセンブラでウェブサービスを実装するぐらいのコスト意識の無さです。
「やってやれなくはない」かもしれませんが、 そこにコストを掛けるのは、単なる労力の無駄使いです (※ ミスの可能性も跳ね上がります)。
第1世代 (SCCS/RCS)
+ 作業領域ルート +-- foo.c ※ 管理対象ファイル +-- RCS ※ 履歴データ格納場所 | +-- foo.c,v ※ foo.c の履歴データ +-- subdir +-- bar.c +-- RCS +-- bar.c
第2世代 (CVS/SVN/VSS)
+ 「モジュールA」の作業領域ルート +-- foo.c ※ 管理対象ファイル +-- CVS | +-- Entries, Root .... ※ 最小限の管理情報 +-- subdir +-- bar.c +-- CVS +-- .... + 「リポジトリ」ルート ※ 履歴データ格納場所 +-- 「モジュールA」のルート +-- foo.c,v ※ foo.c の履歴データ +-- subdir +-- bar.c,v
第3世代 (Bazaar/Git/Mercurial)
+ 作業領域 (=広義の「リポジトリ」) ルート +-- foo.c ※ 管理対象ファイル +-- subdir | +-- bar.c | +-- .hg ※ 管理データ領域 (=狭義の「リポジトリ」) +-- store +-- .....
重要な事なので第3世代 SCM ツールの特徴をもう一度:
「リポジトリ」+「作業領域」は各自で複製を保持
作業を実施する主体ごとにリポジトリが分散 ⇒ 分散リポジトリ型 SCM ツール
第2世代 SCM ツールに関して、時々見かける表現:
「Client/Server モデル」、 つまり分散コンピューティングモデルであるから、 「分散 SCM ツール」である
基本的には、 「分散リポジトリ型」以外の SCM ツールを 「分散 SCM ツール」とは呼んでほしく無いのですが...
分散リポジトリ型 SCM ツールでの履歴の記録
良くある誤解 (3):
分散リポジトリ型は、 常にリポジトリ同士が連携するに違いない!
ユーザが明示的に指示しない限り、 他のリポジトリとの連携は発生しません。
良くある誤解 (4):
各リポジトリは「完全な履歴情報を持っている」らしいので、 常に最新の情報を得られるんでしょ?
多くの英文で "complete history" などと記述されていますが、 perfect とか whole のような「全ての」的なニュアンスではなく、 「それ単独で機能し得る」というニュアンスの、 「完結した履歴情報を持っている」 と考えてください。
「最小限の管理情報」しか持たない第2世代 SCM ツールの「作業領域」は、 「リポジトリ」と分離されてしまうと、 単独では殆ど機能しません。
良くある批判 (1):
他のリポジトリとの相互連携を、 明示的に指定するのは面倒だ!
「明示的な操作」を、 「余計な一手間」と見るか、 「連携契機の柔軟性」と見るかの視点の差。
「連携契機の柔軟性」によって、 「オフライン環境での利便性」や、 「システム構成の自由度」が得られます。
良くある批判 (2):
リポジトリの複製は、 同一内容のファイルが散在することになるので、 ディスク消費量が増えてしまう!
21世紀のバイトあたり記録単価の話をしようじゃないか!
Mercurial では、同一ファイルシステム上での複製時は、 ハードリンク使用によりディスク消費を抑止する仕組みも。
イマドキのファイルシステム/ストレージサーバであれば、 重複排除 (dedup) 機能も利用可能です。
分散リポジトリ型 SCM ツールでの履歴記録に関して、もう一度:
個別のリポジトリで「平行」して記録された作業履歴は、 最終的に一本に統合する必要が有ります。
良くある批判 (3):
平行作業の履歴統合作業が面倒臭い!
「統合作業」の必要性を、 「余計な一手間」と見るか、 「平行開発に必要なコスト」と見るかの視点の差。
多くの場合、 お決まりのコマンドを幾つか実行すれば、 統合作業は自動的に完了します。
自動的に完了しないケースは、 第2世代のツールでも同じように厄介な作業が必要な場合です。
良くある批判 (4):
平行作業の履歴統合のために、余計な履歴が増えてしまう!
第2世代のツールにおける平行作業成果の統合は、 実は結構危険な代物です。
履歴記録で安全が買えるなら、 安いものだと思いませんか?
良くある批判 (5):
余計な履歴が増えてしまうと、 ログが汚れてしまう!
個人的な経験を言えば、 作業履歴が 100 とかを超えると、 履歴のログは、 「全部見るもの」ではなく、 「条件指定で抽出してから見るもの」になりますから、 「汚れ」なんて気になりません。
条件例: 日付、作業者、変更対象ファイル、変更内容に含まれる内容、 履歴記録時のコメント、などなど
良くある批判 (6):
余計な履歴が増えてしまうと、 ディスク消費量が増えてしまう!
だから、21世紀のバイトあたり記録単価の話をしようと何度も○×※☆?!
第2世代 SCM ツールにおける「リポジトリ」と「作業領域」の間では、 「作業領域」契機での「要求発行」による「履歴データ転送」しかできません。
リポジトリ側契機での、 「作業領域」への「履歴データ」転送はできません。
第3世代 SCM ツールにおける「分散リポジトリ」間では、 任意の「リポジトリ」が契機となって、 「履歴データ」を転送することが可能です。
履歴データの転送契機となる「要求」には、2種類あります。
リポジトリ連携が対称性を持つことで、 セキュリティ/ネットワーク的な面での制約に対して、 柔軟に対応することが可能になります (詳細は後述)。
『第2世代的な使用』ユースケース
『第2世代的な使用』運用概要
『オフラインサテライトでの作業』ユースケース
『オフラインサテライトでの作業』運用概要
『多拠点での平行開発』ユースケース
『多拠点での平行開発』運用概要
『特定作業の物理的な隔離』ユースケース
『特定作業の物理的な隔離』運用概要
『リモートからの pull 禁止』ユースケース (1)
『リモートからの pull 禁止』ユースケース (2)
『リモートからの pull 禁止』運用概要
『品質監視ゲートウェイ』ユースケース
『品質監視ゲートウェイ』運用概要
『コミット前レビュー』ユースケース
『コミット前レビュー』運用概要
『配置 (deploy) システムとしての利用』ユースケース
『配置 (deploy) システムとしての利用』運用概要
第3世代の SCM ツールで、みんな幸せ
ありがとうございました