JavaでMavenを使用してリリースを作成する

この記事は何についてですか？

この記事の内容は次のとおりです。

1. リリースとは何ですか？
2. リリースはどのように番号付けされますか？
3. リリースするときにブランチが必要なのはなぜですか？
4. リリースが単なるjar（war、ear、zipなど）だけではないのはなぜですか？
5. maven-release-pluginとは何ですか？
6. release：branchを使用してブランチを作成します。
7. releaseを使用したリリースの準備：prepare。
8. release：performを使用してリリースをリリースします。

この記事を読んで理解するには、Mavenをブラッシュアップすることをお勧めします。 この技術を理解しないと、多くの用語を理解できない場合があります。

最初のいくつかのセクションでは、リリースの一般的な概念と番号付けについて説明します。 十分な経験がある場合は、スキップしてください！

リリースとは何ですか？

私自身にとって、リリースとは特定の機能セットを修正することです。 機能を統合すると、「このバージョンの製品には、新しいドキュメントの作成、指でページをめくる、またはロケットを宇宙に発射する機能が含まれます」と言います。あなたのリリースができることとできないことは、エラーがあなたのシステムに侵入した場所などを言います。
小さなプロジェクトの例を考えてみましょう。 市の動物園が動物の状態を監視するシステムの開発を命じたと想像してください。動物が住んでいるケージ、飼育係が動物の世話をします。 また、動物が世話をする必要があることをSMSで管理人に知らせる必要があります。
プロジェクトがWeb向けに行われ、次の構造を持つようにします。
zoo
|---zoo-web
|---zoo-sensor-server

私たちのリリースは戦争であり、Webサーバーに展開し、動物のいる鳥小屋のセンサーからメッセージを受信する小さなサーバーで圧縮します。

リリース番号

「ソフトウェアの変更を追跡するために、多数のソフトウェアバージョン番号付けスキームが作成されました」とウィキペディアは語っています。
そして、これは本当にそうです。 ほとんどのプロジェクト、企業、製品、および個々の開発者は、独自のバージョン管理方法を使用します。
Mavenは、多かれ少なかれ一般的に受け入れられているxyz番号付けスキームを使用することを提案しています。

• x-メインリリース機能の数
• y-追加のリリース機能の数
• z-バグ修正番号

たとえば、1.3.23、0.7.7、および1.4.112。 動物園に使用します。

一方、動物園で

そこで、動物園の管理に同意し、本格的な製品を発売する前に、3つの中間バージョンを提供することにしました。 最初のものには、鳥小屋のセンサーから情報を収集するサーバーの実装が含まれます。 Webパーツは非常にシンプルで、準備されていない形式でメトリックを表示します。 2番目のものには、鳥小屋、並べ替えオプションなどに関する情報を含む全画面が含まれます。 3番目-SMSを介して必要なアクションについて従業員に通知する機能が含まれます。 そして、すべてを収集し、クライアントがすべてを気に入った場合にのみ、最終リリースをリリースします。

0.y.0

各中間バージョンにそれぞれ名前0.1.0、0.2.0、0.3.0を付けます。
メインリリースはまだリリースされていないため、最初の数字は0です。これは中間結果にすぎません。
2桁目は配達番号と同じです。 3番目は0です。これは、アセンブリの時点でバグはないと考えているためです。
3桁目が0の場合、多くの場合、0.1、0.2、0.3が書き込まれません。

アルファ、ベータ、その他のRC

クライアントにリリースを提供する前に、中間であっても、彼はQAプロセスを経る必要があります。 テストリリースのリリース方法も異なる場合がありますが、私のプロジェクトではリリース候補の概念を使用しようとしています。
xyリリースをリリースする前に、リリースが安定しており、UATまたはProductionで準備ができていることがQAから通知されるまで、xy-RC1、xy-RC2などをビルドします。
その後、最後のRCが待望のリリースになります。

0.1.x

コードにエラーがあります。 そして、ユーザーは喜んでそれらを見つけます。 サポートのプロセスでは、新しいバグが開始され、それらを編集し、修正を加えたバージョンを提供する必要があります。 このために、バグ修正リリースが収集されます。
たとえば、バージョン0.1.0をリリースしましたが、実際の作業中に温度センサーデータが正しく処理されないことが判明しました。 リリース0.1.1がリリースされ、迷惑な誤解が修正されました。

最終リリース以降

一連の中間配信の後、1.0-RCを構築し、QAプロセスを完了して、1.0を構築します。 その後、顧客が夜間に自動的にセルを開く機能を必要とする場合、動物が戯れるように、1.1を作成して組み立てます。 数十個のバグが見つかり、1.1.47をリリースします。
彼が突然、もっときれいに、もっとかっこよく書き直したければ、おそらく2.0、2.1.45などが必要になるでしょう。

リリースブランチ

したがって、リリースは機能の統合です。 つまり、鳥小屋のセンサーからデータを収集するためのサーバーを作成しました。 シンプルなWebインターフェイスを作成しました。 すべてをテストして動物園に渡し、センサーを配置させました。 美しくフレンドリーなインターフェイスの作成を開始します。 そしてもちろん、これに対処します。
いくつかの質問があります：

1. 新しいフレンドリーなインターフェイスコードはどこに書くべきですか？
2. 動物園で突然情報が見つかった場合、センサーからの情報を処理する際のエラーをどこで修正しますか？

トランクでは、もちろん、エラーを修正する必要があります。 しかし、新しいバージョンを数日でまとめて動物園に渡すことはできません。 美しいインターフェイスのためにすべてを整理しました。
したがって、通常、基本機能または追加機能を備えたリリースのリリースには、 VCS （ブランチ）でのブランチの作成が伴います。 このブランチには、現在の製品バージョンのクライアントで見つかったバグの修正が含まれます。 トランクでは、何でもできます。 同時に、バグ修正のみを含む安定したコードが常にあります。
通常、このようなブランチは<プロジェクト名> -0.1.xと呼ばれます。つまり 、このバージョンの修正バグを含むリリース0.1からのブランチです。

リリースが戦争の組み立て以上のものである理由

最終製品は、ただの戦争ではありません。 製品にはライフサイクルがあります。 他の製品で使用できる必要があります。 サーバー動物園での火災の結果、すべてのアセンブリが失われた場合、リリースを再構築できます。
リリースは2つのタスクを実行する必要があります。

1. 収集された製品の可用性の確保と確保。
2. 再アセンブリまたはこのリリースからの新しいブランチの開始の場合の、リリースのソースコードの統合。

したがって、動物園の組み立てられた戦争とzipがどこにあるかを見つける必要があり、 VCSレベルでコードのこの特定の状態がリリースに対応していることも覚えておく必要があります。

コードの状態を覚えておいてください

これにはタグが使用されます。 バージョン管理システムのタグ。これは、リビジョンに割り当てられた名前です。 カスタムルックの場合、タグは同じソースフォルダーですが、その状態はタグが作成された時点で固定されています。 また、タグをブランチとして使用しないでください。

組み立てた製品を広げる

組み立てられた製品を保存してアクセスできるようにするために、外部サーバーでボールを使用することもできます。 Mavenは、産業開発にリポジトリの概念をもたらします。 アーティファクトはリポジトリに保存されます。リポジトリからアーティファクトを取得できます。 リポジトリは、グループ、名前、およびバージョンごとに成果物を構造化します。

すべて一緒に

する必要があります：

1. これが基本機能または追加機能のリリースである場合は、バグを修正するためのブランチを作成します。
2. リリース時のコードの状態を記憶するタグを作成します。
3. 製品をビルドし、パブリックアクセスのために共有します。

maven-release-plugin

maven-release-pluginは、バージョン管理システムとリポジトリ間の対話ツールであり、いくつかのコマンドでリリースできます。 プラグインは、開始から終了までのリリースプロセス全体を実行します。

プラグイン構成

プラグインが機能するには、プロジェクトのメインモジュールのpom.xmlに次の情報が必要です。

バージョン管理情報

まず、プロジェクトのソースコードが保存されている場所を示す必要があります。 これを行うには、標準のMavenタグを使用します。

 <scm> <connection>scm:svn:http://svn.zoo.com/zoo/trunk</connection> </scm> 

scm：svn：httpは、 scmプロトコルを使用して、 http：パスに沿ってsvnリポジトリと対話します。 SCMは、バージョン管理システムを操作するためのMavenプロトコルです。
Mercurialを使用して動物園を作成する場合、以下を作成する必要があります。

 <scm> <connection>scm:hg:http://svn.zoo.com/zoo/trunk</connection> </scm> 

ビルド設定

リリースのパラメーターを設定するために、セクションへのプラグイン接続が使用されます。

  <ビルド> <プラグイン>。 

  <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-release-plugin</artifactId> <configuration> <tagBase>svn://svn.zoo.com/zoo/tags</tagBase> <branchBase>svn://svn.zoo.com/zoo/branches</branchBase> <preparationGoals>clean install</preparationGoals> <goals>deploy</goals> <autoVersionSubmodules>true</autoVersionSubmodules> </configuration> </plugin> 

構成：

• tagBase-タグが保存されるリポジトリ内のフォルダへのパス。
• branchBase-ブランチが保存されるリポジトリ内のフォルダへのパス。
• PreparationGoals-タグを作成する前に、リリースの準備で実行するタスク。 これは通常、標準のビルドサイクルです。
• 目標 -リリース自体で実行する必要があるタスク。 通常、これらは統合テストおよび共通リポジトリへの展開です。
• autoVersionSubmodulesは、プロジェクト内のすべてのモジュールの新しいバージョンを一度に指定できる便利な設定です。

プラグインはプロジェクトバージョンも使用します。

 <version>0.1-SNAPSHOT</version> 

一般的な要件

リリースを作成するには、 VCSのクライアントをシステムにインストールする必要もあります。 コンソールからアクセス可能で、PATH（svn、hg、git）にある必要があります。
また、コードにローカルな変更がある場合、プラグインではリリースを作成できません。 そして当然です！
リリースを作成するには、プラグインにバージョン管理システムへの書き込みアクセスが必要です。 マシンの認証キャッシュに必要な情報があることを確認するか、-Duser = <vcs-user> -Dpassword = <vcs-password>を使用します。

zoo-0.1リリースを作成する

動物園の最初の配信のリリースを収集します。 バージョン0.1-RC3-SNAPSHOTのトランクがあります。 QAチームは、RC2で十分にリリースできることを通知しました。

リリース用ブランチの作成-リリース：ブランチ

この項目を完了する必要があるのは、基本機能または追加機能を備えたリリースをビルドする場合のみです。 バグ修正リリースzoo-0.1.2を収集している場合、このポイントはスキップします。
リリース候補を収集する場合、このステップもスキップします。
ブランチを作成するには、次を行う必要があります。

 mvn release:branch -DbranchName=zoo-0.1.x 

実行時に、Mavenはトランクの次のバージョンを尋ねます。デフォルトでは0.2-SNAPSHOTを提供します。
What is the new working copy version for "Zoo"? (com.zoo:zoo) 0.2-SNAPSHOT:


リリースの準備-リリース：準備

maven-release-pluginに関するプレリリースフェーズには、プロジェクトの検証（コンパイル、テスト、アセンブリ）およびVCSでのタグ作成が含まれます。 タグは、構成中に指定されたフォルダーに作成されます。
リポジトリから選択した後、作成したブランチからリリースします。 前のステップで、トランクは新しい生活を始め、私たちは彼に触れなくなりました。

バグ修正リリースを収集する場合、何も選択する必要はありません。 すでにバグ修正のためにブランチにいます。
リリース候補を収集している場合、トランクからこのフェーズを実行しています。
次のコマンドを実行します。

 mvn release:prepare 

Mavenは、収集するバージョン番号、タグの名前、および次のバージョン番号を常に要求します。
これは最初の将来のバグ修正リリースであるため、最後の質問には0.1.1-SNAPSHOTと答えます。

リリースリリース-リリース：実行

リリース実行フェーズには、タグからソースコードをチェックしてビルドすることが含まれます（通常、展開フェーズの前）。 はい、そうです、彼らはタグからソースコードをチェックアウトします。 作業コピーのソースコードが既にあるのに、なぜこれが必要なのですか？ Mavenは、このアセンブリがタグを手動で選択することで実行できるものと同一であることを確認したいためです。
リリースを完了するには、以下を完了する必要があります。

 mvn release:perform 

今回は何も聞かれず、必要なことを何でもします。 結果は、一般的なアーティファクトリポジトリに投稿されたリリースになります。

何かがうまくいかなかった場合。

プラグインの使用中に何かが壊れた場合、次の3つのオプションがあります。

1. たとえば、バージョン管理システムを備えたサーバーが利用できなかったなど、外部要因によりこれが発生した場合は、タスクを再度実行します。 プラグインは最後に成功したアクションを記憶し、続行しようとします。
2. アセンブリエラー中にプラグインが発生した場合、たとえば、統合テストに合格しなかった場合、 release：rollbackを使用します。このコマンドは、すべてのバージョン変更をロールバックし、バージョン管理システムから失敗したタグを削除します
3. ロールバックするものが何もないと確信していて、もう一度やり直したい場合は、 releaseを使用してください：clean