正常なモデル駆動型アプリ フォーム ALM の維持管理
[アーティクル] 2023/04/08
2 人の共同作成者
フィードバック
この記事の内容
新しいフォームを作成し、複数の管理ソリューションを使用して維持する
新しいフォームを作成し、パッチとアップグレードを使用してカスタマイズを行います
既存の管理フォームをカスタマイズし、複数の管理ソリューションを使用して維持する
既存の管理フォームをカスタマイズし、パッチとアップグレードを使用して維持する
複数の開発環境にわたる新しいフォームの、アンマネージド ソリューションとカスタマイズの維持
複数の開発環境にわたる既存のフォームの、アンマネージド ソリューションとカスタマイズの維持
完全フォームと差分フォーム XML
さらに 3 個を表示
この記事では、モデル駆動型アプリ ソリューションでフォームをカスタマイズするための健全なアプリケーション ライフサイクル管理 (ALM) を実装および実践する方法のさまざまなシナリオに関する情報を提供します。
次のセクションでは、フォームのマージのしくみと、カスタマイズを維持する方法について説明します。 モデル駆動型アプリ フォームの ALM を成功させるためのレコメンデーションを含む基本的な開発シナリオについては、次の各セクションで詳しく説明します。 すべてのシナリオには、ソリューションまたはモデル駆動型アプリを更新するときに適切な ALM プロセスを実装するのに役立つ手順が含まれています。
新しいフォームを作成し、複数の管理ソリューションを使用して維持する
次の手順に従って、このシナリオの正常なフォーム ALM を実装します。
開発環境で FormA という名前の新しいフォームを作成し、フォームのカスタマイズを実行します。
開発環境で新しいソリューション (下図ではソリューション A という名前) を作成してください。これはアンマネージド ソリューションとなり、新しいフォームを追加します。 ソリューションを管理対象としてエクスポートします。 この手順では、フォームの完全な FormXml をエクスポートします。
テスト環境で、手順 2 から管理ソリューションをインポートします。これにより、テスト環境で FormA が作成されます。 下の図では、FormA がテスト環境で作成され、フォームの UI にはソリューション A がフォームに追加された Field1 と Field2 が表示されます。
新しい開発 (ソース) 環境を使用して手順 1 で作成したフォームをさらにカスタマイズする場合は、手順 2 で作成した管理されたソリューション A をインポートし、開発インスタンスの FormA が管理された状態であることを確認します。 下の図に示すように、管理されたソリューション A は開発環境にインポートされ、フォームはカスタマイズされてアクティブなカスタマイズが作成されます。 次に、FormA を新しいアンマネージド ソリューションに追加し (図内のソリューション B )、開発環境から管理ソリューションとしてエクスポートされます。 このステップでは、フォームの差分 (diff) FormXml をエクスポートします。
テスト環境で、手順 4 から管理ソリューション (ソリューション B ) をインポートします。 下の図に示すように、ソリューション B は新しい Field3 を FormA に追加し、Field2 を削除しています。これは、ソリューション A によって追加されました。マージ後、テスト環境のフォームの UI では、フォームに Field3 と Field1 が表示されますが、Field2 は表示されません。
次の図に示すように、基本ソリューション (ソリューション A ) が管理されていない状態の開発環境から複数の管理ソリューションを作成することは、健全な ALM プラクティスではありません。 これは、管理されていないフォームに対して別のアンマネージド ソリューション (ソリューション B ) を作成すると、上記の有効なシナリオに示されているように、FormXml は diff FormXml ではなく、完全な FormXml としてエクスポートされるためです。 その後、列の削除などの変更は有効になりません。
次の手順に従って、このシナリオの正常なフォーム ALM を実装します。
開発環境で FormA という名前の新しいフォームを作成し、フォームのカスタマイズを実行します。
ソリューション (下図ではソリューション A という名前) を作成してください。これはアンマネージド ソリューションとなり、新しいフォームを追加します。 ソリューションを管理対象としてエクスポートします。 この手順では、フォームの完全な FormXml をエクスポートします。
テスト環境で、手順 2 の管理ソリューションをインポートします。これにより、テスト環境でフォームが作成されます。 下の図では、FormA テスト環境で作成され、フォームの UI にはソリューション A がフォームに追加された Field1 と Field2 が表示されます。
手順 1 で作成したフォームをパッチを使用してさらにカスタマイズする場合は、ソリューション A が管理されていない状態にあり、ソリューションのパッチを作成してフォームをカスタマイズする同じ環境を使用してください。 次に、パッチをマネージド ソリューションとしてエクスポートします。 この手順では、フォームの完全な formXml をエクスポートします。
テスト環境で、手順 4 から管理パッチ ソリューションをインポートします。 下の図に示すように、ソリューション A パッチは新しい Field3 を FormA に追加し、ソリューション A によって追加された Field2 を削除します。
注意
フル formXml を含むパッチは、常にパッチの作成元であるベースレイヤーと比較され、ベースレイヤーと現在のパッチの間にある中間パッチは無視されます。 結果として、 Field2 はベースレイヤーソリューション A に存在しているために削除され、除去が検出されます。 一方で、Field3 は今回のパッチソリューションで追加されたもので、その後のパッチで削除することはできません。 したがって、パッチソリューションを介して追加されたフィールドは、付加的な性質を持っています。
手順 1 で作成したフォームをアップグレードを使用してさらにカスタマイズする場合は、ソリューション A が管理されていない状態にあり、ソリューション A をクローンして、アップグレード ソリューションを作成し、フォームをカスタマイズする同じ環境を使用してください。 次に、管理ソリューションとしてソリューション A をエクスポートします。 この手順では、フォームの完全な FormXml をエクスポートします。
テスト環境で、手順 6 から管理されたソリューション A アップグレードをインポートします。 下の図に示すように、ソリューション A アップグレードは新しい Field4 を FormA に追加し、Field2 を削除しています。これは、ソリューション A によって追加されました。フォームがインポートからマージされた後、テスト環境のフォームの UI では、フォームに Field1 、Field3 そして Field4 が表示されますが、Field2 は削除されます。
既存の管理フォームをカスタマイズし、複数の管理ソリューションを使用して維持する
次の手順に従って、このシナリオの正常なフォーム ALM を実装します。
この例では開発環境で FormB という名前の既存の管理フォームを編集し、フォームでカスタマイズを実行します。 ソリューション A は、開発環境のフォームにすでにインストールされている管理ソリューションであることに注意してください。
新しいソリューション (下図ではソリューション B という名前) を作成してください。これはアンマネージド ソリューションであり、FormB を追加します。 ソリューションを管理対象としてエクスポートします。 このステップでは、フォームの差分 (diff) FormXml をエクスポートします。
テスト環境で、手順 2 の管理ソリューションをインポートします。これにより、フォームの 2 番目のソリューション レイヤーが作成されます。 下の図では、FormB がテスト環境のソリューション A とソリューション B から変更をマージし、フォームの UI では、フォームに Field1 と Field3 が表示されますが、Field2 は表示されません。これは、ソリューション B から削除されています。
新しい管理ソリューションを使用して手順 1 でカスタマイズしたフォームをさらにカスタマイズする場合は、FormB が管理された状態になっている新しい開発環境を使用してください。 下の図に示すように、ソリューション A とソリューション B の管理ソリューションは新しい開発環境にインポートされます。 FormB はカスタマイズされてアクティブなカスタマイズが作成され、その後、新しいソリューション (図の ソリューションC ) に追加して、管理ソリューション としてエクスポートできます。
テスト環境で、手順 4 から管理されたソリューション C をインポートします。 下の図に示すように、ソリューション C は新しい Field4 を FormB に追加し、Field3 を削除しています。これは、ソリューション B によって追加されました。テスト環境のフォームの UI では、フォームに Field1 と Field4 が表示されますが、Field2 とField3 は表示されません。
次の図に示すように、同じフォームに対して作成した別のアンマネージド ソリューションを含む開発環境から複数の管理ソリューションを作成することは、健全な ALM プラクティスではありません。 ソリューション B が管理されていない状態であることに注意してください。 FormB に対して別のアンマネージド ソリューション (ソリューション C ) を作成すると、上記のシナリオの手順 4 に示すように、FormXml は diff FormXml としてエクスポートされます。 しかし、FormB にはソリューション B からの変更も含まれており、新しい変更によって上書きされます。
たとえば、次の図に示すように、Field3 はソリューション B で FormB に追加されます。しかし、ソリューション B が管理されていない状態で、この環境に新しいソリューション C を作成し、Field3 を削除すると、Field3 も開発環境から削除されます。 Field3 は、この列の追加と削除の変更が同じアクティブな レイヤー で行われたため、ソリューションがエクスポートされるときにdiff FormXmlで追跡されません。 つまり、管理ソリューション C がテスト環境にインポートされた場合でも、フォームは Field3 をレンダリングします。なぜなら、diff FormXml はそれを削除済みとして記録しないためです (上記の正常なフォーム ALM シナリオの手順 5 で削除されたのと同様)。 この方法でフォームのカスタマイズを実行すると、開発環境がテスト環境と矛盾することになります。
既存の管理フォームをカスタマイズし、パッチとアップグレードを使用して維持する
次の手順に従って、このシナリオの正常なフォーム ALM を実装します。
この例では開発環境で FormB という名前の既存の管理フォームをカスタマイズし、フォームでカスタマイズを実行します。 ソリューション A は、開発環境のフォームにすでにインストールされている管理ソリューションであることに注意してください。
ソリューション (ソリューション B という名前) を作成してください。これはアンマネージド ソリューションであり、FormB を追加します。 ソリューションを管理対象としてエクスポートします。 この手順では、フォームの diff FormXml をエクスポートします。
テスト環境で、手順 2 から管理ソリューション B をインポートします。これにより、フォームの 2 番目のソリューション レイヤーが作成されます。 下の図では、FormB がテスト環境のソリューション A とソリューション B からマージされた変更を取得します。 さらに、FormB の UI ではフォームに、ソリューション B によって削除された Field1 と Field3 が表示されますが、Field2 は表示されません。
パッチ ソリューションを使用して手順 1 でカスタマイズしたフォームをさらにカスタマイズすると、ソリューション B が管理されていない状態で存在する手順 1 と同じ開発環境を使用できます。 下の図に示すように、ソリューション A は管理された状態にあり、ソリューション B は管理されていない状態です。 フォームがさらにカスタマイズされ、フォームをこのソリューションに追加し、管理パッチ ソリューションとしてエクスポートして、ソリューション B にパッチを作成します。 この手順では、diff FormXml をエクスポートします。
テスト環境で、手順 4 から管理パッチ ソリューション B をインポートします。 下の図に示すように、ソリューション B パッチ は新しい Field4 を FormB に追加し、ソリューション B によって追加された Field3 を削除します。
注意
パッチは本質的に付加的なものであり、列などのコンポーネントをフォームから削除することはできません。 そのため、Field3 はフォームから削除されません。 テスト環境のフォームの UI に Field1 、Field3 、および Field4 が表示されますが、Field2 は表示されません。
手順 1 で作成したフォームをアップグレードを使用してさらにカスタマイズする場合は、ソリューション B が管理されていない状態にあり、ソリューション B をクローンして、アップグレード ソリューションを作成し、FormB をカスタマイズする同じ環境を使用してください。 アップグレードをマネージド ソリューションとしてエクスポートします。 この手順では、フォームの diff FormXml をエクスポートします。
テスト環境で、手順 6 から管理ソリューション B アップグレード ソリューションをインポートします。 下の図に示すように、ソリューション B アップグレード は新しい Field5 を FormB に追加し、Field3 を削除しています。これは、ソリューション B によって追加されました。テスト環境のフォームの UI では、フォームに Field1 、Field4 および Field5 が表示されますが、Field2 と Field3 は削除されます。
複数の開発環境にわたる新しいフォームの、アンマネージド ソリューションとカスタマイズの維持
次の手順に従って、このシナリオの正常なフォーム ALM を実装します。
開発環境 1 で FormA という名前の新しいフォームを作成し、フォームのカスタマイズを実行します。
ソリューション (下図ではソリューション A という名前) を作成してください。これはアンマネージド ソリューションとなり、新しいフォームを追加します。 ソリューションをアンマネージドとしてエクスポートします。 この手順では、フォームの完全な FormXml をエクスポートします。
開発環境 2 で、手順 2 からアンマネージド ソリューションをインポートします。これにより、開発環境 2 にフォームが作成されます。 下の図では、FormA が作成され、フォームの UI にはソリューション A がフォームに追加された Field1 と Field2 が表示されます。
開発環境 2 でフォームをさらにカスタマイズし、Field3 という名前の付いた新しい列を追加するなど、環境でアクティブなカスタマイズを行います。 FormA に フィールド1 、 フィールド2 、 が表示されるようになりました。フィールド3 。
開発環境 1 で、Field4 を追加することにより、さらにフォームをカスタマイズします。 開発環境 1 のフォームの UI に、Field1 、Field2 、および Field4 が表示されます。
アンマネージド ソリューション A を、手順 5 で行った変更を使用してエクスポートします。 この手順では、フォームの完全な FormXml をエクスポートします。
開発環境 2 で、手順 6 からアンマネージド ソリューション A アップグレードをインポートします。 インポートするソリューションには、FormA の完全な FormXml が含まれているため、開発環境 1 で行われたアクティブなカスタマイズを上書きします。 そのため、フォームには Field1 、Field2 、および Field4 のみが表示されますが、開発環境 1 で行われた追加のアクティブなカスタマイズであった Field3 は表示されません。 この動作は、フォームの完全な FormXml を持つアンマネージド ソリューションのインポートで発生します。
複数の開発環境にわたる既存のフォームの、アンマネージド ソリューションとカスタマイズの維持
次の手順に従って、このシナリオの正常なフォーム ALM を実装します。
開発環境 1 で、この例では FormB という名前の既存のフォームをカスタマイズします。 次に、フォームのカスタマイズを実行します。
ソリューション (下図ではソリューション B という名前) を作成してください。これはアンマネージド ソリューションであり、FormB を追加します。 ソリューションをアンマネージドとしてエクスポートします。 この手順では、フォームの diff FormXml をエクスポートします。
開発環境 で、手順 2 からアンマネージド ソリューションをインポートします。これにより、フォームの 2 番目のソリューション レイヤーが作成されます。 フォームのマージ後、FormB UI には、Field1 、Field2 、および Field3 が表示されます。
開発環境 2 でフォームをさらにカスタマイズし、Field4 という名前の付いた新しい列を追加するなど、環境でアクティブなカスタマイズを行います。 FormB には、 Field1 、 Field2 、 Field3 、および Field4 が表示されます。
開発環境 1 で、Field5 という新しい列を追加することにより、さらにフォームをカスタマイズします。 開発環境 1 のフォームの UI に、Field3 、および Field5 が表示されます。
アンマネージド ソリューション B を、手順 5 で行った変更を使用してエクスポートします。 この手順では、フォームの diff FormXml をエクスポートします。
開発環境 2 で、手順 6 からアンマネージド ソリューション B アップグレードをインポートします。 インポートするソリューションには、FormB の diff FormXml が含まれているため、開発環境 1 で行われたアクティブなカスタマイズとマージされます。 そのため、フォームには Field1 、Field2 、Field3 、Field4 、および Field5 が表示されるようになります。 この動作は、フォームの diff FormXml を持つアンマネージド ソリューションのインポートで発生します。
アンマネージド ソリューションで diff FormXml をインポートしていても、手順7でのフォームのマージが目的ではなく、開発環境 2 で行われたアクティブなカスタマイズを上書きできるようにしたい場合、FormB のアクティブ レイヤーを削除します。 詳細: アンマネージド レイヤーを削除する 。
アンマネージド ソリューション B を、手順 5 で行った変更を使用してエクスポートします。 この手順では、フォームの diff FormXml をエクスポートします。
開発環境 2 で、手順 9 からアンマネージド ソリューション B アップグレードをインポートします。 開発環境 2 のフォームにはアクティブなレイヤーがないため (ステップ 8 を参照)、アンマネージド ソリューション B からのすべての変更は、FormB の diff FormXml をインポートしている場合でもインポートされます。 そのため、フォームには Field1 、Field2 、Field3 、および Field5 のみが表示されるようになります。 この動作は、フォームの diff FormXml を持つアンマネージド ソリューションのインポートで発生します。 これは、複数の開発環境にわたる既存のフォームの、アンマネージド ソリューションとカスタマイズの維持 シナリオの手順 7 と同じ結果です。
エクスポートされたすべてのソリューション パッケージには、customizations.xml ファイルが含まれています。 フォームがソリューションに含まれている場合は、関連するフォーム定義が customizations.xml ファイルの FormXml セクション内に常に存在します。 FormXml は完全 または差分 (diff) 次のいずれかになります。
管理されていない状態のフォームのソリューションをエクスポートするときに得られる FormXml は、完全 FormXml と呼ばれます。 完全とは、フォーム定義全体が含まれていることを意味します。 新しいフォームを作成してエクスポートすると、エクスポート元の環境のフォームは管理されていない状態であり、作成状態でもあるため、フォームは必ず完全 FormXml になります。 この同じ環境からさらにソリューションをエクスポートすると、完全 FormXml も含まれます。 なぜなら solutionaction
属性は diffFormXml を示し、エクスポートするソリューションの customization.xml ファイルの完全 FormXml には solutionaction
属性が含まれません。
管理された状態のフォームのソリューションをエクスポートするときに得られる FormXml は、差分または diff FormXml と呼ばれます。 差分とは、FormXml に、その環境でアクティブなカスタマイズで行われた変更のみが含まれ、フォーム定義全体が含まれないことを意味します。 既存の管理対象フォームをカスタマイズしてエクスポートする場合、フォームには、加えられたアクティブな変更のみが含まれるため、フォームは常に差分 FormXml になります。 エクスポートするソリューションの customization.xml ファイルの diffFormXml には、solutionaction
属性が含まれ、追加済み 、削除済み 、変更済み など、変更が何であるかを定義します。
Diff FormXml により、ソリューションがアプリに必要な変更のみを表現し、他のレイヤーからの変更による影響が少なくなります。 Diff FormXml はまた、ソリューションのサイズを抑え、インポートを高速化します。
健康なALMのための推奨事項