ビルド バージョンを管理するための最適なビルド プロセス ソリューション
https://stackoverflow.com/questions/57730
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
私はいくつかの独立したアプリケーションを含むかなり複雑なプロジェクトを実行しています。ただし、これらはいくつかの共有コンポーネントを使用します。したがって、以下のようなソースツリーがあります。
- 私のプロジェクト
- アプリケーションA
- 共有1
- 共有2
- アプリケーションB
- アプリケーションC
すべてのアプリケーションには、プロジェクトとそれに必要なすべての共有リソースを構築する独自の MSBuild スクリプトがあります。また、これらのビルドは、CruiseControl 制御の継続的統合ビルド サーバー上でも実行します。
アプリケーションがデプロイされると、負荷を分散するために複数のサーバーにデプロイされます。ということは、 非常に 異なるサーバーのそれぞれにどのようなビルド/リビジョンがデプロイされているかを追跡することが重要です (DLL バージョンに現在のバージョンが必要です (たとえば、「1.0.0.68」))。
何かが意図したとおりに動作しなかった場合にロールバックできるように構築されたリビジョン/ビルドを再作成できることも同様に重要です (はい、それは起こります...)。現在、ソース管理に SourceSafe を使用していますが、正当な理由を提示できれば変更する可能性があります (SS は実際に問題なく機能しています) それで 遠い）。
私たちが従おうとするもう 1 つの原則は、統合サーバーによってビルドおよびテストされるのはコードのみであるということです。その後デプロイします。
「CrusieControl ビルド ラベル」ソリューション
上記を解決するためにいくつかのアイデアがありました。1 つ目は、継続的統合サーバーを構築し、プロジェクトをローカルにデプロイしてテストすることでした (現在はそれが行われています)。おそらくご存知かと思いますが、CruiseControl でビルドが成功するとビルド ラベルが生成され、それを使用して実行可能ファイルの DLL バージョンを設定できると思います (つまり、ビルド ラベル 35 は "1.0.0.35" のような DLL を作成します)。このビルド ラベルを使用して、 完了 ソースツリー。そうすれば、おそらくそのラベルでチェックアウトし、後でビルドを再作成できるでしょう。
完全なツリーにラベルを付ける理由は、実際のアプリケーション コード (ソース ツリー内の 1 か所にある) だけでなく、すべての共有アイテム (ツリー内の別の場所にある) も含めるためです。したがって、「アプリケーション A」のビルドが成功すると、ツリー全体にラベル「ApplicationA35」が付けられます。
ただし、このビルドを再作成し、展開する前に DLL バージョンを設定しようとすると、CruiseControl で生成されたビルド ラベルにアクセスできなくなるため、問題が発生する可能性があります。すべての CrusieControl ビルド ラベルがすべてのプロジェクトで一意であれば、ラベル付けに番号のみを使用できますが、そうではない (アプリケーション A と B の両方が同時にビルド 35 である可能性がある) ため、アプリケーション名をラベル。したがって、SourceSafe ラベルは「Application35」になります。 ビルド 35 をビルドした後で、ビルド 34 を再作成し、DLL バージョン番号を 1.0.0.34 に設定するにはどうすればよいでしょうか?
「リビジョン番号」ソリューション
たとえば、Subversion はチェックインするたびにソース ツリー全体のリビジョン番号を作成すると誰かが教えてくれました。 これはそうなのですか？SourceSafe に似たようなものはありますか? これが正しい場合、最新のリビジョン番号を取得し、CruiseControl サーバー上でビルドするという考えになります。その後、リビジョン番号を使用して DLL バージョン番号を設定できます (たとえば、「1.0.0.5678」)。必要に応じて Subversion のこの特定のリビジョンを取得すると、そのアプリケーションとすべての共有アイテムが含まれ、過去の特定のバージョンを再作成できるようになると思います。 それはうまくいきますか?また、SourceSafe を使用してもこれを実現できますか?
要約する
したがって、主な要件は次の 2 つです。
- できる ビルドおよびデプロイされた DLL のビルド/リビジョン番号を追跡します。
- できる 過去のリビジョン/ビルドを再構築し、そのビルドの実行可能ファイルに古いビルド/リビジョン番号を設定します (要件 1 を満たすため)。
では、これをどうやって解決しますか? あなたの好みのアプローチは何ですか? どうやって あなたはそれを解決しますか（それともまったく別のアイデアがありますか？）**詳細な回答をお願いします。**
おまけの質問 リビジョン番号とビルド番号の違いは何ですか?また、実際に両方が必要になるのはどのような場合ですか?
解決
あなたのスキームは健全であり、VSSで実現可能です（代替案を検討することをお勧めしますが、VSSは実際には時代遅れの製品です）。
「CI」ビルドの場合、バージョニングを実行します。 MSBuild コミュニティ タスク プロジェクト これには「バージョン」タスクがあります。通常、ソース ツリーには "Version.txt" があり、開発者が Major.Minor.Release.Revision 番号を制御している間、MSBuild タスクは "Release" 番号をインクリメントします (これが私のクライアントが望んでいた方法です)。必要に応じてリビジョンを使用できます。
その後、そのバージョンの AssemblyInfo.cs ファイルを編集するための「FileUpdate」タスクが実行され、EXE と「DLL」は目的のバージョンになります。
最後に、VSSLabel タスクはすべてのファイルに適切なラベルを付けます。
「再ビルド」ビルドの場合 - そのラベルからファイルを取得するように「Get」を変更し、明らかに「Version」タスクを実行しません（ビルドするバージョンを選択しているため）。その後、FileUpdate タスクはそのバージョン番号を使用します。
おまけの質問:
これらはすべて「どのように使用するか」です。私はビルド番号を使用します。つまり、ビルド番号を増分します。CI を使用している場合、非常に多くのビルドが存在しますが、その大部分はどこにもデプロイする予定がありません。
メジャーとマイナーは自明ですが、私は常に「ホットフィックス」インジケーターにリビジョンを使用してきました。私は「1.3」リリースを予定しています。これは実際には、たとえばバージョン 1.3.1234.0 の製品になります。1.4 の作業中にバグを見つけたので、1.3.2400.1 としてホットフィックスが必要です。1.4 の準備が整うと、1.4.3500.0 になります。
他のヒント
コメントに直接返信するよりも多くのスペースが必要です...
ありがとう！いい答えだ！違いは何でしょうか、たとえば、リチャード・ホールグレン（15時間前）など、転覆を使用してこれを解くより良いことは何でしょうか
VSS の問題はこの例とは何の関係もありません (ただし、「ラベル付け」機能は非効率的に実装されていると思いますが...)
VSS に関する問題のいくつかを次に示します。
1）分岐は基本的に不可能です2）共有チェックアウトは一般的に使用されません（私はそれで成功した少数の人々を知っています） - それは完全に信頼できません、ほとんどのショップにとっては、それは刻々と過ぎたタイムボムです。
4 の場合 - 問題は、VSS がファイル システム内で「フラット ファイル」として表されるリポジトリ全体によって実装されていることです。リポジトリが特定のサイズ (4GB だと思いますが、その数字には自信がありません) を超えると、「破損」の可能性が生じます。サイズが大きくなるにつれて、破損の可能性はほぼ確実になるまで増加します。
したがって、リポジトリのサイズを確認し、ギガバイトに達している場合は、VSS の置き換え計画を開始することを強くお勧めします。
とにかく、「VSS Sucks」でグーグル検索すると 30,000 件がヒットします...代替手段を使い始めたら、それが努力する価値があることがわかると思います。
- CC.net で成功したビルドにラベルを付けるようにする
- ソリューション内の各プロジェクトを、アセンブリとファイルのバージョン属性を含む共通の solutioninfo.cs ファイルにリンクします (各プロジェクトから Assemblyinfo.cs を削除します)。
- ビルドの前にクルーズ コントロールで msbuild regex replace (msbuild コミュニティ タスクから) を実行し、cc.net ビルド ラベル (msbuild タスクにパラメーターとして渡される) を使用してバージョン情報を更新します。
- ソリューションの構築、テストの実行、為替監視など
- 必要に応じて、ソリューション情報ファイルを元に戻します
その結果、cc.net で公開されたビルド内のすべてのアセンブリは、ソース コード リポジトリ内のラベルに準拠する同じバージョン番号を持つことになります。
UppercuT は、アプリケーションを分割するカスタム パッケージング タスクを使用してこれらすべてを実行できます。ソースのバージョン番号を取得するには、Subversion を考えるとよいでしょう。
始めるのもめちゃくちゃ簡単です。
http://code.google.com/p/uppercut/
ここにいくつかの良い説明があります: アッパーカット
