8

つい数年前まで、開発者は実際にクライアント向けのビルドを作成していました。これは、列挙するにはあまりにも多くの理由から、明らかに惨事でした。

その後、自分たちのやり方の誤りを学び始めたとき、専用のビルド マシンでアプリケーション全体を自動ビルドする方法を探しました。当時の文化は外部ツールを持ち込むことを非常に嫌っていたので、VB アプリを作成して独自の自動ビルド システムを構築しました。

プロジェクトの構造が変更され始め、新しいプロジェクトが追加され、さまざまな方法でアプリケーションを構築する必要が生じるまで、これはしばらくの間うまくいきました。その後、手巻きの自動車ビルダーの弱点が明らかになり、時間が経つにつれて、ますます面倒になりました。この病気は、ますます多くのプログラミング スキルが必要になるため、QA (ビルド プロセスの所有者) が autobuilder を維持することさえできないところまで進行しています。プロジェクトを追加したり、既存のプロジェクトで何かを変更したりするたびに、それを機能させるためにより多くの開発者の時間が費やされます。システムが壊れてビルドできない日もありました。

私は今、このプロセスを変更できる立場にあり、システム全体を破棄して、別のものを代わりに配置しようとしています。私の目標は次のとおりです。

  • 毎日特定の時間に人的介入なしで実行できる自動構築システムを用意します。すべてのソース コードを収集し、すべてのアプリをコンパイルし、セットアップを作成し、完成した製品をネットワーク共有に配置し、自動テスト システム (QTP を使用) を起動できるようにする必要があります。
  • autobuild システムは、大幅なオーバーホールを必要とせずに、プロジェクトの変更に容易に適応できる柔軟性を備えている必要があります。
  • QA がシステムを所有でき、開発者のリソースがビルドの作成方法を変更する必要がないように、十分にシンプルにする必要があります。

あなたの経験は何ですか？自動構築システムをお勧めできますか? 違う目標を持つべきですか？

4

9 に答える 9

5

ナイトリー ビルドには FinalBuilder と FinalBuilder Server を使用します。少しバグがある場合もありますが、考えてみれば、X プロジェクト タイプをビルドできる拡張可能なプロジェクトを作成し、変更スクリプトからそのデータベースをビルドし、それをテスト サーバーにデプロイするのは非常に簡単です。

また、夜間のビルドを ZIP して FTP にアップロードしたり、ISO イメージを自動的に作成したりするなど、あらゆる種類の奇妙で素晴らしいことを処理できます。

于 2008-10-10T14:15:53.700 に答える
5

現在、Ant と統合された CruiseControl を使用して、プロジェクトのビルドを制御しています。これにより、ビルド スケジュールの柔軟性が得られ、Ant スクリプトを使用してビルド プロセス全体をかなり簡単に自動化できます。また、不具合の修正期間中は、期間ではなくソース管理の送信を監視し、送信が発生したときにビルドするように CruiseControl を設定できます。これにより、開発者は欠陥修正に関する非常に迅速なフィードバックを得ることができます。

于 2008-10-10T12:52:29.673 に答える
4

手巻きの Perl スクリプト セットからBuildbotセットアップに移行したところです。それはGoogle が Chrome に使用しているものだからです。

ナイトリーを実行したり、ソース管理と統合して、誰かがチェックインしたり、その他のさまざまなことを行うたびに、分離されたテスト ビルドを実行したりできます。それも平行です。ビルド ファームに複数のマシンを配置して、特別な作業を行うか、より多くの負荷を処理することができます。

システム全体が Python で記述されているため、プラットフォームに依存しません。これは、複数のプラットフォームでビルドする必要がある場合に重要です。コマンドラインからできることは何でもできます。ユーザー モード コンポーネント用に MSBuild を呼び出しbuild、カーネル モード部分用に DDK を呼び出し、単体テスト ビルド用に製品を実行しています。

箱から出してすぐに、ほとんどの OSS ソース管理ツールをサポートしますが、TFS などを使用している場合は、スレーブ マシンにインストールするパッケージを変更する必要がある場合があります。

于 2008-10-10T13:22:00.440 に答える
4

Microsoft スタックを使用している場合は、必ず MSBuild を調べてください。

Joel は常にFinalBuilderの素晴らしさを語り続けているので、それも一見の価値があるかもしれません。

于 2008-10-10T12:59:39.503 に答える
2

あなたはここで正しい軌道に乗っていると思います。

自動化されたビルド プロセスを担当する人は、ソリューションがどのように適合するかを根本的に理解している必要があります。これは必ずしもコードの書き方やソリューションの設計方法を知っていることを意味するわけではありませんが、ソリューションのコンパイル方法やパッケージ自体などについてしっかりと理解している必要があります。

これを達成するには、人またはチーム間でビルドの責任を共有する必要がある場合があります。毎日のビルドは「チームの責任」だと思います。

国際化されたリリース、fxCop/Quality Tools 構成、ビルド + ユニット テストの実行、継続的インテグレーション ビルド、開発者ワークステーションなどで実行するビルド構成。

代わりに、次のことを達成することを目指します。

  • 自動バージョン管理、署名など
  • ビルド中断のデバッグに役立つ詳細出力 (ログ) を生成する機能
  • その点で-エラーを適切に処理し、できるだけ多くの情報をキャプチャして、適切にログに記録する必要があります
  • 一貫性 - 繰り返し可能な結果を​​生み出すために、毎回同じように機能する必要があります
  • アクセスが制限されたクリーンな環境で実行する
  • 新しいスタッフなどが理解できるように、十分にコメント/文書化されています。
  • リリース ノートの生成、メトリックのコンパイル、レポートの作成のオプション (このオプションが利用可能な場合)
  • 複数の環境に展開する機能
  • ソース管理からソース コードを取得するさまざまな方法をサポートします。たとえば、変更セット、ラベル、日付などによってです。

    • ツールの推奨事項については、FinalBuilder、Visual Build Pro、MSBuild/Team Build、nAnt、CruiseControl、CIFactory に加えて、古き良きバッチ ファイルを使用しました。

    それぞれに長所と短所があります。適切な UI サポートを備えた製品は、操作が少し簡単だったということ以外は推奨しませんが、時にははるかに強力ではありませんでした。VIsual Studio を使用している場合、MSBuild は非常に強力ですが、学習曲線がやや急です。

    于 2008-10-10T14:04:01.010 に答える
    1

    これを行うには、CruiseControl.NETとUppercuT（NAntを使用）を使用します。UppercuTは構築に規則を使用しているため、3つの質問（ソリューションの名前は何ですか？ソース管理へのパスは何ですか？会社の名前は何ですか？）に答えることで、誰かが簡単に構築を開始できます。

    http://code.google.com/p/uppercut/

    ここでいくつかの良い説明：UppercuT

    于 2009-05-16T18:57:45.747 に答える
    1

    MS Visual Studio で提供されるツールの時点で、MSBuild を使用することをお勧めします。MSBuild 用の追加のコミュニティツールセットを使用すると、Subversion および zip 出力からコードをチェックアウトすることもできます。

    社内でうまく活用しています。プロジェクトは、100 以上のサブプロジェクトを含むいくつかのソリューションで構成されています。魅力のように機能します。

    于 2008-10-10T12:54:51.680 に答える
    1

    ビルド マシンが Windows の場合、Visual Build Proは便利です。これで、システムを所有する QAに関する要件を満たすことができると思います。しかし、誤解しないでください、それはかなり強力です。

    于 2008-10-10T12:58:43.683 に答える