DVCSを使用したリリースサイクルの短縮

CVCSではなくDVCSを使用するという選択は、実際にはリリースサイクルの短縮につながりますか？もしそうなら、何がソフトウェアリリースサイクルをより短くするのですか、そしてこれに対する議論は何ですか？

1. プルリクエストに関連していますか？パッチの簡単な提出がここで役割を果たしますか？
2. 人的要因に関連していますか？CVCSを使用するプロジェクトチームは、リリーススケジュールに対してより保守的に機能しますか？
3. 他の要因はありますか？

CVCSと比較して、DVCSではソフトウェアのリリースサイクルが短くなるのはなぜですか？

ここではDVCSとCVCSに必ずしも違いがあるとは思わないが、人々が従う分岐モデルには違いがある。

私がここで集めたものと私の経験から、DVCSを使用する人々は、CVCSを使用する人々よりも多くのブランチを使用する傾向があります。また、各機能を独自のブランチで開発する場合は、新しい機能Xを含むリリースの準備を開始する方が簡単ですが、開発が開始されたがまだリリースの準備ができていない機能Yは簡単ではありません。

ここの誰もが、DVCSを使用するプロジェクトのリリースサイクルが全体的に短いことに同意しているようですが、DVCSの採用がより短いサイクルを引き起こすかどうかはまだはっきりしていません：相関は因果関係ではありません！

分散VCSと短いリリースサイクルはどちらも比較的新しいテクノロジです。一方を採用するプロジェクトは他方を採用する可能性が高く、実績のあるプロジェクトを好むグループ、またはワークフローが長年確立されているグループは、より保守的で、CVCSを使用し、リリースの頻度は低くなります。

「DVCSを使用すると、短期リリースサイクルモデルがどのように促進されるのですか？」これは、実際のところ、ほとんどの回答が対処していることです。DVCSを使用しても、リリースサイクルが長くなるのを防ぐことはできません。短いものを採用することは選択であり、VCSだけでなく、開発方法論、分岐モデル、コードレビューなどが含まれます。

良い質問！

CVCSは、すべてが「トランク」にマージ/同期し続ける必要があるという主要な原則を信じています。また、リリースされる前に、トランクが最も安定したポイントになることを期待しています。したがって、人々は自分の作業を作業用コピーに入れ、チェックイン前に更新とテストを行います。または、プライベート/機能ブランチで作業してから、他のトランクの変更をマージし、再統合する前にテストします。

DVCSパターンは大幅に異なる場合があります。あなたは分岐し続け、自分自身をフォークします。実験して、最後に意味のあるブランチをマージすることができます。ときどき、すぐにリリースする必要があるセキュリティ修正について聞いたことがあります。そのため、そのパッチもブランチに含めたいが、他の多くのトランクは必要ありません。したがって、デフォルトでは、あなたは自分のスペースで働き続け、物事を取り、統合し続けます-そして、リリースの時が来たら、あなたは誰もが何をドロップするかを決定します。

これを参照してください：http：//nvie.com/posts/a-successful-git-branching-model/

したがって、本質的な違いはこれです。CVCSは、母親が幼い子供たちに言っていることを尋ねます。DVCSは、明示的にマージする必要がある場合（リリースの作成など）を除き、すべての作業が独立した設計であると想定して機能します。

今あなたの質問に来ています-

上記の説明は、実際にあなたが観察/質問したこととは逆に聞こえます。本当の課題は、何が安定しているかを定義することです。ユーザーベースの数が非常に多く、人々がデルタを注ぎ続けているとき-全員が個々のベストに落ち着き、全体の統合と依存関係に問題がなくなるまで、他の並行した変更に関してそれぞれがカウンターブレイクする可能性があります。したがって、リリースを作成しようとしているときは、実際に物事を揺るがし、人々が新しい機能を注ぎ込むのを止める必要があります。これらすべては、CVCSが常に開発の間に「リリース休憩」を取るように要求することを意味します！

コントリビューターの数が多くなると、「リリースブレーク」のこの時点に到達するのは難しく、少なくなります。したがって、CVCSは非常に重要なフェスティバルの後、実際に「リリース作成フェスティバル」を作成することを強制します。

DVCS-あなたは自分のスペースで作業、テスト、作業テストを続けます。リリースの作成と統合は非常に並行したアクティビティであり、どのパッチセットが連携して機能しないか（したがって、リリースから取得または削除されます）を確認することで、試行錯誤する余裕があります。DVCSでは、個々の開発を分離し、それが理にかなっている場合は、たまにリリースをこっそりとすることができます。

CVCSと比較して、DVCSではソフトウェアのリリースサイクルが短くなるのはなぜですか？

主な理由は使用される分岐モデルにありますが、バージョン管理システムのタイプが実行可能な分岐モデルに直接影響を与えることは、バートに同意します。したがって、2つのサブ質問があります。分散システムがサポートする分岐モデルと、リリースサイクルを高速化する理由

集中型と分散型のバージョン管理の根本的な違いは、中央の権限がなければ線形タイムラインを適用できないことです。したがって、分散バージョン管理を可能にするために、これらのシステムは履歴を有向非循環グラフとして定義する必要がありました。各リビジョンには一意の識別子、1つ以上の親リビジョンがあり、気付かないかもしれない多くの子リビジョンが存在する場合があります。それらが作成されたシステムとまだ同期していません。

このアプローチは、分岐に非常に適しています。ブランチを取得するために何もする必要はありません。単にブランチを持っているだけです。そのため、最初にまっすぐに作業を進めて、いつ、どこで、どこに保存し、どの名前でそれをマージするかを決めて、実際に必要な方法であるかどうかを確認できます。

これとは対照的に、すべての集中型システムは、線形の一連の改訂を伴うブランチのセットとして履歴を維持します。したがって、ブランチが必要かどうかを事前に決定し、ブランチに名前を付けて、明示的に作成する必要があります。これは、アイデアの価値がまだわからない場合や、プログラミングを開始する前にそのことを知らない場合に非常に苦痛です。ほとんどの集中システムではブランチ名はグローバルで重要であり、多くの場合永続的で簡単に変更できないという事実により複雑化していますが、すべての主要な分散システムではそれらは気まぐれに変更して自由にリサイクルできるローカルモニカーにすぎません。そして、実際には、CVCSでは通常、すべての分岐操作とマージ操作がかなり遅くなります。

したがって、DVCSを使用すると分岐が容易になるため、DVCSを使用するチームは常に分岐し、CVCSを使用するチームはほとんどの場合それらを回避します。

なぜブランチを使用すると、より頻繁なリリースが可能になるのですか？さて、すべてのチームは時々タスクを過小評価しますが、バグの追跡が困難な場合がしばしばあります。一元化されたシステムを使用するチームは、ブランチが不便なため、通常、トランクですべてのデバッグとほとんどの開発を行います。そのため、ほとんどのバグが解消されるまでリリースできず、開発フェーズとデバッグフェーズをインターリーブする必要があります。

対照的に、すべての作業がブランチで行われる分散システムでは、これらをマージしてテスト、テスト、バグ修正を行い、テストに合格した作業のみを個別にトランクにマージできます。トランクはバグが非常に少ないため、通常は重要な機能が実装されたときに、より頻繁にリリースできます。

また、優先順位に変更がある場合は常に、分散システムで使用される分岐アプローチを使用して、進行中の作業を簡単に保留することができます。ほとんどの実際のプロジェクトでは、優先順位の変更は常に発生します。