1

結合された Azure Web サイト (コントローラーと ApiController の両方を含む) を、分割された Web アプリと API アプリに移行しています。それを MyApp と呼びましょう。

MyAppDevApi、MyAppTestApi、および MyAppProductionApi API アプリを (異なる App Services で) 作成して、3 つの環境をホストし、ある環境から別の環境にコードを昇格させることを想定しています。

これまでのところ、私は始めたばかりなので、MyAppDevApi にのみデプロイしました。

UI のみのプロジェクトで API アプリの参照を開始しAdd/Azure API App Client、それを MyAppDevApi にポイントすると、AutoRest を使用してコード内にクラスが作成されます。これらのクラスはすべて、MyAppApi だけでなく、MyAppDevApi という名前になりました。これは、すべての環境にデプロイするコードの実際の名前空間です。明らかに、それをチェックインすることはできません...どうすればテストと製品を通じてそれを促進できますか?

この名前を参照する Swagger JSON には何もないため、AutoRest 側にある必要があります (と思います)。

API アプリでのこの複数環境でのプロモーションの問題に対処するための戦略または回避策を思いついた人はいますか?

編集

これまでのところ、私が思いついた最善の方法は、Swagger を API アプリからローカル ファイルにダウンロードすることです (ここでも、API アプリの名前ではなく、元のコードの名前空間のみが含まれています)。 Web アプリにインポートします。これにより、期待どおりの名前を持つクラスが Web アプリに生成されます。

問題は、生成された MyAppApi.cs ファイルの _baseUri プロパティを編集して AppSetting からプルし、異なる web.config.dev、.test、.prod を用意してから、web.config 変換を行う必要があることです。つまり、それは機能しますが、API アプリのインターフェイスを変更するたびに再生成されます...そして、_baseUri をもう一度変更することを忘れないでください...そして、誰かがいつか忘れるでしょう.これを実行してから、本番環境にデプロイします。それは本当に、本当に壊れやすいです。

それで...誰かもっと良いアイデアがありますか?

4

2 に答える 2

0

環境ごとに 1 つずつ、3 つの異なるアプリを作成している理由がよくわかりません。1 つのアプリケーションで十分であり、環境ごとに web.config 変換を使用します。これは、私がすべてのアプリを実行する一般的な方法であり、正常に動作します。

web.config 変換を適用する方法に関する情報は、こちらで見つけることができます。これは、状況に役立つ場合があります。

それが役立つことを願っています。

于 2015-10-15T01:04:42.220 に答える