build-process - ビルド プロセスの改善

Question

または、そもそもビルド プロセスがあまり整っていないときに、実際にビルド プロセスを確立します。

現在、それが私のグループが直面している状況です。私たちは主に Web アプリの開発を行っています (ただし、現時点ではデスクトップ開発は行っていません)。私たちの控えめなアプリでも、ソフトウェアの展開は醜く扱いにくく、私がこのチーム (および会社) の一員であった 2 年間で、非常に多くの問題が発生しました。それについて何かをするのは過去のことであり、最終的には、1 つの石で 2 羽の Joel Test 鳥を殺すことができるようになります (デイリー ビルドとワンステップ ビルド、どちらもどのような形でも存在しません)。

私がここで求めているのは、私よりも長くソフトウェア開発に携わっていて、より大きな頭脳を持っている人々から、私がやったり考えたりする必要がある種類のことについての一般的な洞察です. 現在ベータ版に投稿しているほとんどの人がそうなると確信しています。

関連ツール: Visual Build Source Safe 6.0 (わかっていますが、現時点で Source Safe を使用するかどうかについては何もできません。次に戦うのはそれかもしれません。)

暫定的に、これを行う Visual Build プロジェクトがあります。

1. ソースを取得し、プロジェクトに必要な DLL を含むローカル ディレクトリに配置します。
2. 構成ファイルを取得し、必要に応じて名前を変更します (実際のアプリケーションの一部ではない特別なサブディレクトリに保存しており、用途に応じて名前が付けられています)。
3. Visual Studio を使用してビルドする
4. コマンドラインを使用してプリコンパイルし、「ビルド」ディレクトリになるものにコピーします
5. 宛先にコピーします。
6. 必要な追加リソースを取得します。ほとんどの場合、プロジェクトに関連付けられているドキュメント、画像、レポートなどです (手順 5 のディレクトリに配置されます)。このようなものはたくさんありますが、以前は含めたくありませんでした。ただし、変更された項目のみをコピーするつもりなので、関係ないかもしれません。このようなものを以前のステップに本当に含めたいかどうかはわかりませんでした。

これらすべてのために、Visual Build からログアウトするように説得する必要がありますが、まだそれを行う必要がある段階ではありません。

アドバイスや提案はありますか？現在、展開プロジェクトは使用していません。このビルドに必要な手順の一部が削除されると思います (web.config のスワッピングなど)。

Answer 1

自動化されたビルド プロセスを使用したことがないプロジェクトに取り組むときは、段階的に進める方が簡単です。一度にたくさん飲み込もうとしないでください。

1. 最初に、自動ビルド プログラム (つまり、nant/msbuild) を使用して 1 ステップでコードをコンパイルします。どちらが優れているかを議論するつもりはありません。自分が使いやすいと思うものを見つけて使いましょう。ビルド スクリプトをプロジェクトと共にソース管理に含めます。
2. 自動ビルドをどのようにトリガーするかを考えます。CruiseControl に接続するか、Scheduled Tasks を使用して夜間のビルド タスクを実行するか。CruiseControl または TeamCity は、このステップを容易にするために使用できる多くのツールが含まれているため、おそらくこれに最適な選択です。CruiseControl は無料で、TeamCity はある程度無料ですが、プロジェクトの規模によっては有料になる場合があります。
3. わかりました。この時点で、ツールにかなり慣れているでしょう。これで、テスト、展開などで実行したいことに基づいて、さらにタスクを追加する準備が整いました...

お役に立てれば。

Answer 2

これらすべてを実行する一連の Powershell スクリプトがあります。

スクリプト 1: ビルド - これは単純です。ほとんどの場合、msbuild の呼び出しによって処理され、データベース スクリプトも作成されます。

スクリプト 2: パッケージ - これはさまざまな引数を取って、テストなどのさまざまな環境向けのリリースと、多くのマシンで構成される運用環境のサブセットをパッケージ化します。

