1

私は現在、多くの異なる部分を持つ .net のプロジェクトを開始しています。

1) Web Service API
2) Web Portal
3) 2 Windows Services + 1 Biztalk server
4) About 3 different Databases
5) Service bus connects them all via pub/sub
6) Client Web Application (Old) that already exists on another Team Collection to consume the web service api.

各プロジェクト領域は単体テスト可能であるため、さまざまなメッセージング部分から分離できます。AZURE でステージング/製品展開を行う予定です。何らかの統合テストを含める予定です。自動化されたテストを含めるために、チェックインごとに CI / ビルドがあります。

アプリケーション全体は、すべての部分が完了したときにのみ機能します。

質問

1) ソース管理と分岐戦略をどのように構築すればよいですか? 単純に Dev/Main/Release ブランチを持つことを考えています。6 つの部分を 1 つのブランチにする必要がありますか、それともすべて独自の Dev/Main/Release ブランチを持つ必要がありますか? CI / ビルド / バージョニングはどうですか? パーツごと、または 6 つのパーツ全体ごとにバージョン管理する必要があります。

2) 統合テストのテストを構造化するという点では、いつ、どこにコードを入れてテストを実行すればよいですか? 最後まで結合テストができるとは思えません。

どんなアドバイスも素晴らしいでしょう。

ジョシュ

4

1 に答える 1

2

これはかなり主観的な質問ですが、意見を述べることができます。明らかに、チーム、ソフトウェア、テスト要件などによって、ある人にとって最適な分岐戦略が別の人にとって異なる場合があります。

私のアドバイスは、ソフトウェアのメイン ブランチを 1 つ作成し、すべての単体テストをプロジェクト ソリューションに含めることです。プロジェクトで最初の開発を行うときは、そのプロジェクトを開発機能ブランチに分岐します (または、すべてを一緒にリリースする必要がある場合は、すべてを分岐します) (事実上、Dev という名前のソース管理フォルダーを作成して分岐します)機能のためにそれに入る）。

開発が完了したら、それを Main にマージします。通常、メインがゲート付きチェックインであることが理にかなっています。マージしたら、開発機能ブランチを削除します。

リリースの準備ができたら、リリース ブランチを作成し、そこからデプロイします。手動でテストする必要がある場合は、リリース ブランチをテストします。リリース ブランチを修正する必要がある場合は、分岐して修正し、修正してからマージします。削除したら、そのブランチを削除してください。

要約すると、別のブランチを作成する理由ができるまで、1 つのブランチを作成してください。dev/main/release 分岐はより概念的なものです。これは、3 つの別個のコード ベースを維持することを意味するものではありません。

于 2013-09-13T13:32:08.143 に答える