4

いくつかの独立したアプリケーションを使用して、かなり複雑なプロジェクトを実行しています。ただし、これらはいくつかの共有コンポーネントを使用します。だから私は以下のようなソースツリーを持っています。

  • 私のプロジェクト
    • アプリケーションA
    • 共有1
    • 共有2
    • アプリケーションB
    • アプリケーション C

すべてのアプリケーションには、プロジェクトと必要なすべての共有リソースをビルドする独自の MSBuild スクリプトがあります。これらのビルドは、CruiseControl 制御の継続的インテグレーション ビルド サーバーでも実行します。

アプリケーションがデプロイされると、複数のサーバーにデプロイされて負荷が分散されます。これは、異なるサーバーのそれぞれにどのビルド/リビジョンが展開されているかを追跡することが非常に重要であることを意味します (「1.0.0.68」など、DLL バージョンに現在のバージョンが必要です)。

何かが意図したとおりに機能しなかった場合にロールバックできるようにビルドされたリビジョン/ビルドを再作成できることも同様に重要です (そうです、それは起こります...)。現在、ソース管理に SourceSafe を使用していますが、その正当な理由を示すことができれば、変更することも可能です (SS 現在のところ、実際には問題なく動作しています)。

私たちが従おうとしているもう 1 つの原則は、さらに展開する統合サーバーによってビルドおよびテストされたコードのみであるということです。

「CrusieControl ビルド ラベル」ソリューション

上記を解決するためにいくつかのアイデアがありました。1 つ目は、継続的インテグレーション サーバーでプロジェクトをビルドし、ローカルにデプロイしてテストすることでした (現在はそれを実行しています)。おそらく知っているように、CruiseControl でビルドが成功するとビルド ラベルが生成されます。これを使用して、実行可能ファイルの DLL バージョンを設定できると思います (つまり、ビルド ラベル 35 は「1.0.0.35」のような DLL を作成します)。このビルド ラベルを使用して、完全なソース ツリーにラベルを付けるというアイデアもありました。その後、おそらくそのラベルでチェックアウトし、後でビルドを再作成できます。

完全なツリーにラベルを付ける理由は、実際のアプリケーション コード (ソース ツリーの 1 か所にある) だけでなく、すべての共有アイテム (ツリーの別の場所にある) も含めるためです。したがって、「アプリケーション A」のビルドが成功すると、ツリー全体にラベル「ApplicationA35」などのラベルが付けられます。

ただし、CruiseControl で生成されたビルド ラベルにアクセスできなくなるため、デプロイ前にこのビルドを再作成して DLL バージョンを設定すると、問題が発生する可能性があります。すべての CrusieControl ビルド ラベルがすべてのプロジェクトで一意である場合、ラベル付けに番号のみを使用できますが、そうではありません (アプリケーション A と B の両方が同時にビルド 35 である可能性があります)。ラベル。したがって、SourceSafe ラベルは「Application35」です。ビルド 35 をビルドしたら、ビルド 34 を再作成し、1.0.0.34 を DLL バージョン番号に設定するにはどうすればよいですか?

「改訂番号」ソリューション

たとえば、Subversion はチェックインのたびにソース ツリー全体のリビジョン番号を作成すると誰かが私に言いましたが、これは本当ですか? SourceSafe に似たようなものはありますか? これが正しければ、最新版を取得して CruiseControl サーバー上でビルドするときにそのリビジョン番号を取得するという考え方です。リビジョン番号は、DLL のバージョン番号 (たとえば、「1.0.0.5678」) を設定するために使用できます。その後、必要に応じて Subversion のこの特定のリビジョンを取得し、そのアプリケーションとすべての共有アイテムを含めて、過去の特定のバージョンを再作成できると思います。それは機能し、これも SourceSafe を使用して実現できますか?

要約する

したがって、主な要件は次の 2 つです。

  1. ビルドおよび展開された DLL のビルド/リビジョン番号を追跡できます。
  2. 過去のリビジョン/ビルドを再構築し、そのビルドの実行可能ファイルに古いビルド/リビジョン番号を設定できるようにします (要件 1 に準拠するため)。

では、これをどのように解決しますか？あなたの好みのアプローチは何ですか? また、それをどのように解決しますか? (または、まったく異なるアイデアをお持ちですか?) **詳細な回答をお願いします。**

