バージョンをプッシュ

プッシュは、開発インスタンスから親インスタンスへの変更を促進し、開発インスタンス上のカスタマイズされたレコードの現バージョンを親インスタンスの現バージョンとして収容します。

このタスクについて

プッシュは、すべての開発バージョンではなく、現開発バージョンのみを親に追加します。

注:

異なるアプリケーションからのレコードの更新は、同じプッシュ/プルでプッシュ/プルすることはできません。他のアプリケーションへの更新が混在しているケースでエラーを解決するには、他のアプリケーションへの更新を戻しキューします。１アプリケーションのプッシュ1つのアプリケーションへの更新を再キューします。プッシュしてから、必要に応じて繰り返します。

プッシュすると、完了したとマークされた親にローカル更新セットを作成します。プッシュされた変更は、親のローカルの変更としても追跡します。したがって、更新セットを転送するか、ローカルの変更をプッシュすることで、開発およびテストの階層構造を通じて変更を促進できます。各プッシュは、開発インスタンスのプッシュまたはプルテーブルに記録します。

手順

1. 移動先 すべて > Team Development > チームダッシュボード.
2. プッシュする準備ができているローカルの変更をキューに入れます。
3. 親インスタンスからプルバージョンしそして競合があれば解決します。

   競合が検知された場合、親インスタンスに変更をプッシュすることはできません。

4. コントロールパネルで、プッシュをクリックします。
   のページが開きます。
5. 変更のために名を提供します。
6. 変更のリストをレビューして、正しい変更がインクルードされていることを確認します。

   オプション	説明
   プッシュしたくない変更を削除するには	行の横にあるチェックボックスをオンにして、行動選択リストからプッシュしないを選択します。
   変更を追加するには	キャンセルをクリックし、ステップ2 から手順を繰り返します。

   

7. オプション: 名前を編集。
   名前は、開発インスタンスのプッシュレコードと、親インスタンスのローカル更新セットレコードを識別します。
8. オプション: コメントを入力。
   コメントは、開発インスタンスのプッシュレコードと親インスタンスのローカル更新セットレコードに追加します。
9. プッシュ変更をクリック。
   システムはプッシュを開始して、プッシュが進む前に競合がないことを確認します。

   • 競合が検知された場合、プッシュは自動的にキャンセルされ、ステップ3 から手続きを繰返す必要があります。
   • 競合が検知されない場合、変更は親インスタンスでステージングされます。親では、各バージョンは検証され、レコード間の依存関係を維持するために正しい順序で収容されます。たとえば、新しいテーブルがそのテーブルのフィールドの前に収容され、そのテーブル上のフィールドが正しく作成されていることを確認します。

   注:

   インスタンス間にバージョンの競合がある、またはプッシュするインスタンスにコードレビューを待つステージにある変更がある場合にはプッシュできません。
10. 完了ページで、結果を示す をクリックします。
11. エラーまたはスキップされた変更のプッシュレコードをレビューします。
    • プッシュされた状態の変化は親インスタンスで収容されます。
    • スキップされた状態を持つ変化は親インスタンスで収容されず、開発インスタンスでローカル変更としてキューに入ったままになります。
12. スキップされた各変更について、ログメッセージを確認して、変更がスキップされた理由を判断します。
    親インスタンスで目的のバージョンを収容するために必要な変更を開発し、それをプッシュします。変更がスキップされる理由の例は次を含みます：

    • テーブルは、開発インスタンス上でプラグインをアクティブ化したときに作成されたため、親には存在しません。親でそのプラグインが有効になっていることを確認し、変更を再度プッシュします。
    • プッシュ中にエラーが発生したもう一度プッシュしてみます。
    • 現在のバージョンは無効以前のバージョンに戻して、バージョンが有効であることを確認するために再度変更を行います。
    • プッシュ中に親にエラーが発生したプッシュレコードのログフィールドは例外メッセージを含みます。親インスタンスのシステムログをレビューし、インスタンスの問題のトラブルシューティングを行います。