DVCSは継続的な統合を妨げますか？

10人のアジャイル開発者のチームがあるとします。毎日、彼らはボードからタスクを選び、そのタスクに対していくつかの変更をコミットします（1日の終わりまでに）。すべての開発者は、トランクに対して直接チェックインします（Googleスタイル、すべてのコミットはリリース候補であり、機能の切り替えなどを使用します）。

SVNのような集中型CVSを使用している場合、1人がコミットするたびに、ビルドサーバーは変更を統合し、他の9人の開発者の作業に対してテストします。ビルドサーバーはほぼ1日中継続的に実行されます。

しかし、gitのようなDCVSを使用している場合、開発者はタスクを完了するまで待ってから、ローカルコミットをすべて中央リポジトリにプッシュすることができます。それらの変更は、一日の終わりまで統合されません。

このシナリオでは、SVNチームはより頻繁に継続的に統合し、gitチームよりもはるかに迅速に統合の問題を発見しています。

これは、DVCSが従来の集中型ツールよりも継続的なチームに適していないということですか？この遅延プッシュの問題をどのように回避しますか？

免責事項：私はアトラシアンで働いています

開発者が定期的にリモートで自分のブランチにプッシュし、CIサーバーが既知のアクティブなブランチを構築するようにセットアップされている限り、DVCSは継続的統合を妨げません。

従来、DVCSとCIには2つの問題があります。

• 統合状態の不確実性 -開発者が定期的にmasterからマージしてビルドを実行していない限り、変更の組み合わせの状態はわかりません。開発者がこれを手動で行う必要がある場合、問題を早期に発見するのに十分な頻度で行われない可能性があります。
• ビルド構成の複製とドリフト -ビルド構成を「マスター」ビルドからコピーしてブランチビルドを作成する必要がある場合、ブランチの構成はコピー元のビルドとすぐに同期しなくなる可能性があります。

Bambooでは、開発者が作成した新しいブランチをビルドサーバーが検出し、マスターのビルド構成に基づいてブランチのビルドを自動的にセットアップする機能を導入しました（したがって、マスタービルド構成を変更すると、ブランチ構成も変更されます変更を反映するため）。

また、Merge Strategiesという機能があり、ブランチビルドが実行される前にマスターからの変更でブランチを更新するか、成功したビルドブランチの変更をマスターに自動的にプッシュして、ブランチ間の変更ができるだけ早くテストされるようにすることができます。

とにかく、あなたがもっと学ぶことに興味があるなら、私のブログ記事「継続的な統合で機能ブランチを効果的にする」を参照してください

私の小さなチームは1年か2年前にDVCSに乗り換え、数ヶ月前に私の会社の残りがそれに続きました。私の経験では：

• 集中型VCSを使用している人々は、大規模なプロジェクトを行っているときでも、コミットを保留する傾向があります。これはDVCSに固有の問題ではありません。コミットを行う前に数日待つ変更セットがあります。大きな違いは、この期間中にある時点でミスをした場合、またはコンピューターがクラッシュした場合、修正に多大な労力が必要になることです。
• 各開発者が独自の名前付きブランチで作業するコミットワークフローを使用し、コードを確認した人のみが変更をヘッドにマージできます。これにより、コミットが問題を引き起こす可能性が低くなるため、ビルドサーバーがエラーメッセージを生成する場合、人々は本当に注意を払います。また、他の開発者は、頭が固定されるまで自分のブランチで作業を続けることができます。
• DVCSでは、人々はコードを頭にマージする前にプログラミングにより多くの時間を費やす傾向があります。そのため、ビルドの継続性に少し遅れが生じる傾向があります。しかし、その違いはDVCSの利点に対抗するには十分ではありません。

私は最近、Mercurial over SubVersionを使用した約19のプロジェクト（私はSubversionオタクでした）を観察しました。これは、深刻な統合のトラブルと懸念を引き起こしました。

私たちが直面した別の問題は、継続的統合サーバーにあります。コミットの同期がサーバーに対して行われた場合にのみ、問題（たとえばテストの失敗）が通知されました。

マーティン・ファウラーは彼のサイトでそれについて書いたようです。

そうは言っても、私が言及したプロジェクトのいくつかは、少なくとも1日に1回同期を行って問題を減らしました。したがって、あなたの質問に答えるために、DVCS は継続的な統合を妨げ、個人主義を高めるかもしれないと思います。ただし、DVCSは直接的な原因ではありません。

開発者は、使用するVCSに関係なく引き続き担当します。

推論の基礎となるアイデアは、非常に不安定で、穏やかに言えます。開発者がタスクを完了するまで待つのは、チーム/管理/プロセスの問題です。

それを一つの方法または別のをやって、「待機」または「急いで」、共有トランクまたは単離された枝は、として知られている戦略を分岐し、あなたがあれば、オンラインで入手可能な情報を勉強、あなたは特定の戦略を選択すると、基本的には何の関係もないことがわかります集中または分散されているVCS。

Mercurialのような分散VCSの場合、頻繁なマージの強力な推奨事項を簡単に見つけることができます。

まず、頻繁にマージします！これにより、誰にとってもマージが容易になり、競合（多くの場合、互換性のない設計決定に根ざしている）がわかります...

上記のような推奨事項を検討すると、配布されているMercurialとは関係のない考慮事項に対するこれらのアピールが簡単にわかります。

ここで、集中型VSCであるSubversionの状況を見てみましょう。オンライン情報を調べると、安定したトランクと不安定なトランクと呼ばれる人気の高い戦略の中から見つけることができます。それぞれがマージの頻度に反対の影響を及ぼします。ご覧のとおり、人々はVCSが一元化されていることにも注意を払うことなく、物事を行う方法を選択します。

• ^{一元化されたVCSでマージが大幅に遅延する（不完全な管理で促進される）のを見ました。また、チーム/管理者が正しい方法だと考えたときにDVCSで頻繁にマージされていました。VCSが分散されているか集中化されているかどうかを気にする人はいないと思います。}

上記のように、DVCSは継続的な統合を妨げていますか？だろうムー。

VCSが配布されているかどうかは、それに大きな影響を与えません。

私の経験は正反対です .svnを使用しているチームは数日間プッシュしませんでした。なぜなら、作業していたコードが手動のマージに時間を費やさずにトランクを他の人のためにコンパイルしないためです そして、スプリントの終わり近くに、誰​​もがコミットし、狂気の融合が起こり、物事は上書きされて失われ、回復されなければなりません。CIシステムは赤になり、指を指すようになります。

Git / Gitoriousでこの問題が発生したことはありません。

Gitを使用すると、他の人が何かをチェックしてチェックインしたいので、他の人の変更を都合の良いときにプルしてマージできますが、手動でマージする時間は20分です。

また、Gitを使用すると、他のすべてのコミットをプルし、コードをマージしてから、作業バージョンを他のすべてのユーザーにプッシュできるため、変更内容に基づいてマージする必要があるものを推測する必要がありません。

マージリクエストを介したコードレビューの仲介者としてGitoriousのようなものがあれば、多くのブランチと多くの貢献者の管理が非常に簡単になります。

Gitリポジトリ内のすべてのアクティブなブランチを追跡するためのJenkins / Hudsonのセットアップも非常に簡単です。SVNからGitに移行したとき、CIの牽引力が高まり、リポジトリの状態に関するフィードバックが頻繁に寄せられました。

ビルドサーバーは安価です。CIサーバーに、知っているすべてのブランチを選択させるだけです。

Jenkinsは、複数のgitリポジトリをチェックし、1つのジョブでそれらのいずれかから「最新」を取得することをサポートしています。他のツールにも同様のソリューションがあると確信しています。

この古い質問は新しい質問の複製としてマークされたばかりで、多くの回答が時代遅れのアイデアを参照しているので、更新されたものを投稿すると思いました。

5年前にはあまり一般的ではなかったように思われることの1つは、プルリクエストブランチをマスターにマージする前にプルテストブランチでCIテストを実行することでした。私は、これはマージが頻繁に望ましいが、共有することを姿勢変更を反映だと思うあらゆる変化皆を、できるだけ早くあなたがそれを作るとして、最適ではありません。

DVCSは、コミットを統合するより階層的なモードを生み出しました。たとえば、私はしばしば隣に座っている開発者と非常に密接に仕事に取り組んでいます。1日に数回、互いのブランチからプルします。今日、私たちは数時間ごとにプルリクエストにプッシュされる変更を介して他の開発者と協力しました。

ビルドスクリプトに大幅な変更を加えていました。JenkinsはすべてのPRブランチをマスターとローカルにマージし、テストを実行します。そのため、クリーンビルドを必要とする他の開発者を邪魔することなく、自動化されたフィードバックを得ました。PRが3人の開発者からなるグループの外でマスターと共有する準備が整うまでには、おそらく1日ほどかかるでしょう。

ただし、変更がマスターにマージされるのを待てない場合、変更は私たちの変更に依存するため、開発ブランチをローカルにマージして作業を続行できます。これは、CVCSに慣れている多くの人が見落としているものです。CVCS を使用する場合、変更を共有する唯一の方法は、変更を中央リポジトリにマージすることです。そのため、マージがより重要になることがよくあります。DVCSには、他のオプションがあります。

DVCSは継続的インテグレーションの助けになると思います。マージはそれらを刺激するものではありません。ただし、さらに規律が必要です。ローカルコミットの後にベースからプルしてマージし、タスクが完了したら（次のタスクに進む前に）プッシュする必要があります。

私のチームがGitに切り替えたとき、プッシュが古いVCSのコミットとまったく同じように扱われるようにプロセスを明示的にレイアウトし、ローカルコミットは各個人が選択した頻度/頻度で実行できるようにしました。それにより、DVCSを使用しているか集中型VCSを使用しているかにかかわらず、CIシステムに違いはありません。

答えは「はい」と「いいえ」の両方です。

ここでの違いは、中央のCI表示リポジトリに直接コミットすることと、変更を中央のCI表示リポジトリにプッシュすることです。あなたが見つけるかもしれない「問題」は、DVCSユーザーが実際にそのプッシュを定期的に実行しないかもしれないということです。

これはDVCSに固有の設計機能であり、変更を常に中央サーバーにプッシュするように設計されているわけではありません。そのため、答えは開発者の間でより良いワークフローを実施することです。毎晩変更をプッシュするように伝えます。シンプル！

（また、SVNユーザーが毎晩コミットしていない場合は、まったく同じ問題を伝えてください）。

Gitは継続的な統合を妨げません。トランクベースのワークフローはそうです。

それは直感に反するように聞こえるかもしれませんが、開発者が機能ブランチで作業する場合、自分のマシンに頻繁に統合することを奨励できます（そして、マージのために機能を送信する前にそうする必要があります）。対照的に、トランクベースのワークフローはより大きなコミットを優先するため、統合の頻度は少なくなります。

Googleスタイルのトランクベースのワークフローは、マージが簡単なGitなどのVCSでは逆効果になると考えています。代わりに私がアドバイスしたいことは次のとおりです。

• 機能を十分に小さく分解して、開発に1〜2日以上かかることはありません。
• 各機能はプライベートブランチで開発されています。
• 開発者はプライベートブランチに頻繁に統合しgit fetch origin; git merge masterます（）。この方法で作業するとき、私は通常これを1日に何度も行います。
• 開発者がマージとレビューのためにブランチを送信すると、CIサーバーは自動ビルドを実行します。マージは、これが成功した場合にのみ発生します。

つまり、小さなコミット、頻繁な統合、およびどのコミットがどの機能に属していたかの追跡可能な履歴です。適切に使用されるブランチは、Gitにとって価値のあるすべての鍵であるため、ブランチを避けることは大きな間違いです。

@jdunayのような素晴らしい技術的解決策がありますが、私たちにとっては人々の問題です。同じように、人々がsvnにコミットする環境を育むことは人々の問題です。

私たちのために働いているのは：（「master」を現在アクティブなdevブランチに置き換えてください）

1. マスターからの頻繁なマージ/リベース
2. マスターへの頻繁な十分なプッシュ

3. 特定のリファクタリングなど、マージ地獄の原因となるものを認識し、通信することでこれを緩和します。例えば：

   • 全員がランチの前にプッシュするようにしてください
   • 昼食時にリファクタリングを実行してプッシュする
   • 全員が昼食後に引っ張ることを確認してください