並行処理のベストプラクティス

一般的なガイドライン

チームコラボレーションにおいて、以下のベストプラクティスに従うことをお勧めします：

• 新しい長期プロジェクトのために別のバージョンを作成するのは控える：
  短期の修正を行う場合は、現在のバージョンのリビジョンを保存するために Save オプションを使用してください。小さな変更のために Save As オプションを使用しないでください。新しい、長期的なプロジェクトの開発を開始するときにのみ、公開されたバージョンに基づいて別のバージョンを作成するために Save As を使用してください。
• 現在のバージョンに頻繁にリビジョンを保存し、同じプロジェクトに複数のバージョンを避ける：
  新しいプロジェクトのバージョンに変更を頻繁に保存する場合は、Save As ではなく Save オプションを使用してください。開発中に複数の新しいバージョンを作成すると、公開されたバージョンとの変更の調整や公開時に混乱が生じます。そのバージョンにログインしているユーザーのみが更新通知を受け取ります。
• 小さな変更を行い、頻繁に公開する：
  開発バージョンの変更を小さく保ち、頻繁に公開することで、同僚への影響を減らします。これにより、エラーのトラブルシューティングや変更の元に戻しを容易にします。
• あなたの変更が他の変更を上書きする：
  あなたの変更と最新の公開バージョンが同じ項目を変更し、システムがそれらの変更を自動的に調整できない場合、あなたのバージョンを公開すると、公開バージョンの既存の項目があなたのもので上書きされます。
• 公開バージョンのみと比較する：
  あなたのバージョンを公開バージョンと比較・統合してください。他のバージョンとあなたのバージョンを比較・統合することはできません。
• チームとの調整を行う：
  計画をチーム間で共有してください。早期に重複の潜在的な問題を特定し、チームが共通の要素に対する他のチームの変更を誤って上書きするのを防ぎます。
• 公開バージョンを統合する：
  現在のバージョンが公開バージョンより遅れている場合は、公開バージョンをあなたのバージョンに統合してください。これにより、後で変更を公開するのが容易になります。プロファイルスイッチャーと Save/Publish ダイアログには、現在の公開バージョンとあなたのバージョンの変更を比較するために使用できるステータスメッセージが含まれています：
  • 公開バージョンより先行しています
    あなたの現在のバージョンには、現在の公開バージョンにない変更が含まれています。
  • 最新の状態です
    あなたの現在のバージョンと現在の公開バージョンは一致しています。
  • 公開バージョンより遅れています
    現在の公開バージョンには、あなたの現在のバージョンにない変更が含まれています。これらの変更を表示するには、最新の公開変更を表示 をクリックしてください。これらのステータスメッセージとその使用方法についての詳細は、サーバーサイド保存と公開についてを参照してください。
• 公開バージョンからのみ項目を削除する：
  項目を永久に削除するには、公開バージョンから削除してください。公開バージョンではないバージョンから項目を削除してから保存および公開すると、プラットフォームは公開時に削除された項目を復元します。これは、オーディエンスに必要な属性など、依存関係の誤って削除されるのを防ぐためです。
• 公開前に検証警告を解決する：
  保存/公開モーダルを開いたときに、警告 セクションにリストされている警告を確認してください。警告は保存または公開をブロックしませんが、解決されていない警告は、本番環境で予期しない動作を引き起こす可能性のある誤構成された項目を示すことがあります。ライブワークフローを中断するリスクを減らすために、公開前に警告を解決してください。

例示的なワークフロー

次の例では、組織に2人のユーザーがサーバーサイドプラットフォームで作業しています。ユーザー1はコネクターに取り組んでおり、ユーザー2はデータソースに取り組んでいます。

同じバージョンへの同時保存

次の例では、両方のユーザーが同じバージョンで一緒に作業しています。

図は各アクションを示しています。

1. 最初に、現在公開されている単一のバージョン A1 から始めます。訪問がサイトやアプリを使用するとき、彼らはバージョン A1 を使用します。
2. ユーザー1 はコネクタを追加します。
3. ユーザー2 はデータソースを追加します。
4. ユーザー1 はバージョン A1 への変更をリビジョンとして保存します。ユーザー2 は ユーザー1 がこのバージョンを更新したことを通知されます。
5. ユーザー2 はバージョン A1 への変更をリビジョンとして保存し、ユーザー1 の変更（新しいコネクタ）を統合します。ユーザー1 は ユーザー2 がこのバージョンを更新したことを通知されます。
6. ユーザー1 はバージョン A1 をロードし、ユーザー2 の変更（新しいデータソース）を受け取ります。
7. ユーザー1 はバージョン A1 を公開します。ユーザー2 は ユーザー1 がこのバージョンを公開したことを通知されます。ユーザー1とユーザー2は最新の状態です。
8. 訪問がサイトやアプリを使用するとき、彼らは新しいコネクタとデータソースが追加されたバージョン A1 を使用します。

複数のバージョンへの同時保存

次の例では、各ユーザーがそれぞれの長期プロジェクトに取り組んでいる別々のバージョンで作業しています。

図は各アクションを示しています。

1. 最初に、現在公開されている単一のバージョン Start から始めます。訪問がサイトやアプリを使用するとき、彼らはバージョン Start を使用します。
   • Start: 最新の状態です。
2. ユーザー1 は Start の新しいバージョン Project 1 を作成します。
   • Project 1: 最新の状態です。
3. ユーザー2 は Start の新しいバージョン Project 2 を作成します。
   • Project 2: 最新の状態です。
4. ユーザー1 はバージョン Project 1 にコネクタを追加し、リビジョンを保存します。
   • Project 1: 公開バージョンより先行しています。
5. ユーザー2 はバージョン Project 2 にデータソースを追加し、リビジョンを保存します。
   • Project 2: 公開バージョンより先行しています。
6. ユーザー1 はバージョン Project 1 を公開し、バージョン Project 1 が公開されたことを通知されます。訪問がサイトやアプリを使用するとき、彼らは新しいコネクタが追加されたバージョン Project 1 を使用します。
   • Project 1: 最新の状態です。
   • Project 2: 公開バージョンより遅れています。
7. Project 1 は完了です。
8. ユーザー2 はバージョン Project 2 に変更を保存し、リビジョンを保存します。このとき、最新の公開変更を含める オプションを使用して、バージョン Project 1 からの変更（新しいコネクタ）を統合します。
   • Project 2: 公開バージョンより先行しています。
9. ユーザー2 はバージョン Project 2 を公開します。訪問がサイトやアプリを使用するとき、彼らは新しいコネクタと新しいデータソースが追加されたバージョン Project 2 を使用します。
   • Project 1: 公開バージョンより遅れています。
   • Project 2: 最新の状態です。
10. Project 2 は完了です。