nightly-build - Nightly Builds: なぜそれをしなければならないのですか?

Question

ナイトリービルドを行う必要があるのはなぜですか?

score 44 · Accepted Answer

コードベースが正常に保たれるように、毎晩ビルドを行う必要があります。

ナイトリービルドを行うことの副作用は、チームが完全に自動化されたビルドスクリプトを作成して維持することを余儀なくされることです。これは、ビルドプロセスが文書化され、再現可能であることを確認するのに役立ちます。

自動ビルドは、次の問題を見つけるのに適しています。

誰かが何かを壊すものをチェックインしました。
誰かが必要なファイルまたは変更をチェックインするのを忘れました。
ビルドスクリプトが機能しなくなりました。
ビルドマシンが壊れています。

これを毎晩行うことで、そのような問題が発生してから 24 時間以内に確実に把握できます。これは、ソフトウェアを配布する予定の 24 時間前にすべての問題を見つけるよりも望ましい方法です。

もちろん、夜間のビルドごとに自動化された単体テストも実行する必要があります。

score 23 · Accepted Answer

私は個人的に、継続的インテグレーションがナイトリービルドよりも優れていることを発見しました:
http://en.wikipedia.org/wiki/Continuous_integration

私は一人のプロジェクトでもそれを使用しています。問題をすばやく明らかにし、その場で対処できるのは驚くべきことです。

score 19 · Accepted Answer

私は 16 年間、ビルドエンジニアリング (とりわけ) を行ってきました。私は、早期に構築し、頻繁に構築する、継続的インテグレーションを強く信じています。したがって、プロジェクトで最初に行うことは、プロジェクトのビルド方法 (Java: AntまたはMaven ; .NET: NAntまたはMSBuild ) と管理方法 ( Subversionまたはその他のバージョン管理) を確立することです。次に、プラットフォームに応じて継続的インテグレーション ( CruiseControlまたはCruiseControl.NET ) を追加し、他の開発者に任せます。

プロジェクトが成長し、レポートやドキュメントの必要性が高まるにつれて、最終的にビルドの実行に時間がかかるようになります。その時点で、ビルドを単体テストのみをコンパイルして実行する連続ビルド (チェックイン時に実行) と、すべてをビルドし、すべてのレポートを実行し、生成されたドキュメントをビルドする毎日のビルドに分割します。また、リポジトリにタグを付け、顧客への納品のために追加のパッケージ化を行う納品ビルドを追加することもあります。きめ細かなビルドターゲットを使用して詳細を管理し、どの開発者もシステムの任意の部分をビルドできるようにします。継続的インテグレーションサーバーは、他の開発者とまったく同じビルド手順を使用します。最も重要なことは、テスト用のビルドや、ビルドサーバーを使用してビルドされていない顧客用のビルドを提供することはありません。

それが私がすることです -- これが私がそうする理由です (そしてあなたもそうすべき理由です):

複数のプロジェクトと複数の開発者がいる典型的なアプリケーションがあるとします。開発者は、共通の一貫した開発環境 (同じ OS、同じパッチ、同じツール、同じコンパイラ) から始めることができますが、時間の経過とともに環境が変化します。すべてのセキュリティパッチとアップグレードを宗教的に適用する開発者もいれば、適用しない開発者もいます。一部の開発者は新しい (おそらくより優れた) ツールを追加しますが、他の開発者は追加しません。ビルドする前に完全なワークスペースを更新することを忘れない人もいます。他の人は、開発中のプロジェクトの一部のみを更新します。一部の開発者は、ソースコードとデータファイルをプロジェクトに追加しますが、それらをソース管理に追加するのを忘れます。他の人は、環境の特定の癖に依存する単体テストを作成します。その結果、常に人気のある「まあ、

アプリケーションをビルドするための、安定した、一貫性のある、既知の良好なサーバーを個別に用意することで、この種の問題を簡単に発見できます。また、すべてのコミットからビルドを実行することで、システムに問題が忍び込んだ時期を特定できます。 . さらに重要なことは、アプリケーションのビルドとパッケージ化に別のサーバーを使用するため、毎回同じ方法ですべてをパッケージ化することです。開発者がカスタムビルドを顧客に出荷し、それが動作するようになった後、カスタマイズを再現する方法がわからないことほど悪いことはありません。