おまけの質問リビジョン番号とビルド番号の違いは何ですか? また、両方が本当に必要になるのはいつですか?

4

4 に答える 4

8

あなたのスキームはVSSで健全で達成可能です（代替案を検討することをお勧めしますが、VSSは実際には時代遅れの製品です）。

「CI」ビルドの場合、バージョン管理を行い、「バージョン」タスクを持つMSBuild コミュニティ タスク プロジェクトを確認します。通常、ソース ツリーには "Version.txt" があり、開発者が Major.Minor.Release.Revision 番号を制御している間、MSBuild タスクは "Release" 番号をインクリメントします (これが私のクライアントが望んでいた方法です)。必要に応じてリビジョンを使用できます。

次に、そのバージョンで AssemblyInfo.cs ファイルを編集する「FileUpdate」タスクがあり、EXE と「DLL」は目的のバージョンになります。

最後に、VSSLabel タスクがすべてのファイルに適切なラベルを付けます。

「再構築」ビルドの場合、「取得」を変更してそのラベルからファイルを取得し、明らかに「バージョン」タスクを実行せず (ビルドするバージョンを選択しているため)、FileUpdate タスクはそのバージョン番号を使用します。

ボーナス質問:

これらはすべて「あなたがそれらをどのように使用したいか」です - 私はビルド番号を使用します。CI を使用している場合、非常に多くのビルドが作成されます。その大多数は、どこにも展開するつもりがありません。

メジャーとマイナーは自明ですが、私は常に「ホットフィックス」インジケーターにリビジョンを使用してきました。私は "1.3" リリースを予定しています - 実際には 1.3.1234.0 バージョンの製品になります。1.4 の作業中に - バグが見つかりました - 1.3.2400.1 としてホット フィックスが必要です。次に、1.4 の準備が整うと、1.4.3500.0 となります。

于 2008-09-12T00:47:55.197 に答える
3
  1. 成功したビルドに CC.net のラベルを付ける
  2. ソリューション内の各プロジェクトを、アセンブリとファイル バージョンの属性を含む共通の solutioninfo.cs ファイルにリンクします (各プロジェクトから assemblyinfo.cs を削除します)。
  3. ビルドでクルーズ コントロールを実行する前に、(msbuild コミュニティ タスクから) msbuild regex replace を実行し、cc.net ビルド ラベル (パラメーターとして msbuild タスクに渡される) を使用してバージョン情報を更新します。
  4. ソリューションの構築、テストの実行、FX COP など
  5. 必要に応じて、ソリューション情報ファイルを元に戻します

その結果、cc.net で公開されたビルドのすべてのアセンブリは、ソース コード リポジトリのラベルに準拠する同じバージョン番号を持つことになります。

于 2008-09-23T07:28:30.687 に答える
3

コメントが直接許可されているため、応答するよりも多くのスペースが必要です...

ありがとう！いい答えです！たとえば、SubVersion を使用してこれをよりよく解決するにはどうすればよいでしょうか?Richard Hallgren (15 時間前)

VSS の問題はこの例とは何の関係もありません (ただし、「ラベリング」機能は非効率的に実装されていると思います...)

VSS に関するいくつかの問題を次に示します。

1) 分岐は基本的に不可能です 2) 共有チェックアウトは一般的に使用されません (私は共有チェックアウトで成功した人を何人か知っています) 3) パフォーマンスが非常に悪いです - それは非常に「おしゃべり」です 4) リポジトリが非常に小さい場合を除きます- 完全に信頼性が低く、ほとんどのショップにとって時限爆弾のようなものです。

4 の場合 - 問題は、リポジトリ全体がファイル システムで「フラット ファイル」として表されることによって VSS が実装されることです。リポジトリが特定のサイズ (4GB だと思いますが、その数値に自信がありません) を超えると、「破損」する可能性があります。サイズが大きくなるにつれて、破損の可能性が高まり、ほぼ確実になります。

したがって、リポジトリのサイズを確認してください。ギガバイトに達している場合は、VSS の置き換えを計画し始めることを強くお勧めします。

いずれにせよ - 「VSS Sucks」のグーグルは 30,000 件のヒットをもたらします... もしあなたが別の方法を使い始めたなら - あなたはそれが努力する価値があることに気付くでしょう.

于 2008-09-12T21:36:13.607 に答える