DVCSによるリリースサイクルの短縮
CVCSではなくDVCSを使用することを選択すると、実際にはリリースサイクルが短くなりますか？もしそうなら、何がソフトウェアリリースサイクルを短くし、これに対する議論は何ですか？
- プルリクエストに関連しますか？パッチのより簡単な提出はここで役割を果たしますか？
- 人的要因に関連していますか？ CVCSを使用するプロジェクトチームは、リリーススケジュールに対してより保守的に行動しますか？
- 他の要因はありますか？
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のソフトウェアリリースサイクルが短くなる理由は何ですか？
主な理由は使用される分岐モデルであるというBartに同意しますが、バージョン管理システムのタイプは、実行可能な分岐モデルに直接影響します。したがって、2つのサブ質問があります。分散システムがより適切にサポートする分岐モデルと、それがリリースサイクルを高速化する理由は何ですか？
集中型バージョン管理と分散型バージョン管理の基本的な違いは、中央の権限がないと線形タイムラインを適用できないことです。したがって、分散バージョン管理を可能にするために、これらのシステムは必然的に履歴を有向非巡回グラフとして定義する必要がありました。各リビジョンには一意の識別子、1つ以上の親リビジョンがあり、気付かないかもしれない任意の数の子リビジョンがある可能性があります。それらが作成されたシステムとまだ同期していません。
このアプローチは、分岐に非常に適していることがわかりました。ブランチを取得するために何もする必要はありません。常にブランチを持っているだけです。そのため、最初に真っ向から作業に取り掛かり、いつどこでマージするか、どこに保持するか、どの名前で保持するかは、実際に必要な方法で実行されているかどうかがわかるまで決定する必要があります。
対照的に、すべての集中型システムは、リビジョンの線形シーケンスを持つブランチのセットとして履歴を維持します。したがって、ブランチが必要かどうかを事前に決定し、名前を付けて明示的に作成する必要があります。これは、アイデアの価値がまだわからず、プログラミングを開始する前にそれを知らないことが多い場合、非常に苦痛です。ほとんどの集中型システムでは、ブランチ名はグローバルで重要であり、永続的であり、簡単に変更できないという事実によって複雑になりますが、すべての主要な分散システムでは、気まぐれに変更して自由にリサイクルできるローカルモニカにすぎません。実際、CVCSでは通常、すべての分岐およびマージ操作がかなり遅くなります。
したがって、DVCSを使用するとブランチが簡単になり、DVCSブランチを使用するチームは常にブランチを使用できますが、CVCSを使用するチームはほとんどの場合ブランチを回避します。
では、なぜブランチを使用すると、より頻繁にリリースできるのでしょうか。さて、すべてのチームは時々タスクを過小評価するでしょう、しばしばバグを追跡するのが難しいときが現れます。ブランチは不便であるため、集中型システムを使用するチームは通常、トランク上ですべてのデバッグとほとんどの開発を行います。そのため、ほとんどのバグをフラッシュするまでリリースできず、開発フェーズとデバッグフェーズをインターリーブする必要があります。
対照的に、すべての作業がブランチで行われる分散システムでは、これらをマージしてテスト、テスト、バグ修正を行い、テストに合格した作業のみを個別にトランクにマージできます。その結果、バグがほとんどないため、通常は重要な機能がリリースされるたびに、より頻繁にリリースされる可能性のあるトランクが作成されます。
また、優先順位に変更があった場合はいつでも、分散システムで使用される分岐アプローチを使用して、進行中の作業を簡単に棚上げできるようになります。ほとんどの実際のプロジェクトでは、優先順位の変更は常に発生します。