1

私は最終的に、チームの展開プロセスを完全に突き止めることにしました。私たちにとって最後に残っている問題は、データベースとランタイム データの移行/管理の管理です。多くの例がありますが、以下に 2 つの例を示します。

  • 新しい「アップロード」機能をリリースする場合、アップロード ディレクトリを自動的に作成し、権限を設定します。以降のリリースでは、存在/許可を検証します - 永久に、自動的に。
  • データベース内の値 (「サインアップ」のアカウント ステータスなど) が無効になった場合、一連のビジネス ルールに従って、データベース内のデータを適切な値に自動的に移行します。

私がコードを管理および展開するのと同じように、開発者がこれらの変更を管理および展開できるようにするフレームワークを実装することに関心があります。

最初の質問は次のとおりです。1. この機能を提供するツール/フレームワークは何ですか?

一般に、これはどの言語やプラットフォームでも問題になるようです。私の特定のケースでは、データベースの抽象化に Fluent NHibernate を使用する .NET MVC2 アプリケーションをデプロイしています。NHibernate の SchemaUpdate をトリガーするツールを既にデプロイ プロセスに使用しています。これは素晴らしいことです。

この問題に独自の方法で対処するために構築したのは、特定の抽象クラス (Deployment) から継承するクラスのターゲット アセンブリをスキャンするツールです。その抽象クラスは、アプリケーションのコードベースのコンテキストで、独自の任意の展開コードをオーバーライドして実装できるフックを公開します。Deployment クラスはバージョン管理メカニズムも提供し、ツールは特定の実行中のアプリの現在の「展開バージョン」を管理します。次に、カスタム NAnt タスクがこれを NAnt 展開スクリプトと結び付け、適切なタイミングでフックをトリガーします。

これはうまく機能しているようで、私の目標を満たしています - しかし、これが私の牛肉であり、私の 2 番目の質問につながります。もしそうなら、あなたは私にそれを指摘できますか?3. 誰かがこの道を歩み始め、このアプローチの問題について洞察を持っていますか?

最後に、このようなものが存在するが .NET プラットフォームには存在しない場合は、私に知らせてください。自分のソリューションをゼロから始めるよりも、既知のソリューションを移植することに興味があるからです。

皆様、ありがとうございました。フィードバックに感謝します。

4

1 に答える 1

0

各メジャー リリースには、必要な正確な要件を備えた環境を作成するためのスクリプトがあります。

マイナー リリースの場合は、さまざまなリリースに分割され、環境を段階的に変更するスクリプトを作成します。これにはいくつかの大きなメリットがあります

  1. スクリプトを読み、それをリリース ノートや変更ログと照合することで、時間の経過に伴う環境への変更を確認できます。
  2. 最新のメジャー スクリプトと最新のマイナー スクリプトを実行することで、まったく新しい環境を作成できます。
  3. 特定のマイナー リリースで停止するように指定することで、(おそらくテスト目的で) 以前のバージョンの新しい環境を作成できます。
于 2011-03-03T15:20:15.237 に答える