ソース管理を行う方法としては、今日ではGitベースのプラットフォーム（GitHub、Bitbucket等）を使用するのが主流です。
しかし、ソースコードがCOBOLで書かれているようなレガシーなシステムでは別の方法、極端な話、共有フォルダにソースを格納してライブラリアンが一括管理するような方法が適している場合もあります。
しかし、どのような方法でソースを管理するにしても、確実にアンチパターンと言えるケースがあります。
それは「リポジトリ内のソースが信頼されない」というケースです。
ソース管理が上手く行われていないと、リポジトリ内のソースが開発者から信頼されなくなります。
例えば、以下のようなケースです。
- リポジトリ内のソースが最新化されておらず、本番環境にあるソースが最新であった
- リポジトリ内のソースの改行コードに問題があり、そのままでは使用できない
リポジトリ内のソースが信頼されなくなった場合、開発者に「裏プロセス」を生み出す動機が生まれます。
ここで言う「裏プロセス」とは、リポジトリの管理者・運用担当者を介さない、開発者だけで完結するプロセスのことを指します。
具体的に言えば「開発者自ら本番環境からソースを取りに行くことで、修正元ソースを入手する」「開発者が手元にソースを持ち、そのソースを修正元とする」といったものです。
短期的に見ればこの裏プロセスは上手く行きそうに見えますが、裏プロセスには管理の目が行き届かない、という問題があります。
長期的には見れば、必ずデグレードの危険性が高まります。
特に、同じソースを複数の開発者が開発するようなケースでデグレードが発生しやすくなります。
それどころか、開発者の作業ミスでデグレードが発生することすらあります。
裏プロセスにより開発が行われる状況は、決して放置してはならない状況です。
リポジトリに問題があるのであれば、リポジトリの運用を見直して、その問題を解決する必要があります。
そして、問題を解決した旨を開発者に周知し、リポジトリからソースを取得するように呼びかける必要があります。
また、裏プロセスによる開発を行うことができないように環境やルールを整備することも場合によっては必要です。
例えば、「本番環境のソースを開発者から参照不可にする」という方法は環境整備の方法として検討に値しますし、「開発者に修正元ソースと修正後ソースと修正前後コンペアを提出してもらい、リポジトリ内のソースを元に修正されていることを確認する」という方法も不正なソースを元に開発が行われていないか確認する方法として機能します。
いかがでしたでしょうか。
今回は、経験則を共有するために、ソース管理のアンチパターンを書いてみました。
このようなことが一般的に言われることは少ないと思いますが、仕事をする上ではこのような経験則も重要だと思っています。
コメント