2

私は SCM に所属しており、さまざまなツール (Subversion、Clearcase、TFS、Perforce) とテクノロジ (主に .NET、Java) を扱っています。私が仕事を始める前は、管理された支店を作るのが通常の仕事でした。

管理されたブランチを次のように定義します。 -開発者がアクセスできない昇格されたコードを含む別のブランチ。これにアクセスできるのは、ビルド エンジニアのチームだけです。

制御されたビルド: -制御されたブランチからコードを取得し、開発者が変更できないアーティファクトを生成するビルド エンジン。

その結果、このブランチへのマージは、制御されたビルド プロセスの一部として重要なステップになりました。これにより、速度とエラーの両方の問題が発生する可能性があります (自動化によってほとんど軽減されます)。

利点: 自動コード ロック (開発者はブランチを変更できないため) ブランチ名は異なる場合があります (他のチームは必ずしも標準化された慣行に従っているとは限らず、必要な圧力をかけることができるとは限りません) 正確なバージョン コードを見つける簡単な方法状態 (つまり、バージョンの管理されたブランチの最新のコードは、製品に移行したものです)

欠点: 開発者と問題について話し合うときに、開発ビルドと制御ビルドを一致させる速度が上がります (これは自動化されていますが、少し面倒です)。エラー (プロセスを台無しにする別の場所) 変更リスト/変更セット/不変ラベルを使用して、セキュリティ/役割分離機能を完全に処理できますか?

質問:

現在の管理されたブランチ戦略から移行することをお勧めしますか? 他の特典がありませんか?

4

2 に答える 2

3

ブランチにマージされるラベルから多くの変更を行うつもりでない限り、プロモーション メカニズムとしてブランチを使用することはお勧めしません。ブランチは開発作業を分離する必要
があります (つまり、ファイルが変更され、新しいバージョンがコミットされる場所)

ある種のメタデータ (ClearCase 属性、SVN プロパティ、Git ノートなど) に関連付けられたラベルは、さまざまなプロモーション レベルを通じて、そのラベル (不変のコンテンツを含む) のプロモーションを監視するのに十分なはずです。

于 2011-01-11T18:59:33.043 に答える
0

公式のビルド ブランチとして、管理されたブランチ (MAIN) を使用します。開発者は、開発ブランチからのマージ操作を通じてのみ、このブランチへのアクセスが許可されます。さらに、MAIN ブランチ コードは、ソフトウェアの現在のリリースのバグ修正専用の BUGFIX ブランチと、コードがリリースごとにラベル付けされている PROD ブランチにマージされます。

私は、テスト (そして最終的には) 運用目的でビルドされるものはすべて、開発者が簡単にアクセスできるようにすべきではなく、SCM マネージャーまたはその他のタイプのライブラリアンの役割によって管理されるべきであるという意見です。

MAIN ブランチ内でビルドの問題が発生した場合、開発者によって開発ブランチ内でそれらのバグが修正され、SCM ポリシー内で解決策が MAIN にマージされることにも固執します。

于 2011-01-11T20:30:09.853 に答える