オープンソースツールを使用して複雑なステージ環境を構築する

Question

私は一連のチューブをしばらく検索しましたが、通常、この質問に対する良い答えは何も見つかりませんでした。ユースケースは非常に細かく扱われるようになっています。この質問の例：Create a "label" in subversion indicating what files should be in the next release（5つの投票の回答は近いと思われるが、それほどではない）とこの質問：Using Subversion Tags to Deploy to Development/Staging/Testing Serverは、回答しようとする人を除いて、微妙なことを完全に理解していないようだ。

私は、急速に成長するプロジェクトのためのより洗練されたステージング環境を構築しています。現在の環境は、メインのプロダクションブランチとビルドブランチで構成されています。ビルドブランチのヘッドリビジョンに「完了」したものをタグ付けし、それを本番環境にマージするだけで、ビルドは問題にはなりません。より微妙な部分は、ラベル付きの各ファイルの任意のリビジョンで任意のファイルセットにタグを付け、そのラベルをステージングサーバーに同期できる自動プロセスをセットアップすることができます。今ではSCMの世界のラベルがオーバーロードされているので、このケースでは、PERFORCE（http://www.perforce.com/perforce/doc.current/manuals/cmdref/label.html）の意味でのラベルを使用しています。その意味は、ファイルが任意に選択されたリビジョンにあるファイルセットの名前を意味し、変更可能です。

私はファイルAとBを持っていると仮定します。ファイルAのヘッドリビジョンはそのファイルのリビジョン13であり、ファイルBのヘッドリビジョンはリビジョン4です。現在、A10とB2 。ファイルAへの変更はQAdであり、パッチ適用の準備ができていると判断されました。ファイルB（リビジョン3）への最初の変更はパッチ適用の準備が整っていますが、ビジネス側はヘッド変更（リビジョン4）を少しでも処理する必要があると判断したので、パッチしてはならず、 。したがって、プロダクションにパッチを当てるには、リリースのためにB @ 3とA @ 13にタグを付ける必要があります。だから、誰もが "オハイオ州のよく使うタグ"を言うところです。だから、20110703の夜間パッチにはうってつけです。しかし、舞台環境では、「今のところブランチにタグを付けるかどうかは、これがどのように見えるのか」という状態では、必須ではないヘッドリビジョンファイルをテストできるようにしたい1日を通して（週、月など）。私は間違ってはいけません。私は、プロダクションブランチでたくさんのコーディングをしたくありませんが、時には必要です。

私がこれまでに書いたポイントの1つは、コミットがタスク/チケットに関連付けられ、タスク/チケットが特定のリリース日に関連するチケット発行システムもあるということです。したがって、ワークフローは、ユーザーがタスクを作成し、チェンジセットの形式でコードを1つのタスクと複数のチェンジセットの関係で付加し、タスクが承認プロセスを経て、最終的にはパッチ。次に、X日にどのファイルリビジョンがパッチアウトされるかを判断し、ステージング環境（または本番環境）を適切なバージョンのファイルに同期させる一連の自動スクリプトがあります。私が問題を抱えている特定のスクリプトは、一連のタスクが与えられ、それらのチェンジセットを通じて、パッチを適用する準備が整ったものです。ファイルセットを適切なリビジョンに同期させて、将来のプロダクションパッチをエミュレートします。のように見える。私がPERFORCEを使用する場合は、変更可能なラベルでこれを達成することができ、基本的にはユーザーが同期できる（ファイル名、ファイルリビジョン）値のコレクションを保持します。しかし、私はオープンソースのツール、特にRedmineと統合されたツールを使用しようとしています（もちろん、チケットとチェンジセットの関連付けレイヤーを構築する必要があります）。

私の質問はそうです。

1. ラベルの概念を持つオープンソースのSCMはありますか？私は水銀とキューの拡張を少し見てきましたが、もう一度同様の問題を解決するようですが、まったく同じ問題ではありません。 （私を修正して、「これはまったくこれを完璧に解決してくれません...」）
2. この方法で正確に動作するツールがない場合は、これを最もうまく設定するための提案はありますか？私は間違いなくラベルを作成し、個々のファイルを手動で同期させるスクリプトを書くことができますが、それは非常に多くの点で悪いと思われます。

基本的に私がやりたいことは、数日外に移動したり、パッチのない状態からパッチ可能な状態に移行して、コードの状態に影響を与えるような行動を可能にすることですステージングサーバーは、タスクが変更された後に人間の介入なしに「これは私たちがパッチ適用を計画しているもの」状態にします。

ありがとうございました。

Answer 1

[この答えは、上記のコメントでの議論を要約しようとします。]

近代DVCS（例えばGitの、Mercurialは）むしろファイルのセットよりもコミットのシーケンスなどの変更を管理します。この異なるパラダイムの場合、特定のリビジョンの特定のファイルを選択する「ラベル」を考えるのは難しいからです。コミットはいくつかのファイルに触れるかもしれませんし、コミットは与えられたファイルに触れることができます（ファイル内の変更は重複するかもしれません）。あなたは何ができるか、Gitのを使用して段階的なリリースを管理するには

は次のとおりです。

1. は、以前のリリースブランチをつかみます。
2. 各ブランチまたはチェリーを引っ張ってください。次のステージングテストの対象となる各コミットを選択します（これは開発ワークステーションで行うことができます）。
3. ステージングリポジトリにプッシュします。
4. これをステージングサーバーにプルします。
5. ステージングが正常にチェックアウトされたら、同じブランチを本番環境に引き出します。あなたははしたくない変更がない場合、ステップ2は、シングルステップマージなり（たぶん）一般的な場合には

。特定の変更を望まない場合は、変更をチェリーピックアップしてを実行してください。が必要です。

いくつかの有用なリソース：

• Pro Git - Gitの
• A successful Git branching model上の無料の本 - Gitの