EatSmartシステム部ブログ

ウェブサイトの開発や運営に関する情報です。

プライベートmavenリポジトリでのバージョンの扱いについて

弊社では、Webアプリケーションのビルド用に、かなり昔に作ったAntのスクリプトを使用しているところがあるのですが、JARのバージョン管理や、新しい開発者の環境構築の容易さを考えて、(今更ながら)Mavenを使うように試してみました。

プライベートリポジトリ構築

JARのバージョン管理と言っても、外部のJARについては頻繁にバージョンアップをすることは無いのですが、自社プログラムの共通モジュールは日々更新されているので、自社モジュールのバージョン管理が主目的となります。

そのため、自社環境内にmavenのプライベートリポジトリを構築して、依存関係の配布とモジュールのデプロイを行う必要があります。

すでに、社内向けに閉じたapacheがあるので、今回はWebDAVリポジトリを構築しました。 WANからはアクセスできないので、以下の設定にしています。

DavLockDB /var/lib/dav/lockdb

Alias /repository /var/mvn/repository/
<Location /repository/>
    DAV on
    Options +Indexes
    AuthType None
    Require all granted
</Location>

<Directory /var/mvn/repository/>
    Options Indexes FollowSymLinks
    Satisfy Any
    Allow from all
</Directory>

あとは、使う側のpom.xml

<repositories>
    <repository>
        <id>mvn.eatsmart.jp</id>
        <name>eatsmart.jp mvn repository</name>
        <url>http://mvn.eatsmart.jp/repository/</url>
    </repository>
</repositories>

を追加して、自社モジュールの依存関係を使えるようになりました。

WebDAVリポジトリへのデプロイ

モジュールをデプロイする側のプロジェクトでは、まず以下のようにpom.xmlにデプロイ先の定義をします。

<distributionManagement>
    <repository>
        <id>mvn.eatsmart.jp</id>
        <name>eatsmart.jp maven repository</name>
        <url>dav:http://mvn.eatsmart.jp/repository</url>
    </repository>
</distributionManagement>

次に、maven3でWebDAVへデプロイするために、wagonというextensionを使う必要がある(Maven3でWebDavでjarをdeploy:deploy-fileしたら失敗する件)とのことで、以下の定義を追加します。

<build>
    …
    <extensions>
        <extension>
            <groupId>org.apache.maven.wagon</groupId>
            <artifactId>wagon-webdav-jackrabbit</artifactId>
            <version>2.12</version>
        </extension>
    </extensions>
</build>

以上で、maven deployで自社リポジトリへデプロイできるようになりました。

モジュールのバージョン管理について

自社モジュールのバージョン管理と言っても、外部のJARと同様にすぐにバージョンアップに追随しない種類のものもあります。

大まかに分けると

  1. ユーティリティやフレームワークなど、複数のアプリケーション間で共通に使っているモジュール
  2. バイスごとのサイトを実装する際に、アプリケーションの共通のビジネスロジックをモジュール化したもの

1については、外部のJARと同様に、アプリケーションごとにある程度固定のバージョンを使用します。モジュールもバージョンによって機能やインターフェースに微妙な差異があり、それをバージョン管理する必要があります。

2については、デバイスごとで処理内容が異なることはあまり無い(ある場合は共通ロジックとしては使用しない)ので、特にバージョン情報で世代管理をする必要は無く、むしろ常に最新のバージョンに追随する必要があります。

そのため、1のためには通常のmavenの依存性管理を用いて、バージョン番号で世代管理をしようと考えています。バージョン番号としてはこちら(セマンティック バージョニング 2.0.0 | Semantic Versioning)に則り、互換性を保たないバージョンはメジャー番号、互換性を保つバージョンはマイナー番号、バグ修正やパッチ対応はリビジョン番号で表現したいと思います。ただ、社内の共通モジュールでは、そこそこ頻繁に機能追加が行われ、後方互換性とは関係無く新しいインターフェースが追加されるので、その範囲ではリビジョン番号の繰り上げで対応しても良いかなと考えています。

2については、通常のバージョン番号で管理する範囲の更新頻度ではありませんし、そもそも常に最新バージョンに追随する必要があるので、リビジョン 番号だけを延々と繰り上げていく運用か、あえてSNAPSHOTで運用しても良いかなとも考えています。この辺で何か知見があれば良いなあと思っています。