バージョン・コントロール・システム
- バージョン・コントロール・システム(VCS)により、チーム開発のための規範が提供されます。
- ソース・コードに加えられた変更を追跡し、制御します。
- ファイルの全ての変更がいつ、誰によって加えられたかを追跡できます。
- 比較的簡単に1つ前のバージョンに戻すことができるようになっており、欠陥を取り除くことができます。これはファイル・レベルだけでなく、システム全体でも可能です。
- ソースコードのロック、マージ、復元やソース比較、その他様々な管理が行われます。
上の図では、バージョン3 の簡単なファイルにテキスト"Milk Eggs Juice"というテキストが含まれています。開発者はこれをチェックアウトして、作業用コピーを"Milk Eggs Soup"と修正します。この修正がチェックインされると、これはVCSではバージョン4 となります。もしくは、この変更がバージョン3に戻されると、作業用コピーは"Milk Eggs Juice"となります。これは単純な概念ではありますが、非常にパワフルな仕組みです。まず、簡単に元に戻すことができます。また変更はVCSにより管理されるので、加えられた修正はそのままの形で記録され、将来いつでもその修正に戻ることができるようになります。ですから、開発者は修正を自由に試すことができます。
上図のシナリオでは、メイン・ストリームがバージョン4で枝分かれして同時並行の開発(バージョン5)が作成されています。これはメイン・ストリームで引き続きバグ修正が行われ、適用されている間に製品の新機能を追加するためです。開発者はこの枝分かれに直接入って、新機能"Rice"を追加します。これがバージョン6になります。この変更は次に新しいリリースが必要になる時まで保留にされ、メイン・ストリームに戻ってマージされます。
この間に現場から報告されたバグにより、"Bread"が追加され、これがバグ修正として発行されます。こうすることで、顧客は新機能の修正を受け取りません。これはリリース用のプログラムと分離されていたからです。
そして、次のバージョンがリリースされる時期が来ると、新機能がメイン・ストリームに戻されてマージされます。ファイルには"Rice"が追加されて、結果的に"Milk Eggs Soup Bread Rice"となります。この手順はほぼ自動化されています。システムは追加された変更をほぼ正確に加えることができます。ただし、同じ行が修正された場合は競合が報告され、変更をVCSに追加してバージョン8を作成する前に、この競合が解決されないといけません。この競合がこのシナリオでも発生しました。何故ならば4行目がメイン・ストリームでも枝分かれした開発でも修正されたからです。ここでは、メイン・ストリームの修正に新機能の変更が加えられた後、両方の修正が残されなければならないと開発者が判断しました。
次のトピックも参照してください。
『LANSA/AD ユーザーガイド』の「タスクの処理」