---
sourceDocument: Yokohama ビルドのワークフロー
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/yokohama/build-workflows

 Release :

    - yokohama

ft:locale :

    - ja-JP

ft:publication_title :

    - Yokohama ビルドのワークフロー

ft:clusterId :

    - crworkflow

bundleId :

    - crworkflow

workflow :

    - Creator


---

# ワークフローの重複の回避

# ワークフローの重複の回避 {#ariaid-title1}

* リリースバージョン: Yokohama
* 
* 更新日 2025年01月30日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：2分

更新セットは、ワークフロー バージョンをローカル インスタンスにコミットする前に、ワークフローのすべてのバージョンの公開状態を管理します。

更新セットを使用して挿入または更新としてコミットされたワークフローの最新バージョンは、ワークフロー バージョンの発行順序に関係なく、現在公開されているバージョンになります。

## 更新セットでのワークフローのコミット {#ariaid-title2}

このページの手順に従って、更新セットでワークフローをコミットします。

### 手順

1. ワークフロー A - バージョン 1 が作成され、更新セット A で公開されます。
2. 更新セット A が完成し、ローカル インスタンスに移行されます。
3. 更新セットがコミットされると、ワークフロー A の以前のすべてのバージョンが published = false に設定されます。  
   初回の移行時は、以前のバージョンがありません。
4. ワークフロー A - バージョン 1 がワークフローの唯一の公開バージョンになります。

## 更新セットの移行の例 {#ariaid-title3}

更新セットのコミットの結果として、公開バージョンが複数になることはありません。ただし、これによってリスクがなくなるわけではないため、更新セットを移行する際には注意が必要です。
次の例を考えてみましょう。

1. ワークフロー A - バージョン 1 が本番インスタンスに移行されてコミットされます。
2. 更新セット B が作成されます。
3. 更新セット C が作成されます。
4. ワークフロー A - バージョン 2 が更新セット B で公開されています。顧客更新レコードがバージョン 2 のペイロードを持つ更新セット B に追加されます。

   バージョン 1 ワークフローが未公開のままの更新セット B に顧客アップデートレコードが追加されます。
5. 更新セット B が完成しました。
6. ワークフロー A - バージョン 3 が更新セット C で公開されています。顧客更新レコードがバージョン 3 のペイロードを持つ更新セット C に追加されます。

   バージョン 2 ワークフローが未公開のままの更新セット C に顧客更新レコードが追加されます。
7. 更新セット C が完成しました。
8. 更新セット C が本番インスタンスに移行されてコミットされます。ワークフロー A - バージョン 1 は未公開に設定されています。

   ワークフロー A - バージョン 2 を含む更新セット B が一度も移行されたことがないため、バージョン 2 の更新はスキップされます。

   ワークフロー A - バージョン 3 がコミットされ、ワークフローの唯一の公開バージョンになります。
{#r_UpdateSetMigrationExample__ol_xg3_zrz_gr}

## 更新セットの移行のリスク {#ariaid-title4}

更新セット B が本番インスタンスに移行されてコミットされます。
1. ワークフロー A - バージョン 3 は未公開に設定されています。
2. ワークフロー A - バージョン 1 は未公開のままです。
3. ワークフロー A - バージョン 2 がコミットされ、ワークフローの唯一の公開バージョンになります。ワークフローが、おそらく意図せずにバージョンを戻しました。戻ったバージョンは、現在の公開バージョンになります。

{#r_UpdateSetMigrationRisk__ol_szq_3vz_gr}