Git系ホスティングサービスやCI/CDツールが広まった現在のシステム開発の現場では、以下のようなソース管理が一般的です。
しかし、それが広まる前の昔のシステム開発の現場では、以下のようなソース管理が見られました。
この記事では、昔のソース管理の問題点を挙げていきます。
昔のソース管理によって発生する具体的な問題は、主に以下の二つです。
①商用環境に配置される実行ファイルがどのように作られたのか不明
②最新のソースコードが適切に管理されない可能性がある
以下では、それぞれの問題点について説明します。
①商用環境に配置される実行ファイルがどのように作られたのか不明
現在のソース管理では、Git系ホスティングサービスの中でビルドが行われます。
このビルドの作業は、Git系ホスティングサービスの管理者が実施する、もしくはCI/CDツールの設定に基づき実行されるため、開発者任せになることがなく、どのソースファイルがビルドされたのかも明確です。
しかし、昔のソース管理では、開発者がテストのために開発環境でビルドした実行ファイルがそのまま商用環境に持ち込まれることがしばしばありました。
そのため、ビルド作業が開発者任せになりますし、どのソースファイルがビルドされたのかも不明になります。
（開発者の環境を見に行って推測したり、開発者の申告を信じたりするしかありません）
昔のソース管理では、この問題により、意図しないソースファイルがビルド時に含まれてしまうことによるデグレードが起こりやすくなります。
②最新のソースコードが適切に管理されない可能性がある
現在のソース管理では、商用環境向けにビルドを行ったソースファイルをそのまま世代管理します。
そのため、商用環境向けのビルドに使用したソースファイルの紛失は起こりにくいです。
しかし、昔のソース管理では、リポジトリへのソースファイル格納と商用環境への実行ファイル配置が別作業になることがしばしばありました。
このような運用を行った場合、リポジトリへのソースファイル格納を忘れても本番運用には影響がない、という状態が起こり得ます。
このことにより、ソースファイルの世代管理の作業が漏れやすくなり、ソースファイル紛失の原因になります。
例えば、リポジトリへのソースファイル格納を忘れ、かつ開発環境のリプレースが発生した場合、リプレース前の開発環境にのみ存在していたソースファイルは失われてしまいます。
前回の記事に引き続き、過去の作業手順について触れた記事を書きました。
今回の記事で紹介した昔のソース管理とその問題点は、何れも私が実際に経験したものです。
現在では信じられない話かもしれませんが、私が経験した現場では、デグレードやソースファイル紛失が問題となることがあり、それを防ぐために重厚長大なルールが制定され、開発効率が落ちていました。
現在は、Git系ホスティングサービスやCI/CDツールにより、少ない労力でこういった問題の発生を未然に防げる運用を行えるようになりました。
良い時代になったと思います。