コードベースを正常に保つために、ナイトリービルドを実行する必要があります。
ナイトリービルドを実行することの副作用は、チームが完全に自動化されたビルドスクリプトを作成して維持することを余儀なくされることです。これにより、ビルドプロセスが文書化され、再現可能になります。
自動ビルドは、次の問題を見つけるのに適しています。
- 誰かが何かを壊す何かをチェックインしました。
- 誰かが必要なファイルをチェックインするか、変更するのを忘れました。
- ビルドスクリプトは機能しなくなります。
- ビルドマシンが壊れています。
これを毎晩行うことで、そのような問題が発生してから24時間以内に確実にキャッチできます。これは、ソフトウェアを提供する予定の24時間前にすべての問題を見つけるよりも望ましい方法です。
もちろん、毎晩のビルドごとに実行される自動化された単体テストも必要です。
私は個人的に、継続的インテグレーションがナイトリービルドよりも優れていることを発見しました。
http://en.wikipedia.org/wiki/Continuous_integration
私は一人のプロジェクトでもそれを使用しています。問題を明らかにし、その場で問題を処理できるのは驚くべきことです。
私は（とりわけ）ビルドエンジニアリングを16年間行っています。私は、ビルド-初期、ビルド-しばしば、継続的インテグレーションを強く信じています。したがって、プロジェクトで最初に行うことは、プロジェクトのビルド方法を確立することです（Java： Ant または Maven ; .NET： NAnt または- MSBuild ）およびその管理方法（ Subversion またはその他のバージョン管理）。次に、プラットフォームに応じて継続的インテグレーション（ CruiseControl または CruiseControl.NET ）を追加し、他の開発者を解放します。
プロジェクトが成長し、レポートとドキュメントの必要性が高まるにつれて、最終的にはビルドの実行に時間がかかります。その時点で、ビルドを継続的ビルド（チェックイン時に実行）に分割します。これは、単体テストと、すべてをビルドし、すべてのレポートを実行し、生成されたドキュメントをビルドするデイリービルドのみをコンパイルして実行します。また、リポジトリにタグを付け、顧客への配信のために追加のパッケージ化を行う配信ビルドを追加する場合もあります。きめ細かいビルドターゲットを使用して詳細を管理し、開発者がシステムの任意の部分をビルドできるようにします。継続的インテグレーションサーバーは、開発者とまったく同じビルド手順を使用します。最も重要なことは、テスト用のビルドや、ビルドサーバーを使用してビルドされていない顧客を提供することは決してないということです。
それが私がしていることです-これが私がそれをする理由です（そしてあなたもそうすべき理由です）：
複数のプロジェクトと複数の開発者がいる典型的なアプリケーションがあるとします。開発者は、共通の一貫した開発環境（同じOS、同じパッチ、同じツール、同じコンパイラ）から始めることができますが、時間の経過とともに環境は分岐します。一部の開発者はすべてのセキュリティパッチとアップグレードを忠実に適用しますが、他の開発者は適用しません。新しい（おそらくより良い）ツールを追加する開発者もいれば、追加しない開発者もいます。ビルドする前に、ワークスペース全体を更新することを忘れない人もいます。他の人は彼らが開発しているプロジェクトの一部だけを更新します。一部の開発者は、ソースコードとデータファイルをプロジェクトに追加しますが、それらをソース管理に追加するのを忘れます。他の人は、彼らの環境の特定の癖に依存する単体テストを書くでしょう。結果として、人気の高い「まあ、それは私のマシン上で構築/動作する」という言い訳がすぐにわかります。
アプリケーションをビルドするための独立した、安定した、一貫性のある、正常なサーバーを用意することで、この種の問題を簡単に発見できます。また、すべてのコミットからビルドを実行することで、問題がシステムに侵入した時期を正確に特定できます。 。さらに重要なのは、アプリケーションの構築とパッケージ化に別のサーバーを使用するため、常にすべてが同じ方法でパッケージ化されることです。開発者にカスタムビルドを顧客に出荷してもらい、それを機能させてから、カスタマイズを再現する方法がわからないことほど悪いことはありません。
この質問を見たとき、最初に Joel Spolsky's の答えを検索しました。少しがっかりしたので、ここに追加する予定でした。
誰もが知っていることを願っています キャリアのジョエルテスト 。
Joel Test：12 Steps to Better Code に関する彼のブログから
3。デイリービルドを作成しますか？
ソース管理を使用しているときに、あるプログラマーがビルドを壊す何かを誤ってチェックインすることがあります。 たとえば、彼らは新しいソースファイルを追加し、すべてが自分のマシンで正常にコンパイルされますが、ソースファイルをコードリポジトリに追加するのを忘れていました。それで彼らは自分のマシンをロックして家に帰り、気づかずに幸せになります。しかし、他の誰も働くことができないので、彼らも家に帰らなければならず、不幸です。
ビルドを壊すことは非常に悪い（そして非常に一般的である）ので、毎日のビルドを作成するのに役立ち、壊れが見過ごされないようにします。 大規模なチームでは、破損をすぐに修正するための1つの良い方法は、毎日午後、たとえばランチタイムにビルドを行うことです。誰もが昼食前にできるだけ多くのチェックインを行います。彼らが戻ってきたら、ビルドは完了です。それがうまくいったら、素晴らしいです！誰もがソースの最新バージョンをチェックアウトし、作業を続けます。ビルドが失敗した場合は修正しますが、誰もがビルド前の壊れていないバージョンのソースで作業を続けることができます。
Excelチームでは、ビルドを壊した人は誰でも、「罰」として、他の誰かがビルドを壊すまでビルドをベビーシッターする責任があるというルールがありました。これは、ビルドを中断しないための良いインセンティブであり、ビルドプロセスを通じて全員をローテーションさせて、誰もがそれがどのように機能するかを学ぶための良い方法でした。
デイリービルドを作成する機会はありませんが、私はそれが大好きです。
まだ納得していませんか？ここの概要をチェックしてください デイリービルドはあなたの友達です!!
実際にはそうではありません。必要なのは継続的インテグレーションと自動テストです（これはナイトリービルドよりも一歩進んだものです）。
疑問がある場合は、 継続的インテグレーションに関するMartin Fowlerによるこの記事 を読む必要があります。
要約すると、エラーを発生させたときに達成しようとしていたことがまだ頭の中で新鮮である間にエラーを修正できるように、できるだけ早く、頻繁にエラーを見つけてビルドしてテストする必要があります。
実際には、チェックインするたびにビルドを実行することをお勧めします。つまり、継続的インテグレーションシステムをセットアップすることをお勧めします。
このようなシステムの利点とその他の詳細は、 ファウラーの記事 および ウィキペディアのエントリ などの場所で見つけることができます。
私の個人的な経験では、それは品質管理の問題です。コード（または要件の形式と見なすことができるテスト）が変更されるたびに、バグが忍び寄る可能性があります。品質を確保するには、製品の新しいビルドを作成する必要があります。出荷され、利用可能なすべてのテストを実行するためです。これが頻繁に行われるほど、バグがコロニーを形成する可能性は低くなります。したがって、毎日（毎晩）または連続サイクルが推奨されます。
さらに、プロジェクトへのアクセスを開発者またはより多くのユーザーグループに制限するかどうかにかかわらず、ナイトリービルドにより、全員が「最新バージョン」を使用できるようになり、自分の貢献をコードにマージする手間が最小限に抑えられます。
開発者間のコード統合の問題をキャッチするために、通常のスケジュールでビルドを実行する必要があります。これを実行する理由毎晩毎週またはより長いスケジュールではなく、これらの種類の問題の発見を待つ時間が長くなるほど、問題の解決が難しくなるためです。すべてのチェックイン（継続的インテグレーション）でビルドを実行する方法は、夜間のビルドプロセスを論理的に極端なものにしているだけです。
繰り返し可能なビルドプロセスを持つことの副次的な利点は、長期的にも重要です。複数のプロジェクトが進行中のチームで作業している場合、ある時点で、おそらくパッチを作成するために、古いビルドを簡単に再作成できる必要があります。 :(
ビルドプロセスを自動化できるほど、後続のビルドごとに節約できる時間が長くなります。また、ビルドプロセス自体を、最終製品を提供するというクリティカルパスから外し、マネージャーを満足させるはずです。 :)
また、プロジェクトに取り組んでいるチームの規模と構造によっても異なります。相互のAPIに依存している異なるチームがある場合、頻繁に統合するためにナイトリービルドを用意することは非常に理にかなっています。 1人か2人のチームメイトだけでハッキングしている場合は、それだけの価値がある場合とない場合があります。
製品の複雑さに応じて、継続的インテグレーションは完全なテストスイートを実行できる場合とできない場合があります。
シスコが文字通り何千もの異なるセットアップでルータをテストしていると想像してみてください。一部の製品で完全なテストスイートを実行するには時間がかかります。時には数週間。したがって、さまざまな目的のビルドが必要です。ナイトリービルドは、より徹底的なテストスイートの基礎となる可能性があります。
ええと...もちろん、それはあなたのプロジェクトに大きく依存すると思います。リリースも依存関係もなく、コードを送信する以外に誰もいない、趣味のプロジェクトだけの場合は、やり過ぎかもしれません。
一方、すべてコードを送信する開発者のチームがいる場合は、自動ナイトリービルドがリポジトリ内のコードの品質を保証するのに役立ちます。誰かが他のすべての人のために「ビルドを壊す」何かをした場合、それはすぐに気付かれます。たとえば、リポジトリに新しいファイルを追加するのを忘れることで、気付かずにビルドを中断することができます。一元化された場所でのナイトリービルドは、これらを非常に迅速に検出します。
もちろん、他にも考えられるメリットはありますが、他の人がそれらを提供すると確信しています。 :)
特に1人以上のプロジェクトでは非常に重要だと思います。チームは、次の場合にできるだけ早く知る必要があります。
- 不良ファイルをチェックイン
- ファイルをチェックインしません
- .。
ビルドの自動化は、ビルドの自動化がないよりも優れています:-)
個人的には、デイリービルドが好きです。そうすれば、ビルドが機能しない場合は、誰もがそれを修正するために周りにいます。
実際、可能であれば、継続的インテグレーションビルドを使用することをお勧めします（つまり、チェックインごとにビルドする）。これにより、ビルド間の変更量が最小限に抑えられ、ビルドが壊れた人を簡単に特定でき、また簡単になります。ビルドを修正します。
ナイトリービルドは、非常に大規模なプロジェクトにのみ必要です（1日を通して頻繁にビルドするのに時間がかかりすぎる場合）。ビルドに時間がかからない小さなプロジェクトがある場合は、関数型コードを完成させてビルドすることができます。これにより、手順で何も混乱しなかったことがわかります。ただし、大規模なプロジェクトではこれは不可能であるため、すべてが正常に機能していることを確認するためにプロジェクトをビルドすることが重要です。
いくつかの理由がありますが、いくつかは他よりも適用可能です
- プロジェクトが2人以上で作業されている場合
- 作業していない最新バージョンのコードを取得するのに適した方法です。
- ナイトリービルドは、コードの現在の状態の時間のスライスを提供します
- ナイトリービルドは、コードを人に送信する必要がある場合に安定したビルドを提供します
ナイトリービルドは必ずしも必要ではありません-大きなプロジェクトでのみ本当に役立つと思います。しかし、大規模なプロジェクトを行っている場合は、ナイトリービルドがすべてが機能していることを確認する良い方法です-すべてのテスト（単体テスト、統合テスト）を実行し、すべてのコードをビルドできます-要するに、何も機能していないことを確認しますあなたのプロジェクトで壊れています。
プロジェクトが小さい場合は、ビルドとテストの時間が短くなるため、通常のビルドを行う余裕があります。
ナイトリービルドは静的コード分析を実行するのに理想的です（qalabと、Java world）にいる場合は、qalabとそれが統計を収集するプロジェクトを参照してください）。残念ながら、これはめったに行われないことです。