score 11 · Accepted Answer

この質問を見たとき、まずJoel Spolsky の回答を検索しました。少しがっかりしたので、ここに追加する予定でした。

Joel Test on Careersについて誰もが知っていることを願っています。

The Joel Testに関する彼のブログから: 12 Steps to Better Code

3. 毎日のビルドを行いますか?

ソース管理を使用していると、1 人のプログラマーがビルドを壊すものを誤ってチェックインすることがあります。たとえば、彼らは新しいソースファイルを追加し、マシン上ですべてが正常にコンパイルされましたが、コードリポジトリにソースファイルを追加するのを忘れていました。それで、彼らは自分のマシンをロックして家に帰ります。しかし、他の誰も働けないので、彼らも家に帰らなければなりません。

ビルドを壊すことは非常に悪い (そしてよくあることです) ので、毎日のビルドを作成して、破損が見過ごされないようにするのに役立ちます。大規模なチームでは、破損がすぐに修正されることを保証する 1 つの良い方法は、毎日の午後、たとえばランチタイムに毎日のビルドを行うことです。誰もが昼食前にできるだけ多くのチェックインを行います。彼らが戻ってきたら、ビルドは完了です。それが機能した場合、素晴らしいです！全員がソースの最新バージョンをチェックアウトし、作業を続けます。ビルドが失敗した場合は修正しますが、誰もがビルド前の壊れていないバージョンのソースで作業を続けることができます。

Excel チームでは、「罰」として、ビルドを壊した人は、他の誰かが壊すまでビルドをベビーシッターする責任があるというルールがありました。これは、ビルドを中断しない良いインセンティブであり、ビルドプロセスを通じて全員を回転させて、全員がその仕組みを学ぶ良い方法でした。

毎日のビルドを作成する機会はありませんが、私はそれの大ファンです。

まだ納得できませんか？デイリービルドはあなたの友達です!!の概要をここでチェックしてください!!

score 8 · Accepted Answer

実際には、あなたが望んでいるのは継続的インテグレーションと自動テストです (これはナイトリービルドよりも一歩進んだものです)。

不明な点がある場合は、Martin Fowler による Continuous Integration に関する記事をお読みください。

要約すると、エラーを引き起こしたときに達成しようとしていたことがまだ記憶に新しいうちにエラーを修正できるように、できるだけ早く、できるだけ頻繁にビルドしてテストし、エラーをすぐに発見する必要があります。

score 8 · Accepted Answer

実際、チェックインするたびにビルドを行うことをお勧めします。つまり、継続的インテグレーションシステムをセットアップすることをお勧めします。

このようなシステムの利点やその他の詳細は、ファウラーの記事やウィキペディアのエントリなどで見つけることができます。

私の個人的な経験では、これは品質管理の問題です。コード (または要件の形式と見なすことができるテスト) が変更されるたびに、バグが忍び寄る可能性があります。品質を確保するには、製品の新しいビルドを作成する必要があります。出荷され、利用可能なすべてのテストを実行します。これが頻繁に行われるほど、バグがコロニーを形成する可能性は低くなります。したがって、毎日 (毎晩) または継続的なサイクルが推奨されます。

さらに、プロジェクトへのアクセスを開発者または大規模なユーザーグループに制限するかどうかに関係なく、毎晩のビルドにより全員が「最新バージョン」を使用できるため、自分の貢献をコードにマージする手間が最小限に抑えられます。

score 4 · Accepted Answer

開発者間のコードの統合に関する問題を把握するために、定期的にビルドを行いたいと考えています。毎週またはより長いスケジュールではなく、夜間にこれを行う理由は、この種の問題を発見するのを待つほど、それらを解決するのが難しくなるためです. チェックインのたびにビルドを実行する (継続的インテグレーション) という手法は、夜間のビルドプロセスを論理的に極端なものにしています。

反復可能なビルドプロセスを持つことの副次的な利点は、長期的にも重要です。複数のプロジェクトが進行中のチームで作業している場合、ある時点で、おそらくパッチを作成するために、古いビルドを簡単に再作成できる必要があります。:(

ビルドプロセスを自動化できるほど、後続の各ビルドの時間を節約できます。また、ビルドプロセス自体が、最終製品を提供するためのクリティカルパスから外れるため、マネージャーを満足させることができます。:)

score 3 · Accepted Answer

製品の複雑さに応じて、継続的インテグレーションで完全なテストスイートを実行できる場合と実行できない場合があります。

シスコが文字通り何千もの異なるセットアップをテストするルータをテストしていると想像してください。一部の製品で完全なテストスイートを実行するには時間がかかります。時には数週間。したがって、さまざまな目的のためにビルドが必要です。ナイトリービルドは、より完全なテストスイートの基礎となる可能性があります。

score 3 · Accepted Answer

また、プロジェクトに取り組んでいるチームの規模と構造によっても異なります。お互いの API に依存している異なるチームが存在する場合、頻繁な統合のためにナイトリービルドを用意することは非常に理にかなっています。チームメイトが 1 人か 2 人しかいない場合は、その価値がある場合とそうでない場合があります。

score 2 · Accepted Answer

ええと... もちろん、それはあなたのプロジェクトに大きく依存すると思います。それが単なる趣味のプロジェクトであり、リリースも依存関係もなく、コードを提出する以外に誰もいない場合、それはやり過ぎかもしれません。

一方、すべてのコードをサブミットする開発者のチームが存在する場合、自動ナイトリービルドは、リポジトリ内のコードの品質を保証するのに役立ちます。誰かが他のすべての「ビルドを壊す」ことをすると、すぐに気づきます。たとえば、リポジトリに新しいファイルを追加するのを忘れて、気付かずにビルドを壊す可能性があり、集中管理された場所での夜間のビルドはこれらを非常に迅速に検出します。

もちろん、他の可能性のある利点があります。他の人がそれらを提供すると確信しています。:)

score 2 · Accepted Answer

特に複数の人が関わるプロジェクトでは非常に重要だと思います。チームは、誰かが次の場合にできるだけ早く知る必要があります。

不良ファイルをチェックインする
ファイルをチェックインしません
...

score 2 · Accepted Answer

ビルド自動化は、ビルド自動化なしよりも優れています:-)

個人的には、毎日のビルドが好きです。ビルドが機能しない場合は、誰もが修正するために周りにいます。

実際、可能な限り、継続的インテグレーションビルド (つまり、チェックインごとにビルド) が適しています。これにより、ビルド間の変更量が最小限に抑えられ、誰がビルドを壊したかを簡単に特定でき、さらに簡単になります。ビルドを修正します。

score 1 · Accepted Answer

ナイトリービルドは、非常に大規模なプロジェクトの場合にのみ必要です (1 日を通して頻繁にビルドするには時間がかかりすぎる場合)。ビルドに時間がかからない小さなプロジェクトがある場合は、コードの機能部分を完成させてビルドすることができるので、プロセスで何も台無しにしていないことがわかります。ただし、大規模なプロジェクトではこれは不可能であるため、プロジェクトをビルドして、すべてが正常に機能していることを確認することが重要です。

score 1 · Accepted Answer

いくつかの理由があり、いくつかは他のものよりも適用されます

プロジェクトが 2 人以上で作業されている場合
これは、作業していないコードの最新バージョンを取得するための良い方法です
毎晩のビルドは、コードの現在の状態のタイムスライスを提供します
コードを人に送信する必要がある場合は、ナイトリービルドを使用すると安定したビルドが得られます。

score 0 · Accepted Answer

ナイトリービルドは、静的コード分析を実行するのに理想的です (Java の世界にいる場合は、qalab とそれが統計を収集するプロジェクトを参照してください)。残念ながら、これはめったに行われないことです。

score 0 · Accepted Answer

ナイトリービルドは必ずしも必要ではありません。大きなプロジェクトでのみ役立つと思います。しかし、大きなプロジェクトの場合、ナイトリービルドはすべてが機能していることを確認する良い方法です。すべてのテスト (単体テスト、統合テスト) を実行し、すべてのコードをビルドできます。つまり、何も問題がないことを確認できます。あなたのプロジェクトで壊れています。

小規模なプロジェクトの場合、ビルドとテストの時間が短くなるので、通常のビルドをより多く行う余裕があるでしょう。

nightly-build - Nightly Builds: なぜそれをしなければならないのですか?

16 に答える 16

Related

Reference