構成管理¶

構成は、IFSクラウドソリューションを調整する方法の1つです (IFSクラウドの技術ドキュメントの「調整ライフサイクル」を参照してください)。このページでは特に構成のライフサイクル管理について説明していますが、技術ドキュメントには「調整のライフサイクル管理に関する一般ガイダンス」も記載されています。

構成には、内部ライフサイクルと外部ライフサイクルがあります。

内部ライフサイクルとは、単一の環境内で構成をどのように管理するかを指します。たとえば、構成を作成し (多くの場合ドラフト状態)、構成コンテキストに応じて、すべてのユーザーまたは特定のユーザーグループ向けに有効化 (公開) する方法です。
外部ライフサイクルとは、構成が単独で、またはカスタマイズなどの他の調整とともに環境間をどのように移動するかを指します。

このページでは、構成の外部ライフサイクルについて説明します。内部ライフサイクルについては、構成タイプごとに個別に説明されています。

概要¶

構成の外部ライフサイクルフローは、以下の原則に基づいています。

構成は、DEV (ビルド場所) またはCFG (使用場所) 環境で実施 (作成、更新) されます。
構成は保管のために顧客ソリューションリポジトリに保存されます。これにより、リポジトリには常に最新かつ正しいバージョンの構成が保持され、別の場所に構成を個別に保存する必要がなくなります。
構成は、納品 (コアまたはカスタマイズに対するアップデートを含む) をUATおよびPRODに適用した後、それぞれUATおよびPRODへ手動でインポートすることで昇格されます。

構成の外部ライフサイクルフローを以下の図に示します。

構成ライフサイクルフロー

構成はCFG使用場所環境 (1a) で作成することをお勧めしますが、ビルド場所のDEV環境 (1b) で作成することもできます。どちらを選択するかは、構成のタイプによって異なります。カスタムエンティティやカスタム属性など、一部の構成はどちらの場所でも簡単に作成およびテストできます。一方、ワークフロー、クエリ、ロビーなどの他の構成は、PRODのデータを完全にコピーしないと設計やテスト、検証が難しい場合があります。
構成は、個別にエクスポートされた項目、または展開されたアプリケーション構成パッケージとして、顧客ソリューションリポジトリのトピックブランチにある/nobuild/appconfig/\フォルダーへエクスポートしてコミットします。これは、ACPに含まれない構成 (例: ロビー要素やページ) にも適用されます。保存に使用するコンポーネントとフォルダーを正しく把握しておいてください。

顧客ソリューションの目的の機能を実装するために複数の構成やカスタマイズが必要な場合は、同じトピックブランチで作業し、1つのプルリクエストでmasterブランチにマージします。これにより、顧客ソリューションのその機能に必要なすべての項目を、ライフサイクル全体を通じてまとめて昇格できます。

(オプション) 最終テストまたは承認のために必要な場合は、構成をUATに手動でインポートします。上記の図には示されていません。
プルリクエストプロセスを使用して、トピックブランチで行ったその他の作業とともに構成をmasterへ昇格します。
UATおよびPRODに昇格する新規/変更済みの構成やその他の項目を含むターゲットコミットを含む納品を注文して適用します。ターゲットコミットに構成の変更のみが含まれている場合 (つまりコード変更がない場合)、このステップはスキップできます。
納品をインストールした後、構成をUATに手動でインポートします (技術ドキュメントの「アプリケーション構成パッケージのインポート」を参照)。これにより、構成のカスタマイズやその他の変更に依存する構成や、コアレイヤーの変更に依存する構成が正しく機能するようになります。
UATでのテストが完了したら、PRODでも同じ手順を実行します (納品を適用してから、構成を手動でインポートします)。

何らかの理由でUATまたはPRODで構成の変更を直接行った場合は、その構成をエクスポートして顧客ソリューションリポジトリにコミットします。これは、CFGで作成した場合と同様です。

リリースアップデートでの構成の処理¶

新規および変更された機能を含むリリースアップデートを適用する場合、構成はある程度影響を受ける可能性があります。一部のリリースアップデートには、構成メタデータ用のアップグレードスクリプトが含まれる場合もあります。これは、構成メタデータが、アプリケーションデータと同じ方法かつ同じインストールステップで、インストーラーによってアップグレードされることを意味します。

環境をアップデートする前に、構成開発に使用する環境に正しいバージョンの構成がデプロイされていることを確認してください。
環境のアップデートに使用する納品には、「自動インストール」用の構成を含めないでください。含めると、アップデート済みの構成が上書きされる可能性があります。