スクリプト 3: デプロイ - これは、パッケージ スクリプトによって作成されたフォルダー内から個々のマシンで実行されます (デプロイ スクリプトはパッケージングの一部としてコピーされます)。

デプロイ スクリプトから、マシン名などのサニティ チェックを行って、誤って間違った場所にデプロイされないようにしています。

web.config ファイルには、

<appSettings file="Local.config">

本番マシンに既に存在するオーバーライドを持つ機能であり、それらは読み取り専用であるため、誤って上書きされることはありません。Local.config ファイルはチェックインされていないため、ビルド時にファイルを切り替える必要はありません。

[編集] config セクションの appSettings file= に相当するものは、configSource="Local.config" です。

Answer 3

2年前にperlスクリプトの使用からMSBuildに切り替えましたが、振り返ることはありません。Visual Studioソリューションの構築は、メインのxmlファイルで指定するだけで実行できます。

より複雑なもの（ソースコードの取得、単体テストの実行、インストールパッケージのビルド、Webサイトのデプロイ）については、Execute関数をオーバーライドするTaskから派生した新しいクラスを.netに作成し、ビルドxmlファイルからこれを参照できます。 。

ここにはかなり良い紹介があります： 紹介

Answer 4

私は2、3の.Netプロジェクト（私は主にJavaを実行しました）にしか取り組んでいませんが、私がお勧めする1つのことは、NAntのようなツールを使用することです。ビルドをIDEに結合することに本当に問題があります。ビルドするボックスで完全なVSインストールを実行する必要があるため、ビルドサーバーをセットアップするのが非常に面倒になります。将来。

そうは言っても、自動ビルドは自動ビルドなしよりも優れています。

Answer 5

私たちのビルドプロセスは、10年ほどで進化した自家製のPerlスクリプトの集まりであり、特別なことは何もありませんが、それで仕事は終わります。1つのスクリプトが最新のソースコードを取得し、別のスクリプトがそれを構築し、3番目のスクリプトがネットワーク上の場所にそれをステージングします。デスクトップアプリケーションの開発を行っているため、ステージングプロセスでは、テスト用のインストールパッケージを作成し、最終的には顧客に出荷します。

再構築したいが最新のものを入手したくない場合や、単に再ステージングする必要がある場合があるため、個々のステップに分割することをお勧めします。私たちのスクリプトは、さまざまなブランチからの構築も処理できるため、開発するソリューションでもそれを考慮してください。

最後に、トランクとメンテナンスブランチを毎晩再構築し、問題が発生した場合、または正常に完了した場合に電子メールを送信する専用のビルドマシンがあります。

Answer 6

ビルド スクリプト (および場合によってはインストーラー プロジェクト) がソース管理されていることを確認することをお勧めします。私は、「メイン」ビルド スクリプトをチェックアウトして最新のものを取得し、それを起動するだけの非常に単純なスクリプトを使用する傾向があります。

チームがサーバー上で最新バージョンのビルド スクリプトを実行しているだけで、それをソース管理に入れていないか、そうしてもランダムにチェックインするだけです。ビルド プロセスをソース管理から「取得」する場合、最新かつ最高のビルド スクリプトをそこに保持する必要があります。

Answer 7

UppercuTを使用しています。UppercuTはNAntを使用して構築し、非常に使いやすいです。

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

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

Answer 8

私たちのビルドシステムはmakefile（または2つ）です。Windows（VSでのビルドタスクとして）とLinux（通常の「makebla」タスクとして）の両方で実行する必要があるため、動作させるのはかなり楽しかったです。本当に楽しいのは、ビルドが.csprojファイルから実際のファイルリストを取得し、そこから（別の）makefileをビルドして、それを実行することです。プロセスでは、makeファイルは実際にそれを自分自身と呼びます。

その考えが読者を怖がらせないのであれば、（彼らが狂っている、または）彼らはおそらくmake+「あなたの好きな文字列マングラー」を彼らのために働かせることができます。