2013-04-15 3 views

答えて

6

ステージングは​​git flow releaseブランチに基づいていなければなりません。 git flow release startgit flow release publishの後に、そのブランチに対してQA作業を開始することができます。これには、ステージング領域への発行も含まれます。ステージング領域でのQA作業により、プロダクションリリースの準備ができていることが実証され、git flow release finishが実行されます。

TeamCityを使用している場合、新しいリモートリリースブランチを検出し、それらのビルドを自動的にセットアップするサーバーを簡単にセットアップすることができます。see here

+0

開発およびマスタブランチと同じように、「テスト中の次のリリース」(ステージング)専用のブランチを用意するのではなく、潜在的なリリースごとに異なるブランチを使用することをお勧めしますか? – Eric

+0

はい、それはそれを行う標準的な流行の方法、afaikだろう。ブランチには常に同じ名前を付けることができます。 "ステージング"。しかし、通常のgit-flowの使用は、 'git flow release finish'を実行したときにブランチを削除し、' git flow release start'を実行したときに再作成します。 –

+0

このメソッドではどのようにプルリクエストを処理できますか? –

2

私はgitのフローを使用して起動しましたが、最も簡単な方法があるIMHO devブランチと生産のリリースstage支店などして、例えば手動masterブランチ(あなたの本当の生産)と合併.:として次のリリースを設定します。

バージョン1.2.0をstageにリリースして、リリース(たとえば、コアCMS、機能1、機能3、機能4の4つの修正プログラム)でバグを見つけた場合は、いつでもパッチを適用できますバージョン1.2.4で作成し、最後に本番環境にマージします。

更新:このシナリオでは、ロールバックメカニズムがないと仮定して、常にを追加すると、を追加すると、フィーチャーやその他の機能が修正されます。ロールバック機構を持っているならば、あなたの生産におけるあなたのバグについて心配する必要はありません。あなたがエラーを発見したときには、前の作業バージョンを設定するためにロールバックを使用します。例:バージョン1.2.3のバグが見つかった場合は、バージョン1.2.2に戻ります。バグを修正し、でテストし、次にstageにあり、versioin 1.2.4として生産にプッシュします。したがって、あなたの作品は1.2.2からすぐに1.2.4にジャンプします。