ソフトウェア開発へのCIアプローチを使用したMavenプロジェクトのリリース管理の問題

記事を読んだ後

「Gitツールを使用したシンプルなリリース管理」

Mavenプロジェクトのリリース管理についての私の考えを共有したかった。



この記事では、問題の解決策を提案するだけでなく、問題をより正確に定式化したいと考えています。



要するに、mavenプロジェクトのリリース管理の主な問題はmaven自体です。これは、ソフトウェア開発に対するCI（継続的インテグレーション）アプローチの要件を考慮して開発されたものではありません。

SNAPSHOTバージョンのパラダイムは、CIがソフトウェア開発の標準的なアプローチになったため、非推奨になりました。



詳細は以下をご覧ください。





たとえば、 「Continuous Delivery」という本に示されているCIの現代的な見方は、ブランチが悪であるという前提に基づいています。

理想的には、開発は単一のトランクブランチで行う必要があります。 可能な限り新しい開発ブランチを作成しないでください。



特に有害なのは、「 機能ブランチ 」と呼ばれるもので、その唯一の目的は、新機能の統合の難しさを最後の瞬間まで延期することであり、継続的統合（「継続的統合」）の原則に完全に矛盾します。



私の観点から、ブランチを使用できるのは、「 リリースブランチ 」の場合のみです。 開発がトランクと並行しているときに、本番バージョンのエラーを修正するために作成されたブランチ。

そして、それらを作成するために急いではいけません。 緊急の場合、タグまたはバージョン管理システムのリビジョンに基づいて、必要に応じていつでもリリースブランチをいつでも作成できます。



ブランチは「並行開発ライン」と見なされるべきです。

同時に複数行のコードの並行開発を行う必要がある場合は、新しいブランチを作成する必要があります。 実際には、これは非常にまれです。 唯一のケースは、リリースブランチが使用される以前のバージョンのバグ修正とサービスリリースです。 繰り返しますが、機能ブランチで作業しているときに「見た目が落ち着いている」開発者の快適さは、新しいブランチを作成するのに十分な議論ではありません。

したがって、私の観点から、多くのオープンソースプロジェクトの記事で言及されている単一のトランクの存在は、従うべき良い例です。



継続的配信方法のフレームワークにおけるもう1つの原則は、CIシステムによって生成される各ビルドアーティファクトが一意のバージョン番号を受け取る必要があるということです。 これは、特定のバージョンのコードを開発パイプラインの次のステージに転送する必要があるたびに、プロジェクトを新しい方法で構築せず、時間を浪費し、意図しない変更を行うリスクを負うために必要です。 たとえば、テスト環境で特定のバージョンのユーザー受け入れテスト（UAT）テストに合格した後のステージング。 代わりに、一意のバージョンのアーティファクトをアーティファクトリポジトリに保存する必要があります（たとえば、Nexus。コードと一緒にVCS（バージョン管理システム）に保存することはありません）。



プロジェクトでmavenを使用して依存関係を管理する場合、リリース管理の実際の問題は、mavenがすべての新しいビルドが新しい一意のバージョンを取得するように設計されていないことです。

mavenを使用して新しいバージョンをリリースするための古典的な一連の手順は、新しいリリースブランチを手動で作成し、pom.xmlを更新し、プロジェクトをビルドし、成功した場合はVCSに変更をコミットします。

VCSの2つのリビジョンが同じアーティファクトに対応するようになったため、バージョンの混乱はこの段階ですでに発生しています。 これらの変更のトランザクション性のトピックはここでは取り上げません。

これらのアクションを自動化するには、mavenリリースプラグインを使用できますが、それでも本質的に問題は解決せず、mavenプロジェクトはCIおよび継続的配信/展開により適したものにはなりません。

SNAPSHOTバージョンを使用すると、一見、CIビルドが可能になります。 実際、SNAPSHOTバージョンは混乱をさらに悪化させ、pomファイルの更新に追加の労力を必要とします。プロジェクトバージョンだけでなく、このプロジェクトのすべてのSNAPSHOT依存関係、およびそれを含むすべてのプロジェクトを手動で更新することを忘れないでください参照されます。 また、ここでMaven 3のバージョン範囲を追加すると、パズルのすべての部分を一致させる複雑さがすぐに実用を超えます。



理想的には、CIビルドシステム自体がアーティファクトのバージョン番号を生成し、Continuous Deliveryパイプラインのすべてのビルドチェーンに送信する必要があります。

たとえば、Hudson / Jenkinsはこれを行う方法を知らず、CIシステムを選択する際に深刻な考慮から除外する2つの基本的な欠点があります。

1. ジョブ設定での式言語のサポートの欠如
2. プラグイン設定の継承を使用して階層的に構成を構築する機能の欠如（同様の問題を解決する既存のプラグインには、実際的な利点はほとんどありません）。

まともなCIビルドシステムは、ビルドバージョンを生成および送信するタスクに簡単に対応します。 たとえば、私のお気に入りのQuickbuildは 、価格と品質の点で、おそらくこれまでで最高の選択肢です（ただし、数年前に比較しました。この間、 Thoughtworks Goはどこに移動したのでしょうか）。

残念ながら、副作用なしでバージョンをMavenビルドに転送することはできません（そうでしたか？）。

実行可能な最大値：

