典型的なベストプラクティスのClearCaseプロジェクト構造

Question

開発プロジェクトでは、出荷されたコードは、生産に達する前にさまざまな段階の異なる環境間で移動できます（デプロイメントプロセスのテスト環境、QC、プリプロダクション、 ）。

この開発努力では、特定のリリースを生産に達するまで開発プロセスの上に移動するように指名することができる多数の候補リリースが作成されます。また、本番環境に配備されたコードにホットフィックスが必要な場合もあります現在の内部開発ライン（Parallel Development）と並行して実行されます。 IBM Rational ClearCaseの（CC）によって維持され、特定のUCMプロジェクトのために

、次のように対処するために、「プロジェクト・エクスプローラ」上で作成することが推奨されるプロジェクト構造です：

1. 開発者は、主に接続する必要がありますし、内部開発ライン（またはCC用語では開発ストリーム）での作業を行います。
2. この開発ストリームに配信されたコードが受け入れ可能であると考えられると、テクニカルチームリード（TTL）がベースラインを作成できます。このベースラインは、デプロイメントエンジニアが後でローカル開発環境にデプロイするために取得できます。
3. このベースラインが許容可能であると判断された場合、このベースラインは、品質検査（QC）テストのために導入される内部テストストリーム全体に渡すことができます。
4. このベースラインが許容可能であると判断された場合、このベースラインは全体としてプレプロダクションに渡すことができます。
5. 当然のことながら、これらのベースラインのいずれかが受信側当事者によって受け入れられなかった場合、それは拒否され、受信側当事者はストリームに対して別のベースラインが推奨されるのを待つでしょう。

注：デプロイメント・エンジニアは常にビルド/展開活動を行うために必要な、彼/彼女のファイルを取得するために、各環境に専用のストリームを使用します。

私はこれに答えることは長くなる可能性があることを理解して以来、私はここで皆さんに謝りますが、私の質問は、上記の目的を達成するために「プロジェクトエクスプローラ」で作成する必要があるストリームやビューの

私は、CCを使用したリリース管理のベストプラクティスのアプローチと、この目的に最も適した方法を考え出しています。

私はあなたの助けの人たちと事前にすべてに感謝を申し上げ...

Answer 1

親指のルールは単純です：
少ないブランチ、より良いです。あなたは今までに提供し、ClearCaseと前にリベース行われていれば、私は、意味

、あなたが知っている：

• それは、ファイルの数は（1000個のファイルをマージしてスケールする方法不十分
• がいかに苦痛がひどく長いです、5000個のファイルをマージすることは殺人である）

ので、親指の本当のルールは次のとおりです。

あなたがのために任意のファイルを変更する必要がない場合特定の開発段階、ブランチを作成しないでください。

たとえば、QAにコードを昇格させる場合は、コードを読み込み（いくつかのテストを開始します。合格するとそのコードを受け入れるか、失敗した場合にそのコードを拒否します）、コードを配信するQAストリームを作成します。これは存在しない追加値には長すぎます。

使用できる場合はいつでもbaseline promotion levelを使用し、recommend your promoted baselinesを使用してください。

展開エンジニアは常にビルド/展開活動を行うために必要な、彼/彼女のファイルを取得するために、各環境に専用のストリームを使用します。

エラーがありません。変更する必要がない場合は、
デプロイメントエンジニアは、ベースラインがどこから来ているかは気にしません。コードが展開されて正常に実行された場合のみです。