構成の処理には、CFG環境を使用することをお勧めします。この目的で別の環境を使用する場合、以下の「CFG」への参照はその環境に読み替えてください。

推奨されるプロセス¶

構成処理環境に、正しいバージョン、つまり顧客ソリューションリポジトリ内の現在のバージョンが含まれていることを確認します。
リリースアップデートスタジオのプロセスを進め、リリースアップデートを含む納品がCFG環境に適用されるところまで実行します。
構成影響アナライザー、ページデザインのリベース、ロビー影響分析など、提供されているツールや機能を使用して、CFG環境内の構成への影響を分析し、解決します。
アップグレードによって変更されたすべての構成をエクスポートし、その変更を顧客ソリューションリポジトリに保存します。
上記の概要プロセスのステップ2から続行します。なお、ステップ5の納品は、ここではリリースアップデートを含む納品を指します。

DEV、UAT、およびPRODへの自動適用のために納品に構成を含める¶

上記の推奨アプローチでは、UATおよびPROD (およびその他の使用場所環境) への構成の手動インポートを前提としています。エクスポートした構成をserver/appconfigフォルダーに配置し、納品の適用の一環として環境へ自動的にインポートすることもできます。

IFSクラウド25R1以降では、システムパラメーターImport Application Configuration Packages (ACP) from Installerが有効 (ON) になっている場合、ACPの内容がインポートされます。追加のシステムパラメーターImport Page Configurations from Installerは、デフォルト設定がOFFの場合に、納品内のページ構成をインポートする動作を制御します。

この利点は、トピックブランチ用に作成された新しいDEV環境や、リリースアップデートスタジオで使用される新しい環境に、構成が自動的にインポートされることです。このアプローチの欠点は、構成を (UATやPROD環境などに) 昇格するために納品を作成して適用する必要があるため、手動インポートで構成を昇格する場合より時間がかかる (およびスケジュール済みダウンタイム期間が必要になる) ことです。

このオプションは、以下の場合に検討してください。

多数の構成がすでに「完成」しており、頻繁には変更されない場合に、構成を自動適用する場合。
オンライン納品で、手動による構成インポートで発生するダウンタイムをなくしたい場合。コードと構成レイヤーの内容を同じ納品に含めることが可能であることが前提です。

「リリースアップデート」を含む納品を、構成処理環境 (例：CFG、ビルド場所) のアップデート用としてリクエストする場合、通常は構成を含めないでください。「リリースアップデートでの構成の処理」で説明したように、リリースアップデートには構成メタデータ用のアップグレードスクリプトが含まれる場合があります。そのため、アップデート対象の構成が、環境をアップデートする前にその環境内に存在している必要があります。納品に含まれる構成は、その後のステップでデプロイされるため、すでにアップグレード済みの構成を上書きする可能性があります。

構成への影響分析¶

すべての構成をビルド場所の顧客ソリューションリポジトリで管理し、構成アナライザー (技術ドキュメントの「構成アナライザー」を参照)、ロビーアナライザー (技術ドキュメントの「IFSロビーアナライザー」を参照)、およびページリベースデザイナー (技術ドキュメントの「クライアント構成のリベース」を参照) を使用して影響分析を実行することを強くお勧めします。

コアレイヤーやカスタムレイヤーの変更を含む納品 (機能アップデートやサービスアップデートなど) では、構成への影響分析に加えて、使用場所へ納品する前にビルド場所で構成影響分析を実行することをお勧めします。

ただし、構成以外に他のレイヤー変更がない場合は、使用場所自体で影響分析を実行できます。

ServerおよびNobuildフォルダ¶

Serverフォルダの使用¶

ACPの一部ではないものの、納品に含める必要があるロビーページおよび要素は (納品の一部としてまとめて適用されるため)、以下のパスに配置する必要があります: \/server/lobby

納品に含めるACPの展開済みコンテンツは、以下にコミットする必要があります: \/server/appconfig

Nobuildフォルダの使用¶

ACPの一部ではないものの、納品に含める必要があるロビーページおよび要素は、以下に配置する必要があります: \/nobuild/lobbyこのフォルダーに配置したファイルは、自動的にはインストールされないことに注意してください。代わりに、ユーザーが変更内容を該当する環境に手動でインポートまたは昇格する必要があります。

顧客ソリューションリポジトリ内に保持するものの、ビルド場所を介して納品することを意図していないACPの展開済みコンテンツは、以下の場所にコミットする必要があります: \/nobuild/appconfig/\