不完全な機能を回避しながら、モバイルアプリでの機能のフラグ付けのベストプラクティス？
あるバージョンの機能フラグの背後にある不完全な機能と、次のバージョンのフラグの背後にある完了した機能を含むモバイルアプリをリリースするシナリオを最も適切に処理する方法を考えています。以前のバージョンのユーザーには、不完全な機能に遭遇する。
IOSアプリ用にWeatherという機能を開発しているとしましょう。リリース1.1.0の不完全なバージョンのWeather機能をApp Storeにリリースしました-show-weatherという機能フラグの後ろに置き、falseバックエンド。次に、完成したWeather機能を備えたアプリのバージョン2.0.0をリリースし、バックエンドでshow-weatherをtrueに切り替えます。ええとああ！ 1.1.0がまだインストールされているユーザーには、Weather機能の不完全なバージョンが表示されるようになりました。
これを緩和するためのアイデア：
- アプリは機能フラグを取得するときにバージョン番号をバックエンドに送信し、アプリのバージョンが低すぎる場合はバックエンドが
falseを送信します - アプリの実装は、バージョン
1.1.0の機能フラグサービスからの応答をモックしてfalseを返し、モックをバージョン2.0.0の実際のバックエンド統合に置き換えます - フラグが立てられた機能が完了すると、ユーザーはアプリをアップグレードする必要があります
- 開発者は不完全な機能をマージしません-機能フラグは完全に実現された機能の外観を切り替えるためにのみ使用されます
後者の2つのオプションは最適ではないようです。ユーザーを頻繁にjarしたくありません。また、開発者が長期実行ブランチを維持する必要はありません。
最初の2つは機能するかもしれませんが、バックエンドまたはフロントエンドで何かが簡単に忘れられる可能性があるように見えます。
このシナリオに最適なソリューションは何ですか？
古いバージョンのクライアントは、気象データを処理できません。したがって、サーバーが何を言っても、それを試してはいけません。したがって、ほとんどのコードが存在するが機能しないことが必要な場合は、クライアント自体に、コンパイル時に設定される機能フラグが含まれている必要があります。
クライアント機能フラグが新しいバージョンで天候データを許可（コンパイル時に変更）し、サーバーがサポートしている場合、クライアントは天候データを表示します。
フラグの代わりに、バックエンドは、機能を使用するためにクライアントが持っている必要があるアプリのバージョンを返すことができます。例："show-weather":">=2.0.0"は、バージョン2.0.0以降のクライアントがこの機能を使用できることを示すために使用できます。
問題は、なぜ実行時機能フラグの背後にある不完全な機能が必要なのかです。
プロダクションに対応していないより大きな機能を開発している限り、「プロダクション」では完全に無効にし、ローカル開発環境でのみ有効にする必要があります。そして、それは、さまざまな開発者および製品リリースのビルドをサポートするビルドプロセスと組み合わせて、コンパイル時機能フラグの方が適しているシナリオです。これにより、「開発環境」ビルドでフラグを有効にしたり、App Storeにリリースされたバージョンでフラグを無効にしたりできます。
もちろん、後で「バージョン2.0.0」で機能を無効/有効にする場合は、同じ機能に追加のランタイム機能フラグを設定することもできます。ただし、「1.1.0」では、リリースされたバージョンではコンパイラによって機能が無効化されているため、本番環境で誤ってアクティブにすることはできません。