1

この投稿の長さについてお詫び申し上げますが、適切な回答を得るために多くの情報を含める必要がありました。これが応答を妨げないことを願っています...

当店はこれまで、クラシックASPを使用してWebサイトをコーディングし、いくつかの新しいASP.NETサイトをWebサイトとして構成してきました。誰もが知っているように、これは、ソースファイル(* .asp、*。aspx、および* .aspx.vb(または* .aspx.cs))ファイルが開発サーバーと運用サーバーにそのまま展開されることを意味します。

構成管理プロセスは完全に手動で行われ(現在もそうです)、次の手順(要件)が含まれています。

  • 変更されたファイルのコピーを取り、アーカイブのために「リリース」フォルダに保存します。
  • 置き換えられる本番ファイルのコピーを取り、ロールバックを容易にするために「アーカイブ」フォルダーに保存します。
  • リリース後の問題を診断する際のコードレビューまたは一般的な参照のために、ソースファイルの前後の差分レポートを生成します。
  • 変更をコーディングした開発者は、製品リリースを実行する人ではありません。元の開発者は、追加のテストと実稼働展開のために、ソースファイルを別の開発者に渡す必要があります。

状況をより困難にするために(上記ではなく、以下で説明することで)、正式なリリーススケジュールには従いません。個々のバグまたは機能拡張が完了すると、それらはリリースされます。これは、1週間にサイトに複数のリリースを簡単に作成できることを意味します。特定のサイトが同じ日に個々のページに2つの異なるリリースを取得する可能性もあります。

参加して以来、チームをASP.NETWebアプリケーションやASP.NETMVCなどの新しいテクノロジに移行しようとしています。(Web以外のプロセスに使用されるスタンドアロンアプリケーションとコンソールユーティリティの責任も負っています...したがって、私のジレンマは依然として当てはまります。)

これらのテクノロジーとレガシーテクノロジーの違いは、プリコンパイルです。コードビハインドファイル(* .aspx.vb(または* .aspx.cs))を展開する代わりに、dllまたはexeが展開されます。このタイプの展開パッケージでは、いくつかの質問があります(問題??)。

  • ソースがコンパイルされたときに差分レポートを生成します。新しく変更されたソースファイルが開発者システムにある間、本番コピーはコンパイルされたコピーです。
  • 他のバグや機能拡張に関連する変更が特定のリリースに含まれていないことを確認してください。これは、元の開発者とリリースを実行する人の両方に適用されます。
  • 元の開発者が変更されたファイルを別の開発者に渡して、ビルド、テスト、および展開できるようにします。

これまで、これらのタイプのサイトとアプリケーションに取り組んでいるチームの開発者は私だけだったので、上記の競合や問題は存在しませんでした。(差異レポートの手順をスキップし、独自の展開を行います。)ただし、チームの他のメンバーにこれを採用し、バグと拡張タスクのより良い配布を可能にするように促そうとしています。

現在VSSを使用していますが、TFSへの移行を推進しています(おそらく成功するでしょう)。私が持っているいくつかのアイデアは

  • 開発者がデプロイメントを行うために使用する別のビルドシステムをセットアップします。これにより、2つの問題が解決されます。(1)開発者間でのVisual Studioおよびその他のライブラリのバージョン/パッチの違い、および(2)リリースを実行する人が別の変更のためにファイルをローカルでチェックアウトした場合。(もちろん、これはビルドシステムと元の開発者の違いを保証するものではありませんが、少なくともそれはリリースが一貫した構成からのものであることを意味します。

  • ラベルを使用して、変更されたファイルのみにタグを付けます。私の問題は、変更されたファイルを識別(およびビルド用にプルダウン)できますが、ビルドに含める必要があるが変更されていないファイルを識別するにはどうすればよいかということです。繰り返しになりますが、リリースされていない変更に関連するチェックインされたファイルを含めないという考え方です。

  • ラベルを使用して、リリースのすべてのファイル(変更されたファイルと変更されていないファイル)にタグを付けます。これに関する私の問題は前の問題と似ています...関係のない変更のために別の開発者によってチェックインされたファイル(たとえば休暇に行った)がラベル付けされてこのビルドに含まれていないことを確認するにはどうすればよいですか?

  • ラベルを使用して、ラベル付きバージョンと以前にラベル付けされたバージョンの差異レポートを生成するスクリプトを作成できる可能性があります。プロセスが適切に機能する場合、特定のリリースに含まれる変更が正確に反映されるはずです。

他のアイデア、懸念事項、興味のあるポイントはありますか?私にはプロセスの柔軟性がありますが、いくつかの要件(相違点レポートや、相違点を簡単に表示し、開発者/デプロイヤーを分離する方法など)はほとんど手に負えません。

あなたがこれに関して提供することができるどんな助けにも本当にありがとう。

4

2 に答える 2

0

たとえば、VS2003とVS2010での私の経験に基づくと、プロジェクトの構造が異なり、VSに変換を実行させると、多くのリファクタリングが必要になるか、使用できないソリューションになることがよくあります。そうは言っても; すべてをTFS2010に移行できる場合、それを処理する1つの方法は、ソリューションごとに異なるプロジェクトをセットアップし、異なるリリースのTFS組み込みバージョン処理を使用することです。ビルドサーバーをセットアップして、ナイトリービルドをスケジュールすることもできます。ビルドに問題がない場合は、このバージョンをテストに、そして最終的には本番環境にプッシュできます。TFSはVSSとはまったく異なり、チームに焦点を合わせた開発を行うことができるという点で間違いなく大きなアップグレードであるため、TFSについてよく読んでおく必要があります。

PS TFSには、Sharepointとの統合が非常に優れており、あなたとあなたのチームがすべてのバグとタスクを追跡するのに役立ちます。

于 2011-08-12T02:27:26.587 に答える
0

コードのさまざまなバージョンを追跡し、非常に高速なリリースサイクル(毎日)と長期的な拡張機能を管理できるようにするために、TFSでブランチを使用できます。

分岐についてはたくさんの情報がありますが、一般的に私は物事をシンプルに保つように努めています。たとえば、「リリース」と呼ばれるブランチと「開発」というブランチがあります。誰もが開発ブランチで作業しますが、本番環境にデプロイされるコードは、リリースの直前にリリースブランチにマージされます。

このブログ投稿では、プロセスについて説明しています。

http://team-foundation-server.blogspot.com/2008/01/how-we-branch-our-code-in-tfs.html

于 2011-08-12T12:51:31.877 に答える