2

状況-WCFレイヤーを備えた.netmvcソリューションがあります。このソリューションには、DLLにコンパイルされる約20の奇妙なプロジェクトがあります。サイトはSQLServer2008で実行されています。SQLスクリプトはバージョンとしてソリューションフォルダーに保持されます。したがって、SQLスクリプトがあります。バージョン1.0.0.0から、最新の3.0.0.1と言えます。

ソリューションはTFSでソース制御され、TFSを使用して作業項目やバグなどを管理します。SQLスクリプトファイルもTFSにあります

質問-質問は、アセンブルされたバージョン番号、つまりdllも必要かということです。私たちのDLLは、mvcアプリの実行時にのみ、外部に公開されることはありません。WCFを外部クライアントに公開することはありません。これもmvcアプリで使用されるだけです。

デプロイプロセスは、単純に最新のdbに対する最新のコードであるため、デプロイするときに、dbのバージョンを確認し、ツールを実行して、ソリューションのdbプロジェクトにある最新バージョンにアップグレードします。

シニアアーキテクトの1人は、アセンブリでもバージョン番号を維持する必要があると言っています。コードにバージョン番号は必要ないと言っています。TFSがそれを管理しているからです。リリースするときは、最新のアセンブリ/デプロイパッケージを使用して最新のコードをデプロイするだけです。

アセンブリが外の世界にリリースされていない限り、アセンブリのバージョンに出くわすことはありません（私が何を意味するかを知っている場合）

提案していただけますか...また、特定のDBがどのバージョンであるかを知るために、バージョン番号だけの機能開発は行っていないことに注意してください。

4

2 に答える 2

1

バージョンを知り、再確認できるというセキュリティを望んでいます。公開プロセスに問題があった場合、または公開の問題と思われるバグが明らかになった場合は、できるだけ早く除外したいと思います。また、実際に行うよりも議論や検討に多くの時間を費やしてきたので、実装はとても簡単だと思います。私が考えることができる欠点はありません。

于 2013-01-22T15:43:53.147 に答える
1

私の仕事での同様のプロジェクトでは、バージョン番号を使用しています。

バージョン管理システム（VCS）に対してコミットするたびに、CIサーバー（TeamCity）は、バージョンが「LATEST」に設定された新しいアーティファクトを構築します。「LATEST」のビルドが成功すると、テスト環境に自動的にデプロイされます。理論的には、この「最新」バージョンを本番環境にデプロイすることもできますが、そうではありません。

新しいバージョンを本番環境にデプロイする場合は、バージョン管理されたリリース（1.4.7など）を作成する別の手動ビルドジョブを実行します。ビルドジョブは、現在のコードベースのSVN「タグ」も作成します。DLLに適切なバージョンを持たせるために、TeamCityのAssemblyInfoPatcher機能を使用します。AssemblyInfo.csこのように、プロジェクトのファイルを常に手動で更新する必要はありません。代わりに、彼らは常にこのようなプレースホルダーバージョン情報を持つようになります...

[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion("1.0.0.0")]

これらの番号は、TeamCityによるビルド中に自動的に更新されます。バージョン管理されたアーティファクト（対応するSQLスクリプトを含む）は、コードベースのすべてのバージョンを保持する「Releases」ディレクトリに保存されます。

さて、これはすべてやり過ぎのようですよね？あまり。

これにより、次のようなメリットがあります...

  • デプロイプロセスはwget、バージョン番号を一覧表示し、バージョンが一致していることを表明する監視ページに対して実行します（デプロイされていると予想されるバージョンとサーバーで現在実行されているバージョン）。これにより、デプロイプロセスが適切に機能したことを確信できます。
  • バージョン管理されたリリース（製品リリース候補）にバグが見つかった場合、checkoutリリースを危険にさらす可能性のあるトランク上の他の変更を心配することなく、タグをSVNし、修正を適用して、新しいリリースを作成できます。常に「解放可能」であり続けることは困難です。これにより、解放可能である必要はなくなります。誤解しないでくださいが、それには利点があります。
  • バージョン管理されたリリースで問題が見つかったが、すぐに解決できない場合は、機能することがわかっている古いアーティファクトをいつでも再デプロイできます。デプロイされたリリースを古いバージョンに戻すことができることで、2、3の機会で間違いなく私たちを救うことができました。
  • 調査が必要なバグが本番環境で見つかった場合は、同じバージョンのアーティファクトを任意のテスト環境に自由にデプロイして、本番環境の外部で問題を再現できるようにします。

私が現時点で忘れている利点はおそらくもっとありますが、上記のリストは、適切なバージョン管理がテーブルにもたらすことができる力の一般的な考えを与えるはずです。

私がお勧めするのは、20以上のプロジェクトのバージョンファイルを継続的に手動で更新することです。これは多くの忙しい仕事のように思えますが、人為的ミスが発生しやすいため、ほとんどの場合時間の無駄です。何をするにしても、それを自動化し、結果を確認します。

于 2013-01-22T16:05:42.693 に答える