3

短い形式の質問とその後の説明パッチを作成し、dotnetアプリケーションのいくつかのバグ修正のためにビルドで変更されたファイルのみを含めたいと思います。パッチは、SVN、Cruisecontrol.net、msbuildを含む継続的インテグレーションプロセスで自動的にビルドされる必要があります。

ここにシナリオがあります。継続的インテグレーションを使用してリモートサーバーで実行される.netアプリケーションを維持したいと考えています。ソースコードはSVNにあり、DEV、QA、PRODの3つの異なるリポジトリがあります。私たちの開発者は、ほぼ毎日新しいバグ修正を行い、最初のテストと満足の後に変更を開発リポジトリにマージします。特定の問題が解決された後、または機能が追加された後のコードは、QAリポジトリにマージされます。QAコードは、QAマシンで手動で作成およびテストされます。QAテストの後、それをPRODにマージします。これにより、QAは、手動で置換または変更する必要のあるファイルの新しいパッチも作成します。次に、パッチがステージングサーバーにデプロイされます。完全になるまでテストされ、パッチが実際のリモートサーバーに展開されます。

継続的インテグレーションを求めて、CruiseControl.netとmsbuildを組み合わせてプロセスを実行しようとしています。このプロセスは、QAビルドからパッチを自動的に生成する必要がある段階まで有効です。パッチが生成されたら、それらをftpサーバーに配置し、そこからステージングサーバーにダウンロードしてテストします。問題、つまり新しいビルドからのパッチの生成には、いくつかの側面があります。アプリケーションのソリューションファイルには多くのプロジェクトがあり、dllはpostbuildイベントを使用してスタートアップアプリのbinフォルダーにコピーされます。したがって、実際のアプリケーションには特定のディレクトリ構造があり、それ自体は、多かれ少なかれ互いに独立している6つのソリューションの組み合わせです。

パッチを作成しようとしている方法は、svnのログを検索して、変更されたファイルを見つけることです。次に、プロジェクト名を見つけて解析しています。次に、アプリケーションのすべてのファイルを含むマッピングファイルを使用して、リリースに含まれる特定の方法で、そのプロジェクトのbinディレクトリからパッチフォルダーにすべてのファイルをコピーします。

ですから、svnとcruisecontrol.netがあれば、パッチを作成するためのはるかに優れた、またはより簡単な方法を誰かが提案できますか？またはそれを行うための他のオープンソースツール。

問題が明確であることを願っています

4

3 に答える 3

3

このプロセス全体は、一般に、確立されたベストプラクティスに反します。正当な理由があれば、これは必ずしも悪いことではありませんが、ここではわかりません。

基本的に、本番環境の安定性を確保するためにQAおよびDEV環境を使用していません。さらに悪いことに、さまざまなソースツリーを使用してそれらのコードを構築します。これにより、展開プロセスに障害が発生する可能性のある新しいポイントが導入されます。

これにアプローチする標準的な方法は、単一のSVNコードツリーを持つことです-QAにリリースされたときにバージョンにタグを付け（すでにビルドされたバイナリを使用して！）、PRODにリリースしたときに再度タグ付けする可能性があります。バイナリを再構築するのではなく、実際にテストしたものを使用してください。

于 2012-09-04T08:31:53.793 に答える
1

Msbuildタスクが再構築ではなくビルドを実行している場合、影響を受けていないdllの日付/時刻は変更された日付に変更されません。

次の理由でこれをお勧めします。

  • Msbuildは、変更の影響を受けたアセンブリの変更日を更新します-つまり、インターフェイスの変更ですか？
  • アセンブリはデプロイしたいものなので、変更のソースではなく、これを確認してください。それ以外の場合は、ビルドプロセスを知る必要があります（変更されません）-つまり、ソースファイルの場所、参照など。

デプロイメントには、変更日>=BuildDateであるビルドディレクトリからのdllが含まれるだけです。

于 2012-09-04T05:51:41.240 に答える
0

推奨されるビルドとパッチのプロセスについて、skolimaに同意します。最初のタグと変更からパッチを作成してから、すべての環境に展開する必要がある新しいバージョンを作成する必要があります。

私の会社では、この方法を使用しています：

  1. 成功した各ビルドは、CIサーバーによって自動的にタグ付けされます
  2. 特定のバージョンにパッチが必要な場合、プログラマーはタグ付けされたバージョンをコピーしてチェックアウトし、修正を適用します
  3. 次に、CIサーバー上に特定の「パッチ」ビルドがあります。これは、「パッチ」フラグを使用した通常のビルドとまったく同じことを行い、パッチが適用されたソースを指します。

展開ターゲットは同じで、ビルドプロセスは同じで、ソースのみが変更されます。

さらに、パッチは個別にビルドされますが、通常のビルドとして扱われるため、CI上で独自のビルド履歴があります。

とにかく、CIを介して2つのリポジトリ間のパッチ適用プロセスを自動化する場合は、これを行うために特定のMSBuildタスクを作成する必要があります。それらの間の変更をマージするか、SVNのdiff＆patchコマンドを確認することができます。

于 2012-09-04T09:29:59.493 に答える