<project xmlns="..." xmlns:xsi="..." xsi:schemaLocation="..."> <modelVersion>4.0.0</modelVersion> <groupId>org.xxx</groupId> <artifactId>xxx</artifactId> <version>${ciVersion}</version> <packaging>jar</packaging> <properties> <ciVersion>0.0.0</ciVersion> </properties> mvn -DciVersion=1.1.1 deploy
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、この場合、pom.xmlでは、mavenに保存されているリポジトリは展開後に保存されます



${ciVersion}









変更せずに、これに依存するプロジェクトを構築するときに問題になります。



したがって、効果的なCI Mavenプロジェクトのパス上の問題はおよそ2つです。

1. CIシステムを使用して、接続されたジョブのチェーンを通じて一意のバージョンを生成および送信する複雑さ。
2. 生成されたバージョンをMavenビルドに転送できない。

最初の問題は、CIシステムを正しく選択するか、既存のシステムをカスタマイズするための追加の人件費によって解決されます。



2番目の問題は、たとえばAnt + Ivyの使用に切り替えることで解決できます。 アイビーは当初、Mavenの小児疾患に苦しむことはありませんが、かなり長い準備が必要であり、セットアップがより困難です（ただし、これはおそらく1回だけ行う必要があります）。



妥協案として、次のアプローチを使用しています。

1. すべての開発は、SNAPSHOTバージョン用に構成されたトランクで実行されます
2. CIは、VCSで新しいチェックを検出するとすぐにトランクを構築します。
3. トランクがUATの準備ができると、別の構成/ジョブCIシステムが手動で開始されます。
   
   
   1. 一意のビルドバージョンを生成します（たとえば、VCSリビジョンに基づいて）
   2. VCSから構築中のブランチを取得します
   3. mavenバージョンプラグインを使用して、プロジェクトバージョンとすべてのサブプロジェクトをステップ1で生成されたリリースバージョンに更新します（このステップのバージョンリリースに応じて、オプションでSNAPSHOTを更新できます）
   4. プロジェクトを構築する
   5. Nexusのリリースバージョンでビルドされたアーティファクトを展開します
      
      （私は、pomファイルのこの変更後にVCSでコミットされないことに注意してください）
   6. VCSのリビジョンが記憶されているか、タグが作成されています
   
   
   
4. 前の手順が正常に完了すると、次の/ジョブ構成が自動的に起動されます。これは、アプリケーションをターゲット環境（たとえば、テスト環境）にデプロイする役割を果たし、EL式などを使用して、前の手順で作成されたアーティファクトのバージョンを転送します。 この作業は、CIシステムのリモートエージェントを介してターゲットマシンで直接開始するか、ssh接続を介して展開全体を実行できます。 展開スクリプトもVCSに保存されます。
5. 修正プログラムの発行またはサービスパックの準備が必要な場合、目的のリビジョン（またはタグ）を分岐し、CIシステムの作業のリリースパラメーターを変更して、新しい分岐を使用し、構築されたアーティファクトの適切なメジャー/マイナーバージョンを生成します。 Quickbuildを使用する場合、この手順は、テンプレートから新しいジョブを作成する必要なく、既存の構成のパラメーターの2つの3つの値を文字通り修正することになります。

サブシステムで共有される重要なインターフェイスでは、独自のバージョン管理と分岐が実行されるため、実際には、CIジョブの構成はやや複雑です。 したがって、そのようなサブプロジェクトごとに、独自のCIおよびリリースジョブが構成されます。 CIビルドシステムがジョブの階層構造を十分にサポートしている場合、すべての共有設定はDRY原則に従い、1か所にのみ保存されるため、複数の構成の管理は問題になりません。



「Gitツールによる単純なリリース管理」の記事に戻って、多くの人がリリースブランチを拒否することは、説明したアプローチの実装に対する乗り越えられない障害となることに注意してください。

それぞれの新しい枝は悪です。 ブランチの数を一度に最小化する意図は非常に称賛に値しますが、より複雑なユースケース（ホットフィックスの独立リリースなど）をサポートしようとすると、非標準的に使用されるライブブランチの数が増え、その使用の複雑さが増します。

そして、記事で解決策が提案されている実際の問題は、ブランチの整理の問題/ VCSを操作する手順ではなく、Mavenがソフトウェア開発への継続的統合アプローチに適合していないという問題です。

---

コメントの結果によると、スナップショットの見返りとして提供できるものについて少し考えて、次の分野でのMavenの開発（またはシステムの別のビルドと依存関係制御システム）を歓迎するという結論に達しました：

• 自動バージョン生成の「戦略」のサポート。 「構築中に、乱数ジェネレーター、VCSリビジョン、または好きなものを使用して、そのようなモデルに従ってアーティファクトをバージョンに割り当てます」（これは今日、柔軟なEL Quickbuild式が救助に来る場所です）
• SNAPSHOTの代わりにリリースビルドの概念を導入して、このビルドでビルドおよび参照されたアーティファクトがリポジトリから削除できないことをMavenが認識できるようにします。 しかし、バージョン番号がリリースアーティファクトバージョンと一般に異ならない他のものは、時間をかけて簡単に削除できます。 既存のシステムとは異なり、デフォルトでは、すべてのアーティファクトは一意のバージョンを受け取り、リポジトリから削除する候補となります。 そのうちの1つがリリースビルドから突然参照された場合、自動的にリリースアーティファクトステータスになります。