ライフサイクルマネジメントの計画 ​

Workatoでライフサイクルマネジメントの使用を開始する前に、使用するプロセスについて検討し、文書化する時間を取ることをお勧めします。 すでに実施済みの場合は、次の章に進むことができます。

• ライフサイクルマネジメントの計画 （現在）
• エクスポート：レシピと依存関係のパッケージ化
• インポート: デプロイメント
• 外部ソース管理システムの使用

Environment、プロモーション条件、および責任の定義 ​

ライフサイクルマネジメントのこの計画プロセスには、次の内容を含めることをお勧めします。

• ソフトウェアライフサイクルステージの定義
• サポートが必要なワークスペースの数の特定
• 個々のロール/責任の特定（たとえば、ワークスペースの管理者、開発、テスト、またはデプロイの担当者、ステージ間でのアセットの移動責任者）

レシピをステージ間で移動するための条件を文書化する必要があります。たとえば、プロモーション前に実行する必要があるテストなどです。 組織によっては一部の領域ですでに標準がある場合がありますが、それらをWorkato Environmentで使用される用語や機能に合わせて調整する必要がある場合があります。

一般的なソフトウェアライフサイクルの例では、Development、ステージング（QA）、ライブプロダクションEnvironmentの3つのEnvironmentを使用します。

dev、テスト、およびプロダクションEnvironmentでセットアップ

ワークスペース機能の使用 ​

Workatoのワークスペースとコラボレーション機能は、組織が共有ワークスペース内でDevelopmentを行えるようにし、Developmentの監督と監視を行う機能も提供するように設計されています。

ワークスペース管理者は、ワークスペースを整理し、他のメンバーを招待し、それらのロールと権限を設定できます。 Workatoでは、1つのアカウントが1つのワークスペースを管理します。 ワークスペース内では、ユーザーは他のユーザーのレシピを表示でき（その権限が付与されている場合）、ワークスペース管理者はワークスペース全体のレシピを表示できます。

ユーザーがワークスペースに招待されて参加すると、そのユーザーは個人アカウントとワークスペースアカウントの両方を持つことになります。 Development作業にはワークスペースアカウントを使用することをお勧めします。

ワークスペースは、必要に応じてSAMLベースのSingle-Sign Onを使用するように構成できます。 可能であればこれを有効にして、ユーザーが標準の企業アカウントを使用してログインできるようにし、SAMLアイデンティティプロバイダー（ディレクトリシステム）から統一されたログインポリシーを適用できるようにすることをお勧めします。

アカウントの整理 ​

各Developmentライフサイクルステージは、通常は複数のユーザーを持つワークスペースアカウントである、別々のWorkatoアカウント内で行う必要があります。 最もシンプルなアカウント構成は、各ステージに1つのワークスペースアカウントを用意するだけです。

複数のワークスペース ​

多数のレシピを使用している場合、または複数の異なる部門やグループが1つのステージ内でレシピを操作する場合（例：各部門が独自にDevelopmentを行う場合）、アカウントをさらにセグメント化する方法がいくつかあります。 1つは、各グループ+ステージに個別のアカウントを使用する方法です。 例：

各部門に対してワークスペースアカウントが作成されます

複数のフォルダ ​

もう1つの方法は、1つ以上のワークスペースアカウントをセグメント化して、異なるユーザーが異なるフォルダにアクセスできるようにすることです。例：

異なる部門のために各Environmentにフォルダが作成されます

これは便利な場合がありますが、次のセクションで説明する理由により、ロール管理が複雑になる可能性があります。

ロール管理 ​

ワークスペース管理者は新しいワークスペースを作成し、ユーザーを招待します。 所有者になれるアカウントは1つだけですが、他のユーザーにEnvironment adminロールを割り当てることができます。 Environment adminは、特定のEnvironment内で所有者と実質的に同じ権限を持ちます。 ほとんどのワークスペースメンバーはEnvironment管理者であるべきではありません。 代わりに、より限定されたロールを割り当てます。

特定のプロジェクトとそのフォルダへのアクセスを制御する予定がある場合は、プロジェクトロールを使用します。 たとえば、一部のメンバーには1つのプロジェクトへのアクセスが必要であり、他のメンバーには別のプロジェクトへのアクセスが必要な場合があります。 インポートおよびエクスポート権限の付与や、標準ロールでは提供されない権限の設定など、Environmentレベルでより広範にアクセスを管理する必要がある場合は、カスタムEnvironmentロールを作成します。

ユーザーが実行できるアクションをセグメント化するために、カスタムロールを作成することもできます。 たとえば、一部のユーザーはコネクションを作成および管理し、他のユーザーはそれらを変更せずにコネクションを使用する場合があります。

RLCM権限 ​

レシピライフサイクルマネジメント権限により、コラボレーターは、割り当てられた権限範囲では通常制限されているアセットに間接的にアクセスできる場合があります。 これは、RLCM権限によってワークスペース内のすべてのマニフェストへのアクセスが許可されるためです。 つまり、この権限を持つコラボレーターは、通常はこれらのアセットを含むプロジェクトにアクセスできない場合でも、マニフェスト内のアセットを表示できます。

例:

• User AがProject 1を作成し、RLCMでマニフェストを構築してエクスポートする
• User BはRLCM権限を持っていますが、Project 1へのアクセス権はありません
• User BはUIでProject 1にアクセスできず、RLCMを使用してProject 1アセットを含むマニフェストパッケージを構築することもできません

User Bは、Project 1コンテンツを含む、User Aが作成したエクスポートパッケージを表示、ダウンロード、および使用できます

レシピライフサイクルマネジメント（RLCM）の他のユーザーにこれらのファイルのコンテンツへのアクセスを提供する予定がない場合、Workatoではマニフェストを定期的に削除することをお勧めします。 このプラクティスは、データのセキュリティとプライバシーの維持に役立ちます。

セキュリティを強化するには、デプロイメント機能を使用できます。 この機能はエクスポート/インポート機能を活用してアセットの転送を容易にし、Environment間でアセットを移動するためのより安全で効率的な方法を提供します。

フォルダ ​

レシピをフォルダにどのように整理すべきか、およびそのためにどの命名規則を使用すべきかについても検討する価値があります。 前述のように、ワークスペース内のメンバーに特定のフォルダまたは複数のフォルダ内のレシピに対する責任を割り当てられるよう、カスタムロールとともにフォルダを使用することをお勧めします。

フォルダ内のレシピの例

多数のレシピをすべてデフォルトの場所であるルート（Home）フォルダに配置することは避けるようにしてください。 5～10個を超えるレシピがある場合、Workatoではそれらをフォルダに整理し、各フォルダにも関連するレシピを少数の管理しやすい数（最大で10個程度）に制限することをお勧めします。

フォルダはアセットのインポートおよびエクスポートに使用される単位でもあるため、アカウント間で一緒に移行する場合は、レシピとコネクションなどの関連オブジェクトを同じフォルダに配置する必要があります。

アセットをアカウント間で移動することを計画している場合、たとえばDevelopmentからテストへ移動する場合は、Workatoでは必須ではありませんが、異なるステージのアカウントでフォルダ名と構造を同じにするルールを定めるとよいでしょう。

コネクション ​

Workatoでは、コネクションをフォルダにスコープ設定できます。 デフォルトでは、それらのスコープはHomeフォルダです。 ただし、ライフサイクルマネジメントを使用する準備をする際には、エクスポート予定のフォルダ内のレシピに必要なコネクションを、そのフォルダに関連付けることをお勧めします。

これは、App Connectionsタブに移動し、該当するコネクションをページの左側に表示されるフォルダにドラッグすることで実行できます。 これにより、コネクションを整理し、エクスポートされる各フォルダに正しいコネクションが使用されるようにできます。

アプリコネクションはフォルダ別に整理および管理できます

コネクションをフォルダに割り当てることで、ワークスペースメンバーによるコネクションへのアクセスを制限することもできます。 ワークスペースメンバーがアクセスできるフォルダ内のコネクションのみが、そのメンバーに表示され、使用可能になります。

プロジェクトプロパティ ​

プロジェクトプロパティは、作成および管理する特定のプロジェクト内のプロジェクトレベルでのみ使用できます。 これらのプロパティを別のフォルダにデプロイできます。

ただし、プロジェクトプロパティを作成していても、それらをアクティブなレシピで使用していない場合、Workatoはそれらをマニフェストに含めず、レシピライフサイクルマネジメントツールを使用してエクスポートすることはできません。

Workatoがプロジェクトプロパティをエクスポートする際、エクスポートされるのはプロパティ名のみで、プロパティのValueは含まれません。 このため、プロジェクトプロパティを含むパッケージを、同じ名前のプロジェクトプロパティがすでに存在するフォルダにインポートしても、Workatoは既存のプロパティの値を上書きしません。

たとえば、顧客オンボーディングという名前のフォルダに、値が[email protected]であるclient_emailという名前のプロジェクトプロパティが含まれている状況を考えます。 値が[email protected]のプロパティclient_emailも含むパッケージを顧客オンボーディングにインポートしても、client_emailの値は引き続き[email protected]です。

パッケージにプロジェクトプロパティを含める

ルックアップ テーブル ​

パッケージの一部としてルックアップ テーブル（LUT）をエクスポートする予定がある場合は、そのルックアップ テーブルをレシピで使用する必要があります。 レシピライフサイクルマネジメントツールは、レシピに含まれていないルックアップ テーブルをエクスポートしません。

特定のプロジェクトにスコープ設定されているかグローバルであるかに関係なく、ルックアップ テーブルは同じワークスペース内の別のルックアップ テーブルと同じ名前にすることはできません。 このため、ルックアップ テーブルを含むレシピをインポートすると、Workatoは次のロジックに従います。

• この名前のルックアップ テーブルがターゲットワークスペースに存在しない場合、パッケージのルックアップ テーブルが作成されます。 そのスコープ（プロジェクトまたはグローバル）はソースワークスペースから継承されます。

• この名前のルックアップ テーブルがターゲットワークスペースにすでに存在する場合、ルックアップ テーブルの構造（インポートすることを選択した場合はコンテンツも）が既存のルックアップ テーブルを上書きします。 ただし、そのスコープ（プロジェクトまたはグローバル）は変更されず、元のルックアップ テーブルのスコープと一致します。 ルックアップ テーブルをワークスペースにインポートする前後に、スコープを確認することをお勧めします。

ルックアップ テーブルデータを上書きまたは無視する