14

ここにいる誰もが、プロのソフトウェアハウスと見なされるためには、いくつかの基本的なことが整っていなければならないことに同意すると思います。

これらの 1 つがビルド サーバーであることは疑いの余地がありません。

  • ビルド サーバーの最小要件は何ですか? （コンパイルするだけの場所？）
  • ビルド サーバーの最終的な目標は何ですか? (スケジュール、ソース管理統合、テスト/ライブ サーバーへの自動デプロイ)
  • 現時点で何も持っていないと仮定すると、どこから始めるのが適切ですか?

アマチュアの開発者が、完全に機能するビルド サーバーに向けて適切な軌道に乗せるために取り組めるいくつかの簡単なタスクをリストアップできれば素晴らしいことです。

また、必要なすべての機能を実行する「完全な」システム セットアップが完了したと感じている人々と、それをすべてゼロからセットアップする方法について聞くのもよいでしょう。

4

12 に答える 12

12

クルーズコントロールを調べることから始めることができます。

それがあなたの毒ならCruiseControl.netもあります。

ただし、基本的には、次の成分が必要です。

  • 専用環境 (仮想マシン/サーバー。自分だけでない限り、開発者のマシンを使用しないでください。その場合でも、可能であれば VM を実行してください。組織で使用可能になったときにサーバーに移動する方がはるかに簡単です)
  • ラベル付き/タグ付きリビジョンをサポートするソース管理システム (例: Subversion + TortoiseSVN )
  • スクリプトをビルドします。これらは、コマンド ラインで devenv.exe または msbuild.exe アプリケーションを起動するバッチファイルにするか、AntやNAntなどを使用できます。

このシナリオでは、CruiseControl は継続的インテグレーションサーバーとして機能し、コードをチェックインするときにビルドが完了していることを確認できます。これは、ナイトリー ビルドを行った場合よりも、ビルドが壊れているかどうかをすぐに知ることができることを意味します。ただし、おそらく夜間ビルドも必要です。

于 2009-01-20T10:59:46.527 に答える
4

Hudsonは優れた CI です。

私たちはファームをローカルで実行していますが、hudson.war をダウンロードして実行することから始めました。

java -jar hudson.war

SCM、バグ追跡システムと統合されており、本当に素晴らしいです。

古いビルドを維持したい場合は、いくらかのディスク容量が必要になります。

これまでで最も簡単な CI ソリューションです。

HTH、ヒューバート。

于 2009-01-20T15:21:38.370 に答える
2

Cruise、Maven、Hudson などはすべて優れていますが、その場しのぎのソリューションを用意する価値は常にあります。

任意のマシンからビルドを実行できるようにするバッチ ファイル、シェル スクリプト、または簡単に記述された手順が必要です。過去にビルドサーバーを利用できなかったことがあり、別のマシンにすばやく切り替える機能は非常に貴重でした!

巨大なプロジェクトでない限り、ビルド マシンのスペックは重要ではありません。私たちはビルド時間を 10 分 (単体テストを含む) に抑えるように努めており、かなり大きなプロジェクトがあります。

「そこにあるツールはどれも十分に優れていない」という理由で、独自のビルドシステムを作成または記述しようとしないでください。最近のすべてのビルド システムでは、プラグインを記述してカスタム処理を行うことができます。

于 2009-01-22T08:51:49.280 に答える
2

Cruise Control を使用している場合、作業を手動で行う Ant build.xml から開始します。

ラベル付きチェックアウトを実行できるバージョン管理システムが必要です。

Ant タスクを使用して実行し、HTML レポートを生成するには、JUnit テストが必要です。

于 2009-01-20T11:01:51.403 に答える
2

構造化された方法でコードをビルドできるように、ビルド戦略を実装することから始める必要があると思います-私はNANTを使用しています。

基本的なビルド サーバーの場合、ソース管理を監視し、変更が検出されるたびにビルドをトリガーする CI 製品の 1 つを使用します。例：クルーズコントロール。

基本的なビルドをまとめたら、ビルドが成功した後に単体テストの実行を追加します。

私が導入した中で最も成功したシステムには、3 つの異なるビルドがありました。1 つはチェックイン時に実行されたもので、コードをビルドするだけでした。- アプリケーションをビルドし、インストーラーを生成し、インストーラーをテスターがピックアップできるように共有ドライブに配置するオンデマンドのビルド - 午後 10 時に実行される毎日のビルド。これ: - UML モデルから DB および C# コードをビルドするためのコード生成を実行しました - コードをビルドしました - テスト Oracle インスタンスで新しいビルド検証テスト ユーザーを作成しました - アプリケーション スキーマを db に実行しました - 一連の単体テストを実行しました- db ユーザーをクリーンアップしました (テストが成功した場合) - カバレッジ分析を実行して、ユニット コード カバレッジのレポートを作成しました

Software we used for this was NANT, CruiseControl.NET, a custom code generation system, custom app to build an oracle schema, and NCover for the code analysis.

于 2009-01-20T11:11:10.043 に答える
2

Start by having a read of Martin Fowler's excellent paper on Continuous Integration.

We built such a system for a major project >2,000 kSLOC and it proved itself to be invaluable.

HTH

cheers,

Rob

于 2009-01-20T11:11:25.660 に答える
1

おおよその順序 - 最小/最も洗練されていないものからより洗練されたものまで

  • ソースの特定のセットを任意のマシンに取得できる
  • そのソースをビルドできる (問題なし)
  • ユーザーの介入なしで、毎晩/または他の定義された期間を構築 (スケジュール) できる
  • 1 つ (または複数) の専用ビルド サーバー (qa または dev マシンとして共有されていない)
  • 各チェックイン/コミット後にビルドを実行できる
  • ビルド後に関係者にビルド ステータスを通知する
  • ビルドステータスをいつでも提供
  • ビルドの一部としてインストーラーを作成する
  • ビルドが良好な場合にデプロイ/ライブする機能
  • 単体テストを実行する
  • 製品でテストを実行する
  • それらのテストの結果を報告する
  • 静的コードの分析とレポート...リストはまだまだ続きます

バッチ ファイル、シェル スクリプト、またはその他のアドホックな手段から始めることを恐れないでください。CI が流行する前に、人々は完璧に優れたソフトウェアを作成していました。Hudson と Cruise Control の前には、多くの優れたプロセスがありました - (私はそれらや他のものをノックしているわけではありません - 私は特に Hudson を使用しています) - しかし、ポイントをお見逃しなく - これらはあなたを助けるためにここにいます - 威圧的なプロセスになることはありません)

于 2009-10-18T23:36:20.117 に答える
1

私は Cruisecontrol.NET と msbuild buildscript を使用しています。

ビルドスクリプトを手動で使用して、コードベースの最新バージョンを取得し、コマンドラインを使用してコードベースを非常に簡単に構築できます。(複数のソリューションで構成されるアプリケーションで作業している場合、これは非常に興味深いものです)。

次に、CruiseControl.NET ビルドサーバーもこのビルドスクリプトを使用します。ソース管理にコミットされた変更があるかどうかを定期的にチェックします。
その場合、CC.NET はビルドスクリプトで定義した「get-latest」タスクを実行し、すべてをビルドし、単体テストを実行し、静的コード分析 (fxcop) を実行します。

私の「buildserver」は単なる古いワークステーションです。これは PIV、1GB RAM を搭載した 3Ghz で、その仕事を完璧にこなします。

私が興味深いと思うもう 1 つの点は、新しいバージョンを自動的に展開する機能、またはセットアップを構築する機能があることです。それが良いアイデアかどうかわからないし、そうするための良い戦略をまだ見つけていないので、私はまだそれをしていません... つまり; ミッション クリティカルなアプリケーションのために、いくつかのコンポーネントの新しいバージョンを本番環境にデプロイすることは良い考えですか? 私はそうは思わない ...

ここから始めるのが良いと思います: [ http://confluence.public.thoughtworks.org/display/CC/Home;jsessionid=5201DA7E8D361EB164C40E519DA0F0DE][1]

少なくとも、ビルド サーバーをセットアップするときに探し始めた場所です。:)

[1]: CruiseControl のホーム

于 2009-01-20T11:23:22.110 に答える
0

まず、開発者のマシンで実行されるバッチスクリプトを作成します。すべてのプロセスを自動化したら、それらをビルドサーバーに移動します。

ツール側では、現在、クルーズコントロールからTFSに移行しています。

于 2009-11-01T22:01:47.360 に答える
0

ビルド サーバーのセットアップ方法の詳細をすべてお伝えすることはできませんでしたが (私が関与したのは最初の段階だけでした)、次のことを行います。

  1. ASP.NET と .NET Windows サービスで実装された社内システムから始め、NAnt を使用して実際のビルドを行いました。実際、ほとんどのワークフローは NAnt で実装されていました (たとえば、人々にメールを送信したり、コピーしたりなど)。
  2. JetBrains TeamCity (無料のカットダウン バージョンが利用可能です) に移行しましたが、これはまだうまく機能しています。

コミットによってトリガーされるビルドに使用します。これらはバイナリをビルドし、単体テストを実行するだけです。ここから、MSI も行う完全なビルドを実行できます。そこから、仮想マシン (別のドメイン コントローラー、SQL Server ボックスなど) で構築された環境全体で、より詳細なテストを実行するシステム テスト ビルドがあります。システム テストに合格すると、手動テストとまだ自動化されていないいくつかの回帰テストのために、QA 部門がビルドを利用できるようになります。

于 2009-01-20T11:07:23.657 に答える
0

Java スペースでは、利用可能なビルド環境のほとんどをテストしました。自動ビルドの問題は、かなりの時間をフォローアップに費やすことになることが非常に多いことです。Atlassianから商用の Bamboo に切り替えた後、ビルド ボックスを甘やかすのに費やす時間が大幅に短縮されることがわかりました。Bamboo はクラスタリングもサポートしているため、必要に応じて安価なボックスを追加できます。

于 2009-01-20T11:13:14.953 に答える
0

ビルドに関して既存の慣行に適合するものを試してみてください。たとえば、Maven を使用している場合、Ant ベースのビルドサーバーを試して使用するのは適切ではありません。

理想的には、ソース管理システムを監視し、コードをチェックアウトし、ビルドし、いくつかのテストを実行して、気付かないうちに、または少なくとも失敗が報告されるまで結果を公開できるようにする必要があります。個人的には、Hudson ( https://hudson.dev.java.net/ ) を出発点としてお勧めします。インストールと実行が簡単で、適切な UI を備えているためです。

于 2009-01-20T13:02:17.900 に答える