5

Subversion、Jenkins、Beanstalk のセットアップは次のとおりです。

  • トランク/ -> 開発本線
    • チェックイン時の CI ビルド
    • CI ビルドが成功すると、「テスト」Beanstalk 環境にプッシュする CD ビルドが生成されます
  • branch/qa/ -> 現在のリリース候補
    • チェックイン時の CI ビルド
    • CI ビルドが成功すると、「QA」Beanstalk 環境にプッシュされる CD ビルドが生成されます
  • ブランチ/製品/ -> 現在のリリース
    • チェックイン時の CI ビルド
    • CI ビルドが成功すると、「Prod」Beanstalk 環境にプッシュする CD ビルドが生成されます

基本的に私がやりたいことはこれです：

  • 開発サイクルはトランクから始まります (トランク: 0.1-SNAPSHOT)
  • 開発サイクルが完了すると、qa に分岐し、qa サイクルになります。また、トランクで次の開発サイクルを開始します (トランク 0.2-SNAPSHOT、qa: 0.1-SNAPSHOT)
  • qa サイクルが完了したら、prod に分岐し、maven リリースを実行します。また、次の qa サイクルを開始します (トランク 0.2-SNAPSHOT、qa: 0.2-SNAPSHOT、prod: 0.1)

アイデアは、各開発サイクルの終わりに QA サイクルが始まる短いスプリントを持つことです。qa サイクルが完了すると、本番環境にプッシュされます。

削除して再作成するのではなく、ブランチを保持し、ブランチへ/ブランチからマージしたいと思います。qa で行われた修正は intro トランクにマージされ、prod で行われた変更は qa にマージされます (そしてトランクに戻されます)。

したがって、prod は「ホット」なブランチであり、本番環境の現在の状態を表しています。

これは、1 週間のスプリントに取り組んでいる小さな開発者チーム向けです。

質問:

  1. このセットアップはどのように聞こえますか?
  2. Maven を正しく動作させることはできますか、それともこれをスクリプト化する必要がありますか?
  3. お父さんは誰？そして、彼は何をしますか？
4

2 に答える 2

7

qa および prod ブランチはお勧めしません。Subversion のベスト プラクティスを読んでください。The SVN Book、特に分岐/マージに関する第4章をお勧めします。

QA (タグを介して) であっても、すべてのリリースをバージョン管理する必要があります。トランクは現在の開発作業に使用され、タグはリリースされたバージョン (どの環境にあるかではなく、「機能が完了した」と定義されます) 用であり、ブランチは (とりわけ) 欠陥修正用です。

サンプル シナリオ:

バージョン 1.0 は本番環境にあり、チームはテスト用に 2.0 を QA にリリースしたばかりで、現在 3.0 のリリースに取り組んでいます。この時点で、次のようになります。

  • /trunk (3.0 に取り組んでいる開発者)
  • /tags/2.0 (QA に使用)
  • /tags/1.0 (本番環境の履歴)

QA チームが 2.0 に問題を発見した場合、2.0 タグからブランチを作成します。修正を行い、トランクにマージしてから、ブランチを 2.0.1 (別のタグ) としてリリースします。その後、次のものが残ります。

  • /trunk (3.0 に取り組んでいる開発者 + 2.0 の不具合修正)
  • /branches/2.0.* (* 文字を使用して、すべての 2.0.* 修正がコミットされる場所であることを示します。2.0 コードでさらに別の欠陥が見つかった場合は、この同じブランチを再利用できます)
  • /tags/2.0 (元のタグ QA は欠陥でテストしていました)
  • /tags/2.0.1 (2.0 コードベース、不具合修正のみ)
  • /tags/1.0 (本番環境の履歴)
于 2012-08-13T15:59:30.913 に答える
1

私は以前に分岐とリリースに関して同様の作業を行ったことがありますが、私の経験では、あなたが説明したセットアップは、やがて非常に扱いにくく、官僚的になりました。

Domenic D. の答えは、特に少数の開発者の場合、私が好むセットアップにかなり近いものです。ブランチが多ければ多いほど、コード ベースの管理が複雑になり、その可能性が高くなります。悪いマージ方法によるエラーの導入。

あなたが言及していないことの 1 つは、私の意見では、最初に正しく行うために重要なことは、チェックイン ポリシーです。SCM は不完全な作業のバックアップではありません。メインラインが少なくとも常に構築されていることを確認するように努める必要があります。これについては厳しくしてください。最終的には、すべての人の生活が楽になります。

ただし、重要なことは、どのようなリリース手順を提示する場合でも、チームから賛同を得て、「強制」される必要がないことを確認することです。これは、あなたが思いついたことが正しくないことに何か問題がある可能性があるという兆候であり、おそらくすぐに無視されるか、覆されるでしょう.

于 2012-08-16T09:07:53.893 に答える