4

UPDATE＃1 9/18

私の会社は、増え続ける開発者に合わせて、開発/リリースサイクルを完全に刷新することを決定しました。

gitプロセスは、いくつかの変更を加えた成功した分岐モデルに似ています。開発者が「開発」ブランチに直接プッシュアクセスする代わりに、開発者はマージ/プルリクエストを行う必要があり、コードレビューと基本的な単体テストが必要になります。

バージョンシステムはMajor.Minor.Patchであり、メジャーバージョンは下位互換性の破れを示し、マイナーバージョンは新機能とマイナーバグ修正を示し、パッチは重要なホットフィックスを示します。この新しいバージョンのシステムは、有用な情報としてJenkinsビルド番号を削除しますが、履歴の目的でデプロイされたアーティファクトに添付します。

「開発」ブランチは、スナップショットを構築してローカルのNexusにデプロイするために、Jenkinsによって追跡されるため、開発者は未リリースですが受け入れられている機能を利用できます。「マスター」ブランチもJenkinsによって追跡され、リリースアーティファクトをビルドおよびデプロイします。

リリースプロセスは次のようになります。

  • リリースされた機能に基づいてPOMバージョンを更新します
  • ブランチに新しいバージョンのGitタグを付ける
  • ユニット、統合、およびシステムテストを実行します。
  • リリースアーティファクトをビルド、難読化、およびNexusにデプロイします
  • 新しい開発SNAPSHOTの「develop」ブランチバージョンを「Major.Minor++-SNAPSHOT」に更新します。

元の投稿

難読化され、Jenkins / Hudsonビルドに基づく動的ビルド番号を使用し、社内のSonatypeNexusにデプロイされているJARライブラリをビルドしようとしています。

私の問題は、Mavenのインストール/デプロイがfinalNameへの変更を尊重せず、次のような式でバージョンを設定することは「悪い習慣」と見なされることです。

    <version>1.0.${buildNumber}</version>

これは悪い習慣ですが、ローカルとリモートの両方で、適切なバージョンのアーティファクトを適切にインストール/デプロイします。ビルド番号は、Jenkinsビルドシステムのビルド番号環境変数の存在にリンクされているプロファイルのペアに基づいており、その変数がない場合はデフォルトで0になります。

    <profile>
        <id>static_build_number</id>
        <activation>
            <property>
                <name>!env.BUILD_NUMBER</name>
            </property>
        </activation>
        <properties>
            <buildNumber>0</buildNumber>
        </properties>
    </profile>
    <profile>
        <id>dynamic_build_number</id>
        <activation>
            <property>
                <name>env.BUILD_NUMBER</name>
            </property>
        </activation>
        <properties>
            <buildNumber>${env.BUILD_NUMBER}</buildNumber>
        </properties>
    </profile>

Nexusにコミットされてプッシュされるバージョンは、テスト済みのリリースバージョンと見なされるため、SNAPSHOTバージョンは使用しません。

Jenkins / Hudsonの動的ビルド番号に基づいてMavenバージョンを設定し、その更新されたバージョンでデプロイできるようにする「適切な」方法はありますか？

4

1 に答える 1

1

Mavenの方法では、コードをリリースしたときにのみバージョンが変更され、同じバージョンの2つの連続したビルドで同じ出力が生成されるはずです。

あなたの場合、あなたはこれらの2つの良い習慣に反対しています。

本当にすべてのコミットが新しいリリースである場合、あなたがしていることはひどく間違っているようには聞こえません（しかし、それは私には面白く聞こえます）。1つの欠点は、VCSからタグを作成しているように見えないことです（これは別の良い習慣です）。

正直に言います。各コミットが本番環境に対応したリリースであるとは信じられません。各コミットが多くの自動テストに合格する必要があり、場合によってはリビジョンが拒否される（機能上またはパフォーマンス上の理由で）継続的デリバリー環境でも、これは見たことがありません。

于 2012-09-17T19:14:53.360 に答える