Test、Production、およびDevelopmentに個別のコード行は必要ありません。テストおよび本番の担当者が独自のコーディングを行うことを期待しない限り。そうしないと、多くのものを前後にコピーすることになります。
開発者が取り組んでいるリビジョン (たとえば、Subversion リビジョン #100 としましょう) は、しばらくして QA チームがテストのために取得する予定です。そして、QA チームが気に入れば、リビジョン #100 が本番環境にリリースされます。各チームは他のチームに従います。開発中は Subversion Revision 100 に取り組んでいるかもしれません。一方、QA は Revision 97 をテストしています。また、Revision 90 は本番環境にあるものです。私がお勧めする唯一のことは、本番環境に移行するものにタグを付けることです。
典型的な構造を見てみましょう：
repo/branches/
repo/tags
repo/trunk/common
repo/trunk/projects
私はプロジェクトのトランクから離れて働いていますfoo。チェックアウトrepo/trunk/fooしrepo/trunk/commonて作業を行い、変更をチェックインします。
ここで、リビジョン 90 をトランクからタグ付けしたいとしましょう。これは生産が承認されているためです。次のようにリリースにタグを付けることができます。
$ svn cp --parents -r 90 $REPO/trunk/foo@90 $REPO/tags/1.3/foo
$ svn cp -r 90 $REPO/trunk/common@90 $REPO/tags/1.3/common
何がリリースされたかを確認する必要がある場合は、リポジトリから 1.3 リリース タグをチェックアウトできます。
通常、分岐を使用する方法は 2 つあります。
リリース ブランチについて説明するのは、簡単だからです。
1.3 のリリースに取り組んでいると想像してください。ある時点で、一部の開発者は 1.3 リリースで行う作業がなくなり、リリース 1.4 で作業したいと考えています。
この時点まで、1.3 リリースの作業はトランクで行われていました。1.3 コードの変更に取り組んでいる間、1.4 の開発者は 1.4 の変更を行いたくないため、作業を行うことができません。そのため、彼らは 1.3 が完成するまで 1 日中 Candy Crush をプレイし、1.4 のリリースでは誰もがトランクから作業できるようになります。
Candy Crunch の時間を短縮するために、リリースブランチを作成します。
$ svn cp --parents $REPO/trunk/foo $REPO/branches/1.3/foo
$ svn cp $REPO/trunk/common $REPO/branches/1.3/common
現在、リリース 1.3 に取り組んでいる開発者は作業コピーを 1.3 ブランチに切り替え、1.4 に取り組んでいる開発者はトランクで作業を続けています。リリースが完了したら、ブランチからすぐにタグ付けできます。
$ svn cp --parents $REPO/branches/1.3/foo $REPO/tags/1.3/foo
$ svn cp $REPO/branches/1.3/commons $REPO/tags/1.3/commons
Release 1.4が近づくと、すすぎと繰り返し。
$ svn cp --parents $REPO/trunk/foo $REPO/branches/1.4/foo
$ svn cp $REPO/trunk/common $REPO/branches/1.4/common
現在、リリース 1.5 に取り組んでいる人はトランクで作業を続けていますが、リリース 1.4 に取り組んでいる人はブランチから離れて作業しています。
ホットフィックスを作成する必要がある場合はどうすればよいですか? リリース 1.4 にバグがあるとしますか? あなたはすでに 1.4 ブランチを持っていますが、リリース 1.4 がリリースされたときにはもう使用されていないと思います (チェックするのは簡単です。1.4 ブランチの最新のリビジョンと 1.4 タグを作成したリビジョンを比較してください)。1.4 ブランチでリリース 1.4.1 の作業を行うだけです。
ご覧のとおり、それほど複雑ではありません。ちなみに、名前も逆にできない理由はありません。
$REPO/foo/trunk
$REPO/foo/branches
$REPO/foo/tags
$REPO/common/trunk
$REPO/common/branches
$REPO/common/tags
この場合、私は各プロジェクトを独自の分岐とタグ付けを持つ個別のサブリポジトリとして扱っています。すべてのプロジェクトのリリース スケジュールが異なる場合は、これを行いたいと思うかもしれません。
応答
わかりましたので、共通フォルダーの下に既に「trunk/branches/tags」があります。したがって、Dev/Test/Prod フォルダー (および prod の内容) を完全に削除するだけでよいと思います。「テスト」は実際には Repo/foo/branches/test に格納されますが、正しいですか? または、Repo/branches/test/foo/ に移動できると思いますよね? (Common は SVN externals として設定されています...fyi)
テストブランチは必要ありません。QA は、開発者が使用しているブランチから直接特定の Subversion リリースをテストするだけです。たとえば、Subversion がリビジョン 100 にあり、QA がリビジョン 95 をテストしているとします。QA がバグを発見すると、報告され、リビジョン 101 に組み込まれます。QA がリビジョン 101 以降をテストするとき、そのバグが修正されているかどうかをテストできます。修正されました。もしそうなら、彼らはバグを閉じることができます。さもなければ、彼らはそれを再開するかもしれません。
変更のたびにソフトウェアをビルドするJenkinsのような継続的インテグレーション システムを使用している場合、特定のビルドについて話している可能性があります。最後のビルドはビルド #30 ですが、QA はビルド #28 をテストしています。QA がバグを見つけた場合、開発は単純にそれを修正し、Jenkins はビルド #31 を作成します。その後、QA はビルド #31 をテストして、バグが修正されているかどうかを確認できます。
1 つのショップで Jira と Jenkins を使用し、これらを統合しました。開発者がバグを修正するとき、そのバグ番号をコミット メッセージに入れます。その後、Jenkins はその Jira チケットを Jenkins ビルドで更新します。QA が修正された問題を見つけた場合、Jira チケットを確認し、修正された Jenkins ビルドを確認してテストすることができます。
これが理にかなっており、テストや本番などにブランチが必要ない理由が理解できることを願っています.
私はSVN構文をまったく使用していないので、--parentsのことを調査する必要があります...私たちはTortoiseのみを使用していますが、これはJenkinsを使用しているため、とにかくSVNを学ぶ必要があると思います.ビルド...
Subversion クライアントのコマンド ライン バージョンを知っておくとよいでしょう。TortoiseSVN で問題が発生した場合、コマンド ライン クライアントから詳細情報を取得して、何が起こっているかを確認できます。パラメータは、--parentsそこにある場合とない場合がある親ディレクトリを作成することを意味するだけです。たとえば、ディレクトリを作成したいが、ディレクトリ/branches/4.3/fooがない場合があり/branches/4.3ます。TortoiseSVN では、これは自動的に作成されると思います。コマンド ライン クライアントでは、--parentsパラメーターは/branches/4.3ディレクトリ (存在しない場合) とディレクトリの両方を作成し/branches/4.3/fooます。
あなたの答えの他のすべては素晴らしく見えます！私は Git のバックグラウンドがほとんどなく、SourceGear Vault のバックグラウンドがたくさんあるので、切り替えはまだ少し混乱しています。
Subversion は、リポジトリが 1 レベルしかないため、Git と比較すると実際には非常に単純です。チェックアウト、変更、コミットします。
Git と SVN の大きな違いは、SVN が線形であることです。リビジョン 100 は常にリビジョン 101 より前です。Git では、リビジョンに実際の順序はありません。リポジトリのリビジョンは、チェックサム付きのBLOBとして表されます。順序は、特定のブロブを指すツリーによって課されます。ただし、SVN に精通している人が Git を理解するのは、その逆よりもおそらく難しいでしょう。
もう 1 つ質問があります。ブランチ名がリリースごとに変更される場合 (つまり、1.3、1.4 など)、テスト環境のビルドを自動化するにはどうすればよいでしょうか?
Jenkins には、プロジェクトを複製する一連のシェル スクリプトがあります。プロジェクトをセットアップしたので、プロジェクト間の変更は最小限です。ブランチ名を変更するだけです。スクリプトを実行すると、さらに多くの Jenkins ジョブが作成されます。別のジョブを実行すると、古いブランチ ジョブが削除されます。
一部のサイトでは、post-commit トリガーを使用して、ブランチで実行される Jenkins ジョブを構築します。Jenkins では、パラメーターをビルドに渡すことができるため、変更が行われたブランチを渡すと、Jenkins はそのブランチでビルドします。あるリリースから別のリリースに移行する際に、新しいジョブを作成する必要はありません。
現在、毎週または隔週でリリースを行う場合、リリース ブランチは必要ないかもしれません。すべてがトランクから外れています (時折発生するホット パッチを除く)。この場合、チームの全員が同じリリースに取り組んでいる可能性が非常に高くなります。2 つの異なる開発者グループがリリース 1.3 と 1.4 (トランク上にある) で同時に作業できるようにするために分岐します。その問題がない場合は、リリース ブランチは必要ありません (臨時のホット フィックスを除く)。