継続的インテグレーションシステムのベビーシッター

私のチームにおける私の役割の1つはビルドパーソンです。私は、ビルドスクリプトを維持/更新し、継続的インテグレーションサーバー上で「スムーズに」ビルドすることを確認する責任があります。私は通常、この仕事を気にしませんが、CIサーバーを常にベビーシッターしているように感じることがよくあります。

ビルドが中断した場合、作業中のストーリーを削除し、ビルドの失敗を調査する必要があるため、このジョブは時々面倒な場合があります。ビルドの失敗はチームで毎日発生します。開発者は、コミットする前にローカルでビルドしない場合があるため、CIサーバーでのテストは失敗します。この状況では、ビルドがあまりにも長く壊れないように、「悪いコミット」をした人にすぐに連絡を取りたいです。CIサーバーに、デバッグする必要のある奇妙な状態が時々（はるかに少ない頻度で）存在します。

多くの成熟したチームが継続的インテグレーションを使用していることは知っていますが、優れたプラクティスに関する資料はあまりありません。

私の問題は、継続的インテグレーションがあまり成熟していない、またはこれが単なる仕事の一部であると指摘していますか？

従うべきいくつかの良い習慣は何ですか？成熟した継続的インテグレーションの特徴は何ですか？

更新

いくつかのコメントに答える代わりに、代わりに更新を行います。アプリをビルドするときにビルドサーバーが実行することを正確に実行する単一のシンプルなコマンドがあります。コンパイル、すべてのユニット/統合、およびいくつかのクイックUIベースのテストを実行します。

みんなの答えを読んで、2つの大きな問題があるかもしれないと感じています。

1. ビルドが失敗したときにCIサーバーが十分に不平を言っていない。
2. 開発者は、コミットが正常に実行されることを確認する責任を全員に負わないと感じています。

私のチームで物事を難しくしているのは、大規模なチーム（10人以上の開発者）がいて、仕事をしていないときでも、数人のオフショアチームメンバーがコミットしていることです。チームが大規模であり、頻繁な小さなコミットが好ましいことを確立したため、1日で実際に多くのアクティビティを行うことがあります。

何よりもまず、各人がビルドプロセスを担当します。あなたのチームのメンバーは成熟していないように思えます...コードを書いて、それが機能することを望んでCIサーバーにそれを奪うことでだれも逃げません。コードをコミットする前に、ローカルマシンでテストする必要があります。あなたはする必要があることを確認あなたがチェックしているコードは、ビルドを破るつもりはないされていること。もちろん、ビルドが意図せずに中断する場合もあります（たとえば、構成ファイルが変更された場合や、誤ったコミットが誤って行われた場合）。

ほとんどのCIサーバー（私はHudsonのみを使用しました）は、ビルドを中断させたコミットの詳細を記載した自動メールを送信します。あなたの役割の唯一の部分は、容疑者が彼らが破ったものを何でも修正するまで、彼らの後ろに立つことです。

あなたのチームは一つ間違ったことをしました：

ビルドを担当するサーバのことは責任であることと同じではありませんビルド。

コードをチェックインする人の責任は、それを「仕事」にすることです（仕事の価値のために）。ビルドサーバーを持つ唯一の理由は、このプロセスの見落としを見つけることです。その価値のあるビルドサーバーは、最後のビルド以降にコードをチェックインした人（および関心のある他の人）に次の情報を通知できます。

• ビルドが壊れました！
• 構築時に何がうまくいかなかったのか！
• 前回のビルドから何が変わったのですか！

これはメールで頻繁に発生します。これは、各チェックイン後に非常に迅速に行われることが重要です。

その後、その人は何が間違っていたかを確認して修正し、ビルドサーバーはビルドが正常に戻ったことを関心のある人に通知します。これは、チェックイン犯人以外の人が関与することなく、単独で発生するはずです。

したがって、あなたの質問に答えるために：成熟したCI環境では、管理者が通常の操作に関与する必要はありません。

また、「奇妙な条件が存在する」ことが非常に頻繁に発生する場合は、その原因を特定し、システムをより堅牢にします。

プロセスを変更します。コミットがビルドを壊した場合、そのコミットを自動的にロールバックし、それを壊した開発者に通知します。1人のチームメンバーによるエラーがチームの残りの部分の速度を落とすことは許されません。または、自動的に統合ビルドを行う代わりに、開発者に統合マシンをチェックアウトしてもらい、ビルドが成功した場合、コミットすることができます。継続的インテグレーションは、「好きなジャンクをチェックインすれば、誰かがそれを修正してくれる」という意味ではありません。

「ゴールデンブランチ」戦略は、ゴールデンブランチのゲートキーパーがいないと機能しません。

GitのようなDVCSが役立つかもしれません。開発者はコミットする代わりに、CIサーバーに統合するために変更セットを送信するだけで、サーバーは変更セットの統合を試みることができます。統合が成功した場合、変更セットはマージされ、そうでない場合は拒否されます。

私がよく目にする問題の1つは、開発者がCIビルドとまったく同じステップを持つローカルビルドを実行できないことです。つまり、CIサーバーは、ローカルで実行できないユニット/統合テスト、カバレッジなどの追加のステップを含むように構成されています。必然的に、開発者はローカルで実行できない手順の1つに噛まれ、チェックインする前にリリースをローカルに構築することになぜ悩まされるのか疑問に思うようになります。

ビルド全体を自己完結型で維持し、無関係な構成/手順を定義せずに、CIサーバーにリリースビルドを開始させます。開発者は、チェックインの前にリリースビルドをローカルで実行できます。これには、CIビルドによって実行されるすべてのステップが含まれ、チェックイン時に何も壊れないことをはるかに確信できます。

このアプローチに追加された利点は次のとおりです。

• 余分な手順を設定するために多くの時間を費やしていないため、CIサーバーを簡単に切り替えることができます。
• すべてのビルド時ツールはソース管理下にあります。つまり、すべての開発者はまったく同じツールセットを使用してシステムを構築します。
• 上記の点に加えて、制御された方法でビルドツールを変更するのは簡単です

PS。ビルドベビーシッターのコンセプト全体はばかげていますが、他の人がそれをカバーしています。

まず、開発者は定期的にビルドを壊すべきではありません-CIブランチにコミットする前に、テストをローカルでビルドして実行する必要があります。ビルドを壊すのは恥ずべきことであり、それを強制することは重要です。私は統計を投稿することでそれをやったし、他のチームがビルドを壊すたびにあなたがドルを入れる「ビルドバッグ」を持っているのを見た。プロジェクトの終わりに、お金はビールに行きます。

恥や個人的なプライドが機能しない場合は、より重いものに移動する必要があります（たとえば、終了を脅かす）。その日出発する前にビルドを壊すことは大きな罪になるはずです。また、すべての開発者は、デスクトップにビルドステータス通知を持っている必要があります。このすべての最も良い部分は、より小さなコミットを奨励することです。

とはいえ、ビルドが壊れることがあります（CI構成の理由など）。そして時々、人々は台無しになり、ビルドが壊れたままその日を去ります。そのため、既知の正常なバージョンへの迅速かつ簡単なロールバックを可能にするプロセスを目指すべきです。常に最後の正常なビルドにロールバックできる（そしてロールバックされたバージョンをすべての必要な場所にデプロイできる）場合、原因が夜に残された破損したビルドの最悪のシナリオ最後の良いバージョンに戻り、午前中に彼/彼女に怒鳴ります。

連続配信の本を十分に推奨することはできません。CIプロセスを成熟させる方法についてのガイドを探している場合は、試してみてください。

マイクロソフト（おそらく？）が行うことについて聞いたことがあります。これは、チーム内でベビーシッターを構築する役割を持つことです。これを行う方法は、誰かがビルド（おそらくテストに失敗したものをチェックインすることを含む）を中断したときに、その役割を引き受けることです。これにより、人々は非常に直接的に自分の行動の結果に責任を負います。そして、それがやや面倒な仕事であることを考えると、彼らは再びビルドを壊さないように奨励しています。

現在ビルドの責任者は特別な帽子を持っている可能性があります。それを渡すための式典があるかもしれません。

Thorbjørnが言うように、ビルドを担当することはビルドサーバーを担当することと同じではないことに注意してください。サーバーの責任は、チームの1人以上のインフラストラクチャに傾倒したメンバーに永続的に委ねられ、ビルドの責任は動き回ります。

さて、プロセスの詳細はさておき、私はビルドとテストを実行せずにチェックインする開発者に失望を表明する人々のコーラスに参加します。受け入れられない！

ビルドを破る可能性が高いチームのメンバーがいる場合（そして、私自身の経験に基づいて、私は主に別の国のメンバーを考えています）、そしてMercurialのような素晴らしい現代のソース管理を使用している場合またはGitを使用すると、チームの残りの別のブランチにチェックインし、その上で個別のCIプロセスを実行し、ビルドが成功した後にそのブランチからトランクに変更を自動的にマージすることができます（注意する必要がありますマージをチェックインする前に、マージ後に2回目のビルドとテストを実行してください！）。ただし、自動マージが常に成功するとは限らないため、最終的にはブランチが手動での注意を必要とすることになり、これは大きな痛みになる可能性があります。ただし、チームの他のメンバーのために壊れたコードをチェックインするよりも苦痛は少ないかもしれません。

ジョナサン・クーが言ったように、あなたはすべてビルドサーバーとビルドスクリプトに責任を持つべきです。3つの理由があります。

1. 現時点では、「Bus of 1」のケースがあります。つまり、バスにひかれた場合、ビルドサーバーとビルドスクリプトのすべての知識が失われます。
2. あなたが（正しいか間違って）書いたスクリプトは、あなたの入力があっただけです。他のコードと同様に、関与する人が多いほど、そのコードに適用できる知識ベースが広くなります。
3. 最後に、何かがうまくいかないとき、あなただけが痛みを感じています。痛みは良いことですが、孤立しているときではありません。現時点では痛みに対処していますが、他の全員が痛みを抱えている場合は、コミットする前にコードをテストすることで、最終的にはより厳しくなります。

私はCIに非常に深く関わっており、スクリプトを管理しているというtrapに陥りますが、それを緩和するためにできることをいくつか紹介します。

1. ビルドスクリプトは、CIサーバー上だけでなく、ローカル開発マシン上でも実行する必要があります。同じ出力を生成し、同じテストを実行し、同じ理由で失敗するはずです。これにより、開発者はコードをコミットする前にスクリプトを実行できます。
2. 誰かがビルドを壊した場合、タスクトレイのポップアップ、メール、点滅するライト、ノイズなどを使用して公開します。チームメンバーを困らせるだけでなく、チームの他の全員がジャンプして、支援する。
3. しばらくの間、ビルドを修正しないでください。他の誰かにそれをさせてください。誰もジャンプしない場合は、悪いことが起こるのを待って、CIサーバーが重要である理由を理解するためにチーム全体の学習ポイントとして使用します。
4. ビルドサーバーと開発マシンをできるだけインストールして、サードパーティのコンポーネントをできるだけインストールしないようにします。特にGACをクリーンに保ちます。プロジェクトライブラリフォルダにあるサードパーティのコンポーネントに依存します。これにより、不足しているコンポーネントをより迅速に特定できます。

可視性が役立ちます。すべてのチームメンバーは、修正すべきアクティブな問題があることを知る必要があります。電子メール通知は便利ですが、開発者が忙しくてすぐに反応しない場合、おそらくそれを忘れてしまい、電子メールは膨大な通知の山になってしまいます。

CatlightやBuildNotifyなどのツールを使用してみてください。トレイ領域の重要なビルドの現在のステータスが表示されます。開発者は時計を見るたびに、修正が必要な壊れたビルドがあることを確認します。

また、Catlightは、ビルドに最初に失敗した人を表示し、この人に社会的圧力をかけます。これは、チーム全体がビルドが失敗するたびにそれを確認するためです。

1つの戦略は、多数の小規模プロジェクトに多数の小規模ブランチを使用することです。誰かがビルドを壊すと、彼らは自分自身でビルドを壊しているだけです。したがって、彼らはビルドサーバーから迷惑なメールを受け取り、それを心配するのは彼ら次第です。

もう1つは、人々の責任レベルを改善することです。たとえば、Rietveldのようなものを使用する場合、人々は査読に合格しなければコミットできません。（実際のプロセスは、あなたが思っているよりもはるかに軽いです。しかし、それは人々を「パイプライン」にし、一度に複数の事柄に取り組むことを強制します。）誰かが定期的にビルドを壊したり、ビルドを壊すものを承認したりする場合は、コミットの最終承認を許可しないでください。誰でも簡単に変更をロールバックできるプロセスと組み合わせると、ビルドはそれほど頻繁に壊れず、変更が行われても壊れたままになりません。

ここでコーラスを破り、実際にビルドを破ることはそれほど悪いことではありません。実際の作業が行われていることを示しています。はい、開発者はコミットする前にビルドおよびテストする必要がありますが、テストの主な負担は、継続的統合サーバーを含む開発自動化ツールが負担する必要があります。これらのツールは使用するためのものであり、ビルドが何度も中断しない限り、できるだけ強くプッシュしていることは明らかではありません。ただし、かなりの期間にわたってビルドが壊れたままになることは決してないと考えており、集中化された自動テスト施設からの迅速なフィードバックという2つの目的をサポートするのに役立つ場合は、自動ロールバックまたはマルチステージコミットプロセスを好むことさえあります。プラス「緑」のトランク。

心に留めておくべき事柄：

1. あなたのチームは従うべき一連の標準を必要とします
2. クリーンなコードの考え方を活用して管理を獲得し、コードプラクティスの改善に努める必要があります。
3. テストテストテスト！チェックインする前に必ずテストしてください。
4. ビルドを壊しても構いませんが、それはまれであり、受け入れられる非常にまれな機会を意味します。これが毎日の場合は、ドアを探すか、標準について上司に話します。

全体として、個々のプラクティスではなく、ベストプラクティスに基づいて標準を設定し、作成する必要があります（明らかにそれらはうまくいきません）。全員が標準に同意したら、コードレビュープロセスを開始し、標準を実施します。経営陣は休暇を取り、戻ってこなかったようです。これらは、正直なところどの店にとっても非常に基本的なものです。優れたコードの基盤は、チームのコードとその記述方法を規定する優れた標準から始まります。ちょうど私の考え。最近、新しい仕事で同じような状況に陥り、上司と話をしました。AXYに影響するため、XYZを完了する必要があると彼に説明しました。2週間後、私は従うべきコード標準のリストを書き、それを提示しました。同僚がそこに情報を提供し、約2か月後に大量の問題を解決する基準が整いました。