2

ビルド システムのベスト プラクティスは、すべてのソースをビルドしてリリースをパッケージ化できる単一のスクリプトを用意することです。ジョエルテスト＃2を参照してください

移植性のない依存関係をどのように説明しますか? たとえば、.net 4 用にコーディングする場合は、ボックスに .net 4 をインストールする必要があります。標準の MS リリース .net 4 は xcopy で展開できません (私が間違っていなければ?)。私はいくつかの道を見ることができます：

  1. 依存関係は、いくつかのリソース ファイル (wiki、txt など) に明確に記載されています。ビルド スクリプトを呼び出すと、依存関係がインストールされていない場合、ビルドは失敗します。これは許容できる結果です。
  2. ビルド スクリプトは、環境のセットアップを担当します。したがって、.net 4 が必要で、ボックスにない場合は、インストールされます。
  3. #2 のフレーバー - 依存関係をインストールする代わりに、スクリプトは、すべての依存関係でセットアップされた事前にパッケージ化されたイメージ (仮想マシン、Amazon EC2 AMI) を生成します。
  4. ???
4

2 に答える 2

1

ビルドスクリプトを実装するには、自分自身に、必要な/それに費やすことができる作業量を自問する必要があります。これは、ビルド環境をセットアップする必要がある頻度の問題につながります。＃2が完璧な解決策であることがわかりますが、通常は移植性のない依存関係が複数あるため、多くの作業が必要になります。

したがって、＃1を使用します。そして、それは非常にうまく機能します。最も重要なことは、ビルドスクリプトが何らかのセルフテストから始まっているということです。ソフトウェア全体を構築するために必要なすべてのものを探し、何かが見つからない場合はエラーを出します。そして、それは明確なエラーメッセージを与えるので、新しい人はそれを実行するために何をすべきかを知っています。もちろん、多くのソフトウェアと同様に、それはほとんど完成せず、ニーズによって拡張されます。ビルドプロセス全体に数分以上かかる場合、このテストに数秒かかる可能性があるという欠点は重要ではありません。

セットアップソリューションを備えたwiki（またはsth。else）は、3か月後、これがどこにあるか誰も知らないため、私たちにとって良いソリューションではありませんでしたが、ビルドスクリプトは毎日使用されます。

ビルドスクリプト自体は、必要に応じて選択されたさまざまなもののセットです。それは他の多くのものを呼び出すバッチ（私たちはWindowsを使用しています）から始まります。その他のバッチ、MSBuild、自家製ツール。各ステップは、それ自体が依存関係をチェックし、問題をローカルに持っており、この特別なことが必要な理由を3行後に確認できます。

于 2011-12-06T11:04:00.973 に答える
0

番号 2 は、「1 つのステップでビルドを作成できますか?」と述べています。説明したように、これは、開発チームが効果的に機能するためには、ビルド プロセスのエラーを減らし、一貫性を確保するために、ビルド プロセスをできるだけ単純にする必要があることを意味します。これは、チームが大きくなるにつれて特に重要になります。全員が同じものを構築していることを確認する必要があります。(そのパッケージで行われることも単純である必要がありますが、それほど重要ではありません。) Msbuild はこれに優れています。ソース管理システムに独立してアクセスするビルド サーバーをセットアップする機能を提供するため、開発者のアクションによってビルド環境が破損することはありません。TFS を使用してビルド サーバーをセットアップすることを強くお勧めします。多くのビルドの問題が解消され、Joel が説明するワンクリック ビルドが実現します。

そのパッケージが展開のために何をするかについてのあなたのポイントについては、MSには多くのオプションがありますが、「ワンクリック」が多ければ多いほど、より良いものにすることができます. これは Joel の #2 とは少し異なると思います。彼の例では、インストールに使用するソフトウェアを変更するのは、より少ないステップで実行できるからではなく、1 ステップのビルドに組み込むことができるからであると説明しています。

于 2011-11-26T16:03:21.940 に答える