毎日のビルドはWebアプリを使用する方法ですか？

Question

ジョエルはデイリービルドをよく考えてください。従来のコンパイルされたアプリケーションの場合、私は確かに彼の正当性を見ることができますが、これはどのようにウェブ開発と並行するのでしょうか？

私が求めているプロジェクトについて少し- Django（Python）Webアプリに取り組んでいる開発者は2人います。 1つのsvnリポジトリがあります。各開発者は、チェックアウトとローカルで実行されるMySQLの独自のコピーを保持します（Djangoに慣れていない場合は、独自のテストサーバーにバンドルされており、Visual Studio内でASPアプリを実行できます）。開発とテストはローカルで行われ、その後リポジトリにコミットされます。 Webサイトの実際の作業コピーはSVNチェックアウトです（SVNエクスポートについて知っているため、時間がかかりすぎます）。 「ビルド」に最も近いのは、作業コピーでSVN更新を実行し、djangoビット（「manage.py syncdb」）を実行し、検索エンジンキャッシュ（solr）を更新してからApacheを再起動するバッチファイルです。

見られないのは、Webアプリと類似していると思います。

「ナイトリービルド」を使用してソース管理されたWebアプリを実行していますか？その場合、どのように見えますか？

Answer 1

ナイトリービルドとして、Djangoテストフレームワークを介してすべてのDjangoユニットテストを簡単に実行できます。

それが私たちのすることです。

Djangoの機能を活用しない通常の単体テストもいくつかあり、それらも実行します。

Python（およびDjango）は、コンパイルされた言語のような夜間のコンパイル/リンク/ユニットテストを必要としませんが、「ビルドを壊さない」という日々の規律の恩恵を受けます。そして、所有しているすべてのものを単体テストする毎日のサイクルは良いことです。

Python 2.6（これは完璧に機能します）を見て、使用されている非推奨の機能を確認するために -3 オプションを使用してユニットテストを実行しています。単体テストの完全なスイートを持つことにより、Python 3互換性の変更がビルドを壊さないことが保証されます。そして、それらを毎晩実行するということは、正しくリファクタリングしていることを確実にしなければならないことを意味します。

Answer 2

継続的な統合は、適切なプロセスが必要な場合に役立ちます。 JetBrainsのTeamCityは、親しみを深めたい場合に最適な出発点です。

http://www.jetbrains.com/teamcity/index.html

Djangoに直接関連する素晴らしい記事がここにあります：

http://www.ajaxline.com/continuous-integration-in -django-project

これで開始できることを願っています。

Answer 3

動的言語で構築されたWebアプリケーションは、「コンパイル」を必要としない場合があります。ステップですが、まだ多くの「ビルド」が存在する可能性があります。アプリを実行するための手順。ビルドスクリプトは、依存関係をインストールまたはアップグレードし、データベースの移行を実行してから、テストスイートを実行して、コードが「クリーン」であることを確認します。 w.r.t.リポジトリ内の実際のチェックインバージョン。または、コードのコピーをテストサーバーに展開し、新しいバージョンに対して一連のSelenium統合テストを実行して、コアサイトの機能が引き続き機能することを確認します。

継続的インテグレーションのトピックについて読むのに役立つ場合があります。これは、webapp開発チームにとって非常に便利なプラクティスです。開発プロセスのペースが速く、機敏であればあるほど、自動テストと品質メトリックスからの定期的な入力が必要になり、コードの破損バージョンで迅速かつ大規模に失敗することを確認します。

Answer 4

本当にあなたと他の1人の開発者だけが作業している場合、ナイトリービルドではおそらくあまり効果がありません。

ナイトリービルドに相当するWebアプリはステージングサイト（ナイトリービルドが可能）であると言えます。

ステージングエリアへのナイトリービルドが実際の配当を支払うのは、クライアントのプロジェクトマネージャー、QAの人々が最新の比較的安定したバージョンのアプリを確認できる必要がある場合です。開発者のサンドボックス（少なくとも私のようであれば）は、次の機能を実装しようとして物事を壊しているので、おそらく使用できない状態で多くの時間を費やしているでしょう。そのため、一般的な問題は、QA担当者がバグが修正されたことを確認したい、PMが計画された機能が正しく実装されたことを確認したい、またはクライアントが関心のある問題の進捗を確認したいということです約。開発者のサンドボックスにしかアクセスできない場合、サンドボックスバージョンが実行されていない（つまり、。/ manage.py runserverがターミナルのどこかで起動していることを意味する）か、他の何かが原因で壊れた状態にある。それは本当にチーム全体を遅くし、多くの時間を無駄にします。

実稼働バージョンを自動的に更新するだけなので、ステージング設定がないようです。あなたが私（そしてほとんどの開発者）よりも慎重かつ規律があり、完全に防弾ではないものを決してコミットしないなら、それは問題ないでしょう。個人的には、私の作品が本番に達する前に、少なくとも私以外の誰かによる少なくとも大雑把なQAを通過したことを確認したいです。

つまり、結論として、私が作業しているセットアップ：

• 各開発者は独自のサンドボックスをローカルで実行します（実行するのと同じです）
• 「共通」があります; cronジョブから毎晩更新される開発サーバー上のサンドボックスのステージング。 PM、クライアント、QAがそこに行きます。開発者サンドボックスへの直接アクセスは許可されません。
• 本番環境への自動化された（手動で開始された）展開があります。開発者またはPMは「プッシュ」できます。物事が十分にQAされており、安定して安全であると感じたときに、本番環境に。

唯一の欠点は（夜間のステージングビルドをセットアップするための余分なオーバーヘッドが少し必要ですが）バグの確認に1日かかることです。つまり、QAはソフトウェアのバグを報告し（その日のナイトリービルドの確認に基づいて）、開発者がバグとコミットを修正し、QAはバグが実際に修正されたことを確認するために翌日のビルドまで待つ必要があります。スケジュールに影響を与えない程度の十分な処理がすべてのユーザーに行われているため、通常はそれほど問題ではありません。マイルストーンが近づいており、機能が凍結されたバグ修正のみのモードになっている場合、ステージングサイトの手動更新をより頻繁に行います。

Answer 5

継続的インテグレーションに Hudson を使用して、大きな成功を収めました。 Redsolo によるPythonでのHudsonの使用に関する詳細。

>

数か月前、継続的な展開を支持するいくつかの記事はオンラインでかなりの騒ぎを引き起こしました。 IMVU には、最大5回デプロイ日。

Answer 6

頻繁なビルドの背後にある全体的なアイデア（継続的インテグレーションのように夜間またはより頻繁に）は、問題の導入から検出までの経過時間を短縮するために、即座にフィードバックを取得することです。したがって、頻繁にビルドすることは、コンパイル、（理想的には自動化された）テスト、品質チェックなどを通じてフィードバックを生成できる場合にのみ役立ちます。フィードバックがなければ、実質的なポイントはありません。