継続的インテグレーションシステムのベビーシッター
私のチームでの私の役割の1つは、ビルド担当者です。私は、ビルドスクリプトを維持/更新し、継続的インテグレーションサーバーで「スムーズに」ビルドすることを確認する責任があります。私は通常この仕事を気にしませんが、CIサーバーを常にベビーシッターしているように感じることがよくあります。
ビルドが失敗した場合、ストーリーを削除してビルドの失敗を調査しなければならないため、この仕事は時々迷惑になることがあります。私たちのチームではビルドの失敗が毎日発生しています。場合によっては、開発者がコミットする前にローカルでビルドしないため、CIサーバーでテストが失敗することがあります。この状況では、ビルドが長時間中断されないように、「悪いコミット」をした人にすぐに連絡したいと思います。デバッグする必要のあるCIサーバーに奇妙な状態が発生する場合があります（それほど頻繁ではありません）。
多くの成熟したチームが継続的インテグレーションを使用していることは知っていますが、優れた実践についての資料はそれほど多くありません。
私の問題は、継続的な統合があまり成熟していないことを指摘していますか、それともこれは単に仕事の一部なのですか？
従うべきいくつかの良い習慣は何ですか？ 成熟した連続積分の特徴は何ですか？
更新
いくつかのコメントに答える代わりに、代わりに更新を行います。アプリをビルドするときにビルドサーバーが行うことを正確に実行する単一の単純なコマンドがあります。すべてのユニット/統合といくつかのクイックUIベースのテストをコンパイル、実行します。
みんなの答えを読んで、2つの大きな問題があるかもしれないと感じています。
- ビルドが失敗したときに、CIサーバーが十分な音を出さない。
- 開発者は、コミットが確実に成功するようにするすべての人の責任のように感じません。
私のチームの状況を難しくしているのは、大規模なチーム（10人以上の開発者）がいて、オフショアのチームメンバーが仕事をしていなくてもコミットしていることです。チームが大規模で、頻繁な小さなコミットが好まれることがわかったので、1日で本当に多くのアクティビティが発生することがあります。
何よりもまず：各人がビルドプロセスの責任を負います。あなたのチームのメンバーは成熟していないようです...コードを書いて、CIサーバーが機能することを期待して、CIサーバーにそれを手に入れることに誰も気を使いません。コードをコミットする前に、ローカルマシンでテストする必要があります。チェックインしているコードがビルドを壊さないことを確認する必要があります。もちろん、意図せずにビルドが中断する場合もあります（たとえば、構成ファイルが変更された場合や、誤って誤ったコミットが行われた場合など）。
ほとんどのCIサーバー（私はHudsonのみを使用しています）は、ビルドを中断させる原因となったコミットの詳細を自動メールで送信します。あなたの役割の唯一の部分は、容疑者が彼らが破ったものを修正するまでタフに見える彼らの後ろに立つことです。
プロセスを変更します。コミットによってビルドが中断された場合、そのコミットを自動的にロールバックし、それを壊した開発者に通知します。 1人のチームメンバーによるエラーが残りのチームの速度を低下させるのはばかげています。または、統合ビルドを自動的に行わせる代わりに、開発者に統合マシンをチェックアウトさせ、ビルドが成功した場合はコミットできます。継続的な統合は、「好きなジャンクをチェックインすれば、誰かがあなたのために修正してくれる」という意味ではありません。
「ゴールデンブランチ」戦略は、ゴールデンブランチのゲートキーパーがいない限り機能しません。
GitのようなDVCSが役立つかもしれません。コミットする代わりに、開発者は変更セットをCIサーバーに統合するために送信するだけで、サーバーは変更セットの統合を試みることができます。統合が成功した場合、変更セットはマージされ、そうでない場合は拒否されます。
私がよく目にする1つの問題は、開発者がCIビルドと同じまったく同じ手順を持つローカルビルドを実行できないことです。つまり、CIサーバーは、ユニット/統合テスト、カバレッジなど、ローカルでは実行できない追加のステップを含むように構成されています。必然的に、開発者はローカルで実行できないステップの1つに噛まれ、チェックインの前にローカルでリリースを構築するのが面倒な理由を疑問視し始めます。
ビルド全体を自己完結型に保ち、無関係な構成や手順を定義せずに、CIサーバーにリリースビルドを開始させるだけです。開発者は、チェックインの前にリリースビルドをローカルで実行できます。これには、CIビルドによって実行されるすべてのステップが含まれ、doチェックインしても何も壊れないことをはるかに確信できます。
このアプローチに追加された利点は次のとおりです。
- 無関係な手順を構成するために多くの時間を費やしていないため、CIサーバーを簡単に切り替えることができます。
- すべてのビルド時ツールはソース管理下にあります。つまり、すべての開発者がまったく同じツールセットを使用してシステムをビルドしています。
- 上記のポイントに加えて、ビルドツールを制御された方法で変更するのは簡単です。
PS。全体のビルドベビーシッターのコンセプトはばかげていますが、他の人はそれをカバーしています。
まず、開発者はビルドを定期的に壊してはいけません。CIブランチにコミットする前に、ローカルでテストをビルドして実行する必要があります。ビルドを壊すことは恥ずべきことであり、それを実施することが重要です。私は統計を投稿することでそれを行いました、そして他のチームがあなたがビルドを壊すたびにあなたがドルを入れる「ビルドバッグ」を持っているのを見ました。プロジェクトの終わりに、そのお金はビールに向かって行きます。
恥/個人的なプライドが機能しない場合は、重いものに移動する必要がある場合があります（終了を脅かすなど）。その日のために出発する前にビルドを壊すことは大きな違反になるはずです。そして、すべての開発者は、自分のデスクトップにビルドステータス通知を持っている必要があります。このすべての最も良い部分は、小さいコミットを奨励することです。
とはいえ、ビルドが壊れることがあります（CI構成の理由など）。そして時々人々は台無しにしてビルドが壊れたその日を去ります。そのため、既知の適切なバージョンにすばやく簡単にロールバックできるプロセスを目指す必要があります。常に最後の適切なビルドにロールバックできる場合（およびロールバックされたバージョンを必要なすべての場所にデプロイできる場合）、ビルドが壊れたという最悪のシナリオでは、原因が夜に残ってロールバックできます。最後の良いバージョンに戻って、朝彼に怒鳴りつけます。
Continuous Delivery book はお勧めできません。 CIプロセスを成熟させる方法に関するガイドを探している場合は、ぜひお試しください。
Microsoft（たぶん？）が行うこと、つまり、ベビーシッターを構築する役割をチーム内で動かすことについて聞いたことがあります。彼らがこれを行う方法は、誰かがビルドを壊したとき（おそらくテストに失敗した何かをチェックインすることを含むはずです）、彼らが役割を引き受けるということです。これにより、人々は自分たちの行動の結果に対して非常に直接的な責任を負います。そして、それはやや厄介な仕事であることを考えると、ビルドを再度中断しないように彼らを励ます。
現在ビルドを担当している人は、特別な帽子を持つことができます。それを渡すための式典があるかもしれません。
Thorbjørnが言うように、ビルドの責任は、ビルドサーバーの責任と同じではないことに注意してください。サーバーの責任は、ビルドの責任が移る間、チームの1人以上のインフラストラクチャに傾倒したメンバーに永続的に置かれる可能性があります。
さて、プロセスの詳細はさておき、ビルドとテストを実行せずにチェックインする開発者たちに失望を表明する人々の合唱に参加します。受け入れられない！
ビルドを中断する可能性が高いチームのメンバーがいる場合（そして私自身の経験に基づいて、私はほとんど別の国のメンバーを考えています）、Mercurialのような素敵な最新のソース管理を使用している場合またはGit、チームの他のメンバーへの別のブランチにチェックインし、その上で別のCIプロセスを実行し、ビルドが成功した後、そのブランチからトランクへの変更を自動的にマージすることができます（必要なことに注意してください）マージをチェックインする前に、2番目のビルドを実行し、マージ後にテストします！）。自動マージが常に成功するとは限らないので、最終的にはブランチが手動での注意を必要とすることになりますが、これは本当の痛みかもしれません。しかし、チームの他のメンバーのために壊れたコードをチェックインするよりも苦痛が少ないかもしれません。
Jonathan Khooが言ったように、ビルドサーバーとビルドスクリプトの責任はすべてあなたにあるはずです。 3つの理由があります。
- 現時点では、「Bus of 1」のケースがあります。つまり、バスに乗り越えられた場合、ビルドサーバーとビルドスクリプトのすべての知識が失われます。
- あなたが（正しくまたは間違って）書いたスクリプトは、あなたの入力しかありませんでした。他のコードと同じように、関係する人が増えるほど、それに適用できる知識ベースが広くなります。
- 最後に何かがうまくいかないとき、あなただけが痛みを感じています。痛みは良いことですが、孤立している場合はそうではありません。現時点ではあなたはその苦痛に対処していますが、他の全員が苦痛を感じている場合は、コミットする前にコードをテストすることで結局はより厳格になるでしょう。
私は自分自身でCIに非常に関与しており、スクリプトを保守する責任者という罠に陥っていますが、これを軽減するためにできることがいくつかあります。
- ビルドスクリプトは、CIサーバー上だけでなく、ローカル開発マシン上でも実行する必要があります。それらは同じ出力を生成し、同じテストを実行し、同じ理由で失敗するはずです。これにより、開発者はコードをコミットする前にスクリプトを実行できます。
- 誰かがビルドを壊した場合、タスクトレイのポップアップ、メール、点滅ライト、ノイズなどを使用してビルドを公開します。これは、チームメンバーを困らせるだけでなく、チームの他の全員がジャンプして、支援する。
- しばらくの間、ビルドの修正を避けます。誰か他の人にやってもらいましょう。他の誰もジャンプアップしない場合は、悪いことが起こるのを待って、チーム全体がCIサーバーが重要である理由を理解するための学習ポイントとして使用します。
- ビルドサーバーと開発マシンに、サードパーティのコンポーネントがインストールされないようにしてください。特に、GACをクリーンに保ちます。プロジェクトライブラリフォルダーにあるサードパーティのコンポーネントに依存します。これにより、不足しているコンポーネントをより迅速に特定できます。
可視性はあなたを助けるでしょう。すべてのチームメンバーは、修正すべきアクティブな問題があることを知る必要があります。電子メール通知は便利ですが、開発者が忙しくてすぐに反応しない場合、おそらくそれを忘れてしまい、電子メールは大量の通知の山になってしまいます。
Catlight または BuildNotify などのツールを使用してみてください。トレイ領域の重要なビルドの現在のステータスが表示されます。開発者が時計を見るたびに、修正が必要な壊れたビルドがあることがわかります。
キャットライトはまた、最初にビルドを壊した人を示し、この人に社会的圧力をかけます。これは、チーム全体が、連続するビルドの失敗ごとにそれを見るからです。
ここで合唱を中断しますが、実際には、実際の作業が行われていることを示しているため、ビルドを中断することはそれほど悪いことではありません。はい、開発者はコミットする前にビルドとテストを行う必要がありますが、テストの主な負担は、継続的インテグレーションサーバーを含む開発自動化ツールが負担する必要があります。ツールは使用するためのものであり、ビルドがときどき壊れない限り、できる限り激しくプッシュしていることは明らかではありません。ただし、ビルドはかなり長い間壊れたままにしてはならず、中央集中型の自動化されたテスト施設からの迅速なフィードバックという2つの目的をサポートするのに役立つ場合は、自動ロールバックまたはマルチステージコミットプロセスを優先することになると思います。プラス「緑の」トランク。
心に留めておくべきことのカップル：
- あなたのチームは従うべき一連の標準が必要です
- クリーンなコードのアイデアを基に管理を強化し、コードプラクティスの改善に努める必要があります。
- テストテストテスト！チェックインする前に必ずテストしてください。
- ビルドを中断しても問題ないことには同意しますが、これはまれなケースであり、許容できる非常にまれなケースです。これが毎日の場合、ドアを探すか、上司に標準について話します。
全体的に、皆さんはベストプラクティスに基づいて標準を設定し、作成する必要があります。個々のプラクティスではありません（明らかにそれらはうまくいきません）。全員が標準に同意したら、コードレビュープロセスを開始し、標準を適用します。経営陣が休暇を取り、戻ってこなかったようです。これらは正直に言って、どのショップにとってもかなり基本的なものです。優れたコードの基礎は、チームのコードとその記述方法を規定するための優れた標準から始まります。ただ私の考え。私は最近、新しい仕事で同じような状況に陥り、上司と話しました。 ABCに影響するため、XYZを完了する必要があることを彼に説明しました。 2週間後、私は従うべきコード標準のリストを作成し、それを提示しました。私の同僚がそこに情報を提供し、約2か月後には、多くの問題を解決する標準が導入されました。
1つの戦略は、多数の小さなプロジェクトに多数の小さなブランチを使用することです。その後、誰かがビルドを壊したとき、彼らは自分のためにビルドを壊しています。そのため、ビルドサーバーから迷惑メールを受け取り、心配するのは彼らの責任です。
もう一つは、人々の責任レベルを改善することです。たとえば、 Rietveld のようなものを使用する場合、人々はピアレビューを通過しないとコミットできません。 （実際のプロセスは、あなたが思っているよりもはるかに軽いです。しかし、それは人々に「パイプライン化」し、一度に複数のものに取り組むことを強います。）ビルドを保存することは、コミッターとレビュアーの両方の責任です。誰かが定期的にビルドを中断している、またはビルドを中断しているものを承認している場合は、コミットの最終的な承認を許可しないでください。誰でも簡単に変更をロールバックできるプロセスと組み合わせると、ビルドが頻繁に中断されることはなく、変更が加えられても壊れたままになることはありません。