GitやGit系ホスティングサービスが広まった現在のシステムでは、以下のようなソース管理が一般的です。
しかし、それが広まる前のひと昔前のレガシーシステムでは、以下のようなソース管理が一般的でした。
この記事では、ひと昔前のソース管理の問題点を挙げていきます。
----
ひと昔前のソース管理の問題点は、以下の二つです。
①本番環境に配置される実行ファイルがどのように作られたのか不明である
②最新のソースコードが適切に管理されない可能性がある
以下では、それぞれの問題点について説明します。
①本番環境に配置される実行ファイルがどのように作られたのか不明である
現在のソース管理では、Git系ホスティングサービスの中でコンパイル（ビルド）が行われます。
このコンパイルの作業は、Git系ホスティングサービスの管理者が実施するため、開発者任せになることがなく、どのソースファイルがコンパイルされたのかも明確です。
しかし、ひと昔前のソース管理では、開発者がコンパイルした実行ファイルをそのまま本番環境に持ち込みます。
そのため、コンパイル作業が開発者任せになりますし、どのソースファイルがコンパイルされたのかも不明になります。
（開発者の環境を見に行って推測したり、開発者の申告を信じたりするしかありません）
ひと昔前のソース管理では、この問題により、意図しないソースファイルがコンパイル時に含まれてしまうことによるデグレードが起こりやすくなります。
②最新のソースコードが適切に管理されない可能性がある
現在のソース管理では、本番環境向けにコンパイルを行ったソースファイルをそのまま世代管理します。
そのため、本番環境向けのコンパイルに使用したソースファイルの紛失は起こりにくいです。
しかし、ひと昔前のソース管理では、リポジトリへのソースファイル格納と本番環境への実行ファイル配置は別作業になり、リポジトリへのソースファイル格納を忘れても本番運用には影響がない、という状態が起こり得ます。
このことにより、ソースファイルの世代管理の作業が漏れやすくなり、ソースファイル紛失の原因になります。
（例えば、リポジトリへのソースファイル格納を忘れ、かつ開発環境のリプレースが発生した場合、リプレース前の開発環境にのみ存在していたソースファイルは失われてしまいます）
