13

私は製品開発会社で働いています。最初に内部リリースを行い、次に公開リリースを行います。他の製品開発会社がどのようにリリースを管理しているのでしょうか。リリース番号はどのように付けますか？ソース管理にタグを付けますか？

4

8 に答える 8

12

タグとブランチの作成が安価な SubVersion を使用します。

リリースに関しては、次の規則に従います。

(メジャーリリース).(マイナーリリース).(パッチリリース).(SVNリビジョン)

  • パッチリリース = バグ修正
  • マイナー リリース = バイナリ互換 / インターフェイス互換
  • メジャー リリース = 重大な変更が含まれています。

それは理にかなっていますか？さらに情報が必要な場合は、コメントを追加してください。明確にするために投稿を編集します。

于 2008-09-25T17:47:22.693 に答える
3

私は同様の質問を作成しましたが、これに追加したいと思いました: Jiraのようなものを使用してリリース サイクルを管理することを強くお勧めします。コミットをリクエスト/問題/バグに関連付けて、リリースの一部としてフラグを立てることができます。

特に、適切なリリース サイクルを管理する方法を知りたい場合は、Apache Foundation がそれをどのように行っているかを調べてください。たとえば、Mahout プロジェクトのリリースのロードマップは次のとおりです。

問題を追跡してリリース パッケージにバンドルする作業システムに加えて、これを継続的インテグレーション (私は CruiseControl と Hudson の両方を使用しました) および単体テストと統合して、ビルド サイクルがすべてと共に管理されるようにする必要があります。そうしないと。

于 2009-11-03T21:44:30.053 に答える
2

私はカスタム ソフトウェア プロバイダーで働いていましたが、顧客が独自のコールセンターや Web サイトを実装したくないと判断したため、最終的にソリューション プロバイダーに変わりました。

その環境では、各主要顧客は、システムの動作方法のいくつかの側面をカスタマイズする機会がありました。そのため、開発には、すべての契約に共通のコンポーネントを備えたコア製品と、顧客ごとに個別のブランチがありました (一部の顧客は微調整が必​​要で、他の顧客は他のシステムとの主要な統合が必要でした)。

ビジネスが成長し、支店の数が拡大するまで、それはうまく機能しました。ある時点で、彼らは同じコードベースの 15 の異なるアクティブなバージョンのようなものを持っていたと思います。

私たちがしたことをするのではなく、リリースをスケールさせてください!

于 2008-09-25T18:53:33.627 に答える
1

私の会社では、リリースの準備ができたら、メジャー/マイナー リリース番号のブランチを作成しますR_2_1。最初のリリースは、 という名前のスナップショット ブランチまたはラベルを直後に作成することによって行われR_2_1_0ます。QA がリリースに対してバグを報告すると、R_X_Yブランチでコード変更が行われ、R_2_1_1そのリリースをマークするためにブランチが作成されます。したがって、ツリーは次のようになります。

Mainline
|
|- R_2_1
|  |
|  |-R_2_1_0 (locked)
|  |
|  |
|  |-R_2_1_1 (locked)
|  |
.  .
.  .
.  .
于 2008-09-25T17:51:11.297 に答える
1

ITILフレームワークに基づく回答（他のフレームワークとほぼ同じです）。

ITIL はリリースを、メジャー ソフトウェア リリース、マイナー ソフトウェア リリース、緊急ソフトウェア修正の 3 つのグループに分類します。

ITILの本から：

• 主要なソフトウェア リリースとハードウェア アップグレード。通常、新しい機能の大きな領域が含まれます。その中には、問題に対する介在修正が冗長になる場合があります。通常、メジャー アップグレードまたはリリースは、先行するすべてのマイナー アップグレード、リリース、および緊急修正に取って代わります。
• マイナー ソフトウェア リリースとハードウェア アップグレード。通常、小規模な機能強化と修正が含まれます。これらの一部は、緊急修正として既に発行されている場合があります。通常、マイナー アップグレードまたはリリースは、先行するすべての緊急修正に取って代わります。
• 緊急のソフトウェアおよびハードウェアの修正。通常、少数の既知の問題に対する修正が含まれます。

したがって、これに続いて、次のものが必要です。

メジャー: v1、V2、v3 など
マイナー: v1.1、V2.1 など
緊急: v1.1.1、V2.1.1 など

于 2009-10-16T19:58:15.800 に答える
1

SVN を使用し、リリースごとに 2 つのブランチを作成します。1 つはこのリリースのビルドに使用されたソース コードのタグで、もう 1 つは実際にリリースされたバイナリの新しいインポートです。これは重要です (2 人の開発者のマシンをどれだけ同じにしようとしても、安定したビルド マシンを維持しようとしても) 6 か月後にビルド X を再生成しようとすると、必然的に何かが見つかるからです。変更され、結果のバイナリは微妙に異なります。

マイナー パッチは、リリース ソース ブランチからコピーされたブランチで作成され、トランクにマージされます。マイナー リリースは、リリース ソース ブランチを新しいブランチにコピーし、必要なパッチをマージすることで簡単に作成できます。

主要な作業はトランクからコピーされたブランチで実行され、完了するとトランクにマージされます。その後、トランクからメジャー リリースを行うことができます。

于 2009-06-01T10:43:12.673 に答える
0

TFSに関するco-catの回答へのフォローアップ。VS2010 および VS11 のいくつかの更新を含む新しい URL があります。

http://vsarbranchingguide.codeplex.com/releases

于 2012-04-25T16:32:39.317 に答える