1

私のチームは、SVNを使用してQA環境にデプロイし、そのDEVストリームをテストしてクリーンに保つことに問題があるため、QAの進行中に継続的な開発を行うことができます。

まだ出会っていない問題を解決するアプローチがあることを願っています。

詳細:SVNにDEVブランチがあり、UI開発者用に1つのコードベース、サーバー開発者用にもう1つのコードベースがあります。

展開すると、.EXEファイルと.SWFファイルがサーバー側のフォルダーにチェックインされ、サーバー開発者はTRUNKにプッシュします。そこからWARファイルが作成されます。

問題は、QAが進行している間、サーバー開発者は将来の機能とバグに取り組み続け、UIに対してコードをテストするためにQA環境にプッシュする必要があることです。

専用のDEV環境はありません。それが問題の大きな部分であることを私たちは知っています。

質問は; QAにもSVNの別のブランチを使用する必要がありますか?では、QAにプッシュするたびに、コードをQAブランチに配置しますか?

このようにして、環境をサニタリーに保ち、必要なときにいつでもQASVNブランチからビルドオフを実行できます。

ほとんどのチームとは異なり、QAにプッシュするときに開発を停止することはないと思います。私たちは前進し続け、QAが見つけたバグに対処します。基本的には、好きなときにPRODにプッシュします。だからこそ、衛生的な環境が必要です。

長い投稿で申し訳ありませんが、ここでは少し轍があります。

4

1 に答える 1

5

この質問は破壊とはあまり関係がないと思います。問題をすでに特定しているようです。DEVテストとQAテストの両方に単一の環境を使用しています。2つの機能のために2つの環境が必要です。

ブランチ戦略に関しては、リリースごとのブランチワークフローに従うことをお勧めします。このワークフローでは、QA、次にPRODにリリースするたびに、トランクから新しいリリースブランチを切り取ります。トランクから静的QAまたはPRODブランチにコードをプッシュするべきではありません。リリースを行うたびに新しいブランチをカットする必要があります。

最後に、バイナリ/デプロイ可能な管理をソース管理から分離することをお勧めします。コードのすぐ隣のsvnに最新の.exeファイルのコピーを保存しないでください。ビルドアーティファクトをsvnに保持する場合は、継続的ビルドプロセスを設定して、アーティファクトを別のsvnリポジトリに公開することをお勧めします(このプロセスでは、アーティファクトを単純なファイル共有に公開することもできます。これにより、使用が簡単になる場合があります)。バイナリを「最新」に保つために手動プロセスを必要としないようにします。

于 2012-11-23T15:01:28.320 に答える