2016-09-15 13 views
1

Mavenのバージョン管理並列開発プロセスMavenの並列開発プロセスのバージョン管理

私は通常のトランクとブランチでSVNを使用してプロジェクトを作成しています。 私は2つの異なるポリシー "リリース"と "スナップショット"を持つ2つのリポジトリを持つネクサスを持っています。 このプロジェクトは、私の会社の他のプロジェクトから使用される成果物を生成します。 新機能が必要な場合、私はアーティファクト-1.0.1.jarを持っている私たちがリリースリポジトリにそうネクサスにバージョン1.0.1にあるのは、現時点で言ってみましょう

私は、次の手順を実行します。

  1. をトランクから新しいブランチを作成しますのは、トランクからfeature_1を言わせので、私は今の支店/ feature_1
  2. は1.0.2-SNAPSHOTにバージョンを上げてきたし、ネクサス上で、私は1.0.2-SNAPSHOT.jarに
を持っています

1.0.2-SNAPSHOTがリリースされる前に、別の機能が必要とされ、私は前の手順繰り返します:

  1. をトランクから新しいブランチを作成しますのは、トランクからfeature_1を言わせので、私は今の支店/ feature_2
  2. を持っています1.0.3-SNAPSHOTにバージョンを増やし、ネクサスに私が持っているでしょう1.0.2-SNAPSHOT.jarに1.0.3-SNAPSHOT.jarにいくつかの段階で

私はfeature_2ライブ行く必要があります次の手順を実行します:

  1. トランク内でfeature2をマージする
  2. prodにデプロイし、artifacts 1.0.3.jarをNexusにプッシュします。

私はまだ進行中のfeature_1を持っており、リリースバージョンは1.0.3である一方で、バージョン1.0.2-SNAPSHOT.jarにしていなかった場合、プロセスが正常に動作します。

残念ながら、機能ブランチは順番にリリースされません。 この場合、バージョン管理はどのように管理できますか?私は何が欠けていますか?

1.0.2-SNAPSHOT(feature_1)のチームがトランクをブランチ/ feature_1にマージし、バージョンを1.0.2-SNAPSHOTから1.0.4-SNAPSHOTに増やすよう強制する必要がありますか?

それは私には正しいとは言えません。

答えて

1

トランクのみがリリースバージョン番号を持つ必要があり、ブランチからマージすると増加するはずです。ブランチは定期的に(変更されるたびに)トランクをマージする必要があり、スナップショット接尾辞付きのリリースのバージョン番号を持つ必要があります。

したがって、prodは1.0であるため、トランクも同様です。機能1はリリース1.1を対象とし、機能2はリリース1.2を対象としています。機能1のブランチは1.1-スナップショット、機能2のブランチは1.2-スナップショットです。すべてが計画通りになると、機能1をトランクにマージし、バージョン番号を1.1にアップグレードし、スナップショットをリリースし、削除し、トランクを機能2ブランチにマージします。フィーチャー2も同様の方法でリリースされます。

フィーチャ1が遅れている場合は、機能2をトランクにマージし、トランクのバージョン番号を1.1に上げてリリース(スナップショットの削除)し、トランクを機能1にマージし、バージョンを1.2スナップショットにマージしますそのリリース)、最初のスナップショットを作成します。

バージョン番号の接尾辞として1.0.0.4432のビルド番号などのインクリメンタルカウンタを使用する必要があります。あなたはsvnを使っているので、ビルド番号ではなく、svnのリビジョン番号を最後の部分として使うことをお勧めします。

ここで実際に問題となるのは、長寿命ブランチです。本当に大きな機能を扱う場合は、機能フラグを調べる必要があります。あるいは、小さなフィーチャを使用して、ほとんど発生しないようにすることで、革新的ではなく進化によって大きなフィーチャを段階的に提供することができます。個人的に私は機能フラグが気に入らないので、私は進化的アプローチを好む。

「vanity versioning」と呼ばれるものを使用しているという問題があります。実際のバージョンはsvnのリビジョン番号です(私のような古い人たちが時々svnというリビジョン管理システムと呼ばれる理由です)。現実には基礎がありません。これは、IntelliJとMicrosoftのような企業が使用を中止し、リリース年とカウントについて話を始めたためです。IntelliJ 2016リリース3は現在EAP(ベータ版)であり、163.4396のビルド番号163〜年とリリース)、CIのビルド番号が続きます。

+0

私はいつか5/6以上の機能ブランチを同時に持っていると考えています。この製品は、おそらく問題や遅延を伴う可能性のある他のシステムに依存しているため、実際には何の計画もありません。私はおそらく、バージョンのない機能ブランチを持つべきですが、機能の名前は "SomeFunctionality1-SANAPHOT"、 "SomeName2-SANAPHOT"とし、トランクにマージするときだけ2016.x.rnのようなバージョン番号を与えますビルド番号であり、rnはSVNからのリビジョン番号です。どう思いますか? – carlitos081

+1

あなたはそのように働くことはできず、肯定的な結果に達することを願っています。あなたは機能ごとに1つのチームがあると仮定すると、あなたはあなたが得ているように聞こえるよりもはるかに多くの管理を必要とする仕事のプログラムを持っています。あなたは、プログラム開発のための時間割を計画し、プログラムレベルでリリースすることができるはずです。あなたが記述しているようにバージョンが何であるかを知るまでバージョン管理を延期すると言っていますが、現時点で最良の選択肢と思われます。 –

+0

はい、私たちはその面で取り組んでいます。私たちのプロセスは正しくなく、バージョン管理はうまくいくものです。 – carlitos081

関連する問題