ペンディングヘッド

私は継続的インテグレーションの大ファンです。ほとんどの開発チームに大きな違いをもたらす、比較的単純なプラクティスです。ただし、ほとんどのプラクティスと同じように、改善の欠陥^H^H^H^H^H機会があります。ポール・デュヴァルは、この件に関するすぐに標準となる書籍の著者で、最近指摘しましたこれらの一つ。コミットビルドが停止すると、チーム全体に影響があり、修正されるまで潜在的に速度が遅くなります。

ThoughtworksでContinuous Integrationを最初に始めたとき、これは私たちが行っていた方法について私が心配していたことの一つでした。Thoughtworksの2000スタイルとC3で使用していたスタイルには重要な違いがあったため、私は心配していました。

Thoughtworks 2000スタイルは、今日使用されているCIの標準的なスタイルです。作業に満足したら、リポジトリにコミットしてから、ビルドマシン（手動または、CruiseControlなどのCIサーバーを使用）でビルドします。問題は、コミットが失敗した場合、修正するまで更新した人に失敗したコードが表示されることです。

C3のやり方では、リポジトリのヘッドに直接コミットしませんでした。C3はSmalltalkプロジェクトで、Smalltalk指向リポジトリシステムであるEnvyを使用しました。Envyには従来のリポジトリとは異なるコンセプトがありました。使用してから何年も経つので、正確にそれがどのように機能したのかという私の記憶は曖昧ですが、基本的な考え方は、機能に取り組んでいるときは、エディションにコミットします。エディションは、プライベートブランチに似ていますが、全員に表示されますが、祝福されていません。ビルドマシンで正常にビルドされた場合のみ、エディションをリリースにアップグレードします。これはメインラインに相当します。このように、プロジェクトのメインラインに壊れたコードは入りません。

Envyは、このような作業を容易にしました。現在、私たちが主に使用しているバージョン管理システムは、それをよりトリッキーにします。理想的には、真のヘッドから更新する作業用コピーを作成して同期を維持しますが、別の保留中のヘッドブランチにコミットします。実際のプロジェクトヘッドにコミットできるのは、インテグレーションビルドが成功した場合のみです。継続的インテグレーションサーバーは保留中のヘッドからチェックアウトし、成功した場合は本当のヘッドにコミットします。

自分でこのようなものを設定するのはどれくらい難しいですか？私は確信が持てません。私はそれを行ったチームと話をしていません。しかし、チーム指向のツールの中には、この種の機能を提供するものがあります。たとえば、JetBrainsのTeamCityは「遅延コミット」という名前で行います。ポールは、ボーランドのガントレットについても言及しています。

もう一つの疑問は、どれだけ影響があるかということだ。どれほど心配しても、壊れたビルドに十分なダメージを受けることがなく、2000 年に保留中のヘッドをインストールしたくはならないだろう。壊れたインテグレーションビルドが大量にある場合は、別の方法で修正する方法がある。大抵の場合、主な問題は、コミットする前にプライベートビルドを行っていないことだ。いつものように、より複雑なテクノロジーを導入する前に、人間の問題に対処することが最も重要な課題となることが多い。