検証と本番で移行内容が異なる場合のUpdateSetの移行

[d-aizawa]

コミュニティの皆様

いつもお世話になっております。
現在のプロジェクトで開発・検証・本番の3環境あり、
以下の対応を行い、本番移行(※)を行おうと考えております。
①UpdateSetAでClinet ScriptA(Incidentテーブル)とフィールド(Groupテーブル)を追加

②UpdateSetBでフィールド(Groupテーブル)を追加
※検証環境には移行済のため、上記UpdateSetAとBのステータスはCompleteに設定しています

→ただし、本番移行について、UpdateSetAに記録されているClinet ScriptAは、
お客様都合により、まだ移行したくない(移行時期をずらしてほしい)とのオーダーがあったため、
今回はやむおえず、以下手順で本番移行を行おうと考えております。
①UpdateSetCを作成し、UpdateSetAのフィールド情報をCに移動
②UpdateSet Bのフィールド情報をUpdateSetCに移動
③UpdateSetDを作成し、UpdateSetAのClient Script情報をDに移動
④UpdateSetAとBのステータスをComplete→Ignoreに更新
⑤UpdateSetCのステータスをCompleteに設定し、本番移行
(UpdateSetDは移行しない)

→手順⑤のUpdate SetCの移行でエラーになる可能性がある等、

何か懸念事項やご経験がある方は、ご教示頂きたいです。
よろしくお願いいたします。

[t_sadahisa]

こんにちは。

個人の感覚かもしれませんが、一度も利用していないUpdatesetのリリースは危険だと思います。

私だったら以下の手順で実施します。

①検証環境のUpdatesetA、UpdatesetBをBackout、

　Backout失敗時はUpdatesetの更新がすべて巻き戻るように手修正

②検証環境のBackoutしたUpdatesetを削除
③開発環境でUpdatesetAならびにBをProgressに戻し、UpdatesetAのフィールドをUpdatesetBに移行

④UpdatesetBをCompleteにする

⑤検証環境でUpdatesetBを取得し、Commit

検証作業に問題がなければ本番環境でのリリースに進んでください。

[d-aizawa]

t_sadahisaさん
ご回答ありがとうございます。
追加で以下2点質問させてください。
①他のプロジェクトで開発と本番の2環境しかない所もあり、
今回は検証と本番で使用するUpdateSetを分ける方法で実施したのですが、

検証と本番に移行するUpdateSetは同じにした方が良い、
または、別々にすると危険な理由は何かあるのでしょうか。

②Backoutを2つのPDIで何回か試したところ、
すべて失敗だったので、使うのは危険という印象があります。
また失敗の原因もよくわからず、すべて巻き戻るように手修正するというのも、
経験上難しいと思い、使用するのは避けていたのですが、
t_sadahisaさんの所では、移行失敗等が発生した場合や、
UpdateSetの一部分だけ本番リリースとなった場合、
Backoutはよく使用されるのでしょうか。

[d-aizawa]

すみません、
上記質問の①について、テストしていないUpdateSetを本番に移行するのは、
危険だと理解しました。
質問②のみご確認頂ければと思います。

[t_sadahisa]

基本的には緊急時※のみです。

※プロジェクト内では開発開始後のスコープ変更を禁止していますので、

　頂いた内容は私の感覚では緊急対応となります。

ご認識の通り、Backoutには失敗するケースがありできる限り使わない方が良いです。

行いたいことは、本番環境と検証環境を同じ状態にして、

本番環境に適用するUpdatesetを検証環境にCommitし、検証するということになります。

一番容易に実行できるのがBackoutで、他の方法としては本番環境をクローンするという方法もございます。

Updatesetはすべてのレコード操作を記録していないため、検証作業は必須です。

検証環境での検証後リリース内容に変更があったら、私は記載させていただいた通りの指示を出すと思います。