ブランチ戦略 - 継続的な展開と統合の分離？

Question

私はDevops部門のソフトウェア開発者です。経験豊かな人たちの助けを借りて、これは長くては説明でき、面白いです。私と一緒に裸にしてください。 私はTFSとRMを使って、過去2.5年（rm 13でも）のビルドとリリースを作成しています。

最近私は、私たちの会社にブランチング戦略のための「品質によるブランチング」パターンを埋め込もうとしました。 私たちはホットフィックスマージ、スプリントマージ、バグ修正マージを開発プロセスに必要とします。

生産の前にテスト環境にホットフィックスをアップロードすると、現在テストしているすべての新機能が、私たちが望む小さな緊急ホットフィックスと混在することに同意できます。コードは汚れています。私たちはこのパターンに遭遇しました。私はこのパターンに遭遇したときに、各ブランチ（メインの\ dev、test、 prod）が適切な環境に向かい、支店が安定しており、私の部署（devops）からメンテナンスの手間がかかりませんでした。私たちは、自動化したいもっと多くのアプリケーションのために、これらのブランチにもっと多くのビルドとリリースを追加します。

当社に相談し、スクラムを促進している外部のコンサルタント会社は、別のことを念頭に置いています。私はまだその動機を理解することができないので、誰かが私のケースで私またはコンサルタントが提供するもの（競争ではなく、私の会社の実生活に解決策を付けること）を助けるか矛盾するかもしれません。別の参照が続く Branching strategies with TFVC

： は、彼は次のURLを送信し

要するにEffective TFVC branching strategies for DevOps

- 私たちはv1.0と私たちのリリースパイプライン（CIのCD）を作成すること、それが提供されていますこれは常に変更され、各リリースでパイプラインが変更されます（v2.0 , v50.0など）。

フィーチャーブランチストラテジーが継続的インテグレーションではうまく機能していないと言っていました - 明確なリリースアイソレーション は、新しいブランチになるように各リリースを提案しています。リリースはメインブランチにマージするのに最も多くの2-3週間続くでしょう。 どのように自動化できるか、ホットフィックスオートメーションをサポートする方法はわかりません（前のブランチを修正する は、そのブランチで作業するようにすべてのビルドを変更します）。

リリース管理でTFS 2015を使用して、継続的な統合ビルドを実行し、私たちのすべてのコードがWindows上の.Netにリリースされました。したがって、継続的な統合に使用されるブランチがあり、トリガーがあります。私は私の会社でサービスのビルドとリリースが30以上（および増加）しており、200を超えるアプリがあり、私たちは最も緊急なものを自動化し、ますます自動化に努めています。

私は（コンサルタントがそれらを共有する）の上に追加のリンクで提供されるソリューションは、リリースパイプライン を作成することで新しいリリースがTFSであり、ビルドしていること（2〜3週間毎スクラムでの作業） 心があるたびに（ソースとトリガ）を構築する必要があるブランチへの特定の参照です。つまり、ソースとトリガ内のすべてのブランチ名とメインsln \ csprojをリリースブランチの名前（たとえばr12）に変更する必要があります。 ）。 これはプロジェクトごとに異なります。そのため、すべてが同じリリースブランチ名（例：r5 \ r20）を持つわけではないため、異なるアプリケーションのビルドのブランチ名を自動的に上書きすることはできません。

戦略を分岐のこのタイプは、DevOpsチーム&連続配信のためtfvcをサポートしているかのようにそれが書かれているが、すべて私達の自動化されたアプリケーションの各リリースのリリースブランチ名を変更周りに実行するために、ハード冗長な作業のように思える... これがそうです不必要な仕事のひどいたくさんのように、大きなobviouseの利点のために - 私にもちろん。 コンサルタントは、彼のソリューションがはるかに優れていると確信していましたが、同じ記事で「Continuous」という言葉を使用している間にVisual Studio Webサイトでこのソリューションが表示されます。 さらに、私たちの部門は、私たちの手には他にもたくさんのものがあり、私が見ていないものを誰にでも見せてくれるのですか？トリガーは2015ビルドTFSで複製可能ではありません

注：

これは、我々は各リリースで行う必要がある変更処理です。

この問題の解決策（でも理論的には、それは大丈夫です）証明-に-仕事、私はエレガントな、ない-ハックをリクエストしてくださいしたいことを覚え、それが意味している場合、我々は、コードを持っていてください回避策は、私の経験から、失敗のポイントとメンテナンスの追加と見なされます。

ありがとうございます！

Answer 1

あなたの質問はあまりにもボードであり、多分少し主観的です。どのプロジェクトにも共通して合意された「最良の」分岐戦略はありません ほとんどのリソースは、生産的な戦略を選択することがの特定のプロジェクトの詳細 サイドノートに依存しているようです。

これによれば、プロジェクトブランチング戦略の変更はすべてである必要があります。テストされ、測定され、テストされた他のオプションと比較されます。

あなたは最初の解決策でどのようにリリースを処理するかについてはっきり言及していませんでした。プロダクションリリースがトランク/メインまたはブランチから発生するかどうか。 Googleでの他のほとんどの経験によると：トランクから

行うPRODリリースは、本質的に不安定な トランク戦略を使用することを禁止されています。ブランチからプロダクトをリリースしているチームには、 より多くの分岐オプションがあります。

さらに、ホットフィックスについては、コンサルタントが自動的に共有します。通常、機能の完了時にはリリースブランチを作成し、このコードラインで直近の問題を修正する予定です。上のチュートリアルとスクリーンショットのように、すでにリリースされたコードのバグ修正を作成する必要がある場合、プロセスがリリースから分岐するように見えます。この場合、前のすべてのブランチを修正する必要はありません。