ほとんどの会社は、資産を管理することに打ち込む、大きなシステムやスタッフをもつ
それらは会社の価値ある物理的な資産のすべてを保持する
会社の価値ある物理的な資産ーコンピュータ、車、建物、オフィスでの成果物、など
ソフトウェアプロジェクトでは、あなたはいくつかのシンプルなタスクをもつ
シンプルなタスク：あなたが保持する必要があるすべてのものは、ファイルである
しかし、あなたはすべてのバージョンのビルドに用いる、すべてのファイルを保持する必要がある、プロジェクトが前進するはじめからの
この恐ろしいタスクのために、あなたはソース・コード・マネジメント（SCM）システムを必要とする
これはまた、バージョン・コントロール（VC）システムとも呼ばれる
これらのシステムは有能な司書として動作し、保管場所（またはデータベース）にあるあなたの資産（ファイル）を保持したり、あなたのファイルへの安全なアクセスをコーディネートしたりする
これらシステムはあなたのソースコードの貯蔵はもちろん行う、しかも、他のすべてのサポートファイルも保管する。
すべてのサポートファイル：全員がリリースする、グラフィック、ビルドスクリプト、XMLドロッピング、ドキュメンテーション、小さな（しかし重要な）パールスクリプト
きちんとセットアップしたSCMシステムと、あなたができること
- あなたのチームにプロジェクト全体にわたるアンドゥボタンを与える
：ファイナルはない。間違いは簡単にロールバックされる。
- ひとりより多くの人が与えられたファイルを同時に編集する（または編集したい）ときは、そのぶつかり合いに対処する
- 複数のバージョンのあなたのソフトウェアに跡をつける
：他の人が古いリリースのバグを修正している間に、あなたは次のリリースへの特徴を追加することができる
- どのファイルが（いつ、誰によって）変更されたのか記録しなさい。
- 歴史的ピークを取り出す
：あなたは任意の与えられた日にちからあなたの仕事をとりだせる
もし、あなたの開発ショップの全体が炎に焼かれても、あなたはあなたの保管場所のバックアップから、ただリカバリーすることができるはずだ
あなたはあなたが製品全体でビルドに必要なすべてのものを持つはずだ
：もしあなたがしないなら、そのときひょっとすると、あなたはそのツールをきちんと使っていない
Tip 3
あなたがそれを必要とするなら、それをチェックインしなさい
Javaランタイム（Sunが作った無償利用可能なもの）または、他の特定の製品のような、サードパーティのアイテムを免除する（保存しない）人がいる
彼らは、それらのアイテムを彼らのSCMシステムに貯蔵しない
それはおそらくよいことだろう、もしあなたの製品が複数のバージョンのサードパーティ製品で動作することができるなら。
しかしながら、もしあなたが特定のバージョンの製品に依存するなら、あなたは他の会社がその製品バージョンをあなたのために、提供やサポートを続けることに賭けていることに気づけ
「あなたの製品のビルドにあなたが必要なすべてをSCMに保持しなさい。」という警告への唯一の例外は、あなたが生み出すことのできるファイルである
もしあなたが１５０のライブラリ（JARやDLLファイルで出力された）のセットを持っているなら、それはそれらのライブラリをあなたのSCMに書きだすのは愚かだろう
あなたはそれらをリビルドできる、もし必要なら。なぜならあなたはあなたのSCMにオリジナルのコードを持っているからである
しかしながら、もしあなたの１５０のライブラリがすべて他社からのもの、あるいはあなたがあなたの製品をそれらなしでビルドできないなら、それらをあなたのSCMに含めなさい
他の考えるポイントは製品（それと会社全体の、問題のために）がしばしばなくなることである
もしあなたのベンダーがビジネスをやめるまたは、あなたのオープンソースツールのサポートをやめることを決めるなら、あなたは生き残れるか？
あなたのあなたの製品をまだ発売できるか、もし主要なベンダーがビジネスをやめるあるいは、もしオープンソースプロジェクトがなくなったなら
オープンソースでも商業用でも、製品はしばしば予期せずなくなるものである
必ずあなたのビルド、展開、あなたの製品の動作に必要なものは、あなたのSCMシステムにすべて保持しなさい
もししなかったら、あなたは長い期間のあなたの開発プロジェクトの実行可能性をリスクにおく // ディスク空間に保存するために
それは愚かである、あなたがそれをそのように言うなら。違いますか？
あなたがSCMを使うとき、あなたは特定のバージョンのあなたの製品（または現在のバージョン、問題のために）を得ることができる
あなたは特定の変更をロールバックできる
あなたがこの方法で働いたとき、あなたの開発時間はアクシデントによる浪費をしないでしょう
あなたの仕事は大変価値があって、上書きやぬぐい去ることができない
；それを、あなたにロールバックの変更やあなたのコードの知っている良いバージョンにもどすことを可能にする、ソースコードシステムに書き込め
The Dog Ate my Source Code 犬があなたのソースコードを食べた
あなたはあなたの製品のソースコードがどこにあるか知っているか？
すべてのそれの？
すべてのバージョンの？
本当か？
そして、残りのあなたのチームも同様なのは確かか？
ポイントにおけるケース：私たちが加わった小さなdot-comスタートアップはstate-of-the-artのソースコードコントロールシステム（ああ、ベンチャー投資家の歓びの種）で６つの図式を使ってきた。
しかし彼らはそれをインストールした環境には達していなかった
３つ（そう、たった３つ）のそれぞれは開発者はそ製品コードのはっきり違うバージョンを持っていた、彼らの独特なバグの集まりと共に
それらのどのバージョンもその会社がカスタマーに将来のものとして見せたデモとは一致しない
大きな努力の後に異なるバージョンが調和される、私たちは結局ただ諦めるて、先に進むために１つのバージョンを選んで使うしかない
私たちはSCMをインストールした、このバージョンのコードをこれに入れた、そしてそのときからこれをコツコツと使った。
全員がどのコードが「実際の」製品コードであるか知っていた、そして開発者は平和な心（また製品の品質）は劇的に改善された
How Do I Get Started? どのように私は始めたか
もしあなたがどんなタイプのソースコード・コントロールもあなたのプロジェクトに使っていないのなら、それをあなたの優先順位の一番上にしなさい
これまでの調査によると、４０％ほどのアメリカにあるITショップは、どんなソースコード、バージョンコントロール製品もまったく使っていない、だから私たちは知っている
１．いくつかのSCMシステム（p165の付録Bをごらんなさい）の価値を見極めなさい
私たちは心からCVSまたはSubversionを推奨する（例として、先行しているページの図2.3をごらんなさい）
どちらもフリーかつ世界中の最大級のソフトウェア会社に使われている
もしあなたが商業的ソリューションを選んだのなら、これら製品は彼らの目玉商品との比較のために、あなたにベースラインのシステムを与えるであろう
２．あなたのSCMの使い方を学びなさい
３．１枚のページで、そのシステムへの共通操作のための使い方を教える、クイックスタートガイドを生成しなさい
（留意点などについてp35のリストをチェックしなさい）
４．あなたのチームにそのシステムを見せなさい
そのシステムでみんなが必ず快適を感じるはずだ
５．あなたのコードやサポートファイルをインポートしなさい
６．あなたのすべてのファイルをSCMで保持することを始めなさい
Am I Doing This Right? これを本当にやるのか？
まず、あなたはそのシステムを積極的に使いますか？
もしあなたが週に１度から数日に１度と答えるなら、あなたはシステムを積極的に使っていない
これは目的（あなたの仕事をバックアップする、性格できめ細かな履歴を保持する）の全てを失敗させる
あなたのコードが製品ツリーへの準備が出来ていなくても、それはシステムのプライベートまたは個人用の領域に置かれるとこができる
もしあなたのワークステーションのHDDがまさに今クラッシュしたら、どれほどの仕事をあなたは失う？
それは１、２日より多い、あなたの仕事の仕方を変えることを検討しなさい
また、新しいマシンを開発用にセットアップするのにどのくらいかかる？
あなたの全てのビルドスクリプトや開発リソースのすべてはチェックが済んでいるか？
あなたはSCM操作を素早く行えるか？
コードチェックアウトには２０分、コードのバックアップには他に１５分かかるだろう、あなたはコードチェックインを頻繁にしたくはなくなるだろう
差異のフェッチングのような操作はCPUとHDDを酷使するといえる
多くの会社ではSCMソフトウェアを時代遅れのコンピュータに置くだろう、すべてのインタラクションが辛いものになる
ハードウェアは安い、しかし開発者の時間は高価である
どんなそれ（訓練、ハードウェア、または新たなSCMソフトウェア）でも、必ずあなたのSCMはあなた保つのに十分早いべきである
あなたはSCMの保管場所をバックアップしていますか？
もし建物が今夜炎上して倒壊したら、あなたは他のコンピュータにリストアできるoff-siteのバックアップを持っているか？
素晴らしいSCMはあなたに良くないことをする、もしそのデータが喪失の運命を持っているなら
最低でも、必ずあなたは完全で週１度のoff-siteバックアップを行うべきである
最後に、あなたはあなたのシステムがこれらの操作に十分によい振る舞いを簡単にするか知っているか？
これは操作におけるあなたが知っておくべき最小限のリストである：
- あなたのプロジェクト全体をチェックする
- SCMの最新のコードとあなたの編集との違いを見る
- 特定のファイルの履歴を見るー誰がいつファイルを変更したか
- あなたのローカルのコピーを他の開発者が変更した物にアップデートする
- あなたの変更をSCMにプッシュ（あるいはコミット）する
- あなたがSCMに最後にプッシュした変更を削除（またはバックアウト）する
- 先週の火曜日のコードツリーのコピーを復元する
Warning Sings 留意点
使われない保存場所は役に立たない保存場所だ
あなたは積極的に毎時間一日を通して、個々の開発者が規則正しくチェックインやチェックアウトを行っているか監視すべきである
もし保存場所にあなたの製品のビルドに必要なファイルのみしか入っていないなら、それは自分の役割を果たしていない
「実験的な」リリースあるいはテストツリーは保存場所、クリティカルXMLファイルあるいは、データベースにストアされないことに、用心しなさい
ファイルのチェックインやチェックアウトに長い時間がかかるなら、人々は結局それを使わなくなるでしょうーもし今は使っていたとしても
いくつかのバージョンコントロールシステム（信頼ある大きな会社、名もない会社によって作られた）は通常の基礎のものでは、ファイルを「食べる」と知られている
無償で使うことができるCVSまたはSubversionのような、本物のシステムにアップグレードしなさい
最終更新：2011年07月01日 14:49
