Sitecoreバージョンアップの引継ぎはGit≠本番を前提に。差分検出と負の遺産解消の標準工程

前任ベンダーからSitecoreサイトの運用を引き継ぎ、あわせてバージョンアップを行う。こうした引継ぎプロジェクトで多くの情シス・Web担当者が直面するのが「Gitリポジトリに格納されたソースコードと、実際に稼働している本番環境との乖離」という課題です。

引継ぎ時に受領したリポジトリをそのまま信頼して開発を進めた結果、本番環境でのみ有効な設定や過去の緊急改修が反映されておらず、リリース後に調整が増えるケースは少なくありません。

本記事では、Sitecoreのバージョンアップを伴う引継ぎプロジェクトで必ず押さえるべき環境差分の検出手順と、過去の運用で蓄積された負の遺産をそのバージョンアップで解消するための工程設計を解説します。

引継ぎプロジェクトで最初に確認すべきは、Gitリポジトリに格納されている内容が本番環境と一致しているかという点です。長期にわたり複数のベンダーや担当者が関与してきたプロジェクトでは、以下のような経緯で差分が発生していることが珍しくありません。

• 緊急対応時に本番サーバー上で直接修正され、リポジトリに反映されていない
• 一時的な回避策として追加された設定ファイルが、ドキュメントに残っていない
• 本来バージョン管理すべきファイル（web.config、Sitecoreの設定パッチ、カスタムDLL等）が、本番サーバー上でのみ直接更新されている
• インフラ側の設定（CDNなど）はそもそもGitの管理外にあり、変更の経緯が残っていない
• 旧担当者の退職や引継ぎ漏れにより、変更履歴が追えない

Sitecoreの場合、App_Config配下（Include、Environmentなど）に多数の設定パッチファイルが配置される構造上、本番環境でのみ有効化されている設定や、特定モジュール用の設定が差分として残っているケースがあります。Gitリポジトリを信頼して開発環境を構築した場合、本番との挙動差異が後工程で顕在化し、調整工数が膨らむ要因となります。

実例：引継ぎプロジェクトで見つかった差分

LYZONが前任ベンダーから運用を引き継ぎ、Sitecore 9.3から10.4へのバージョンアップを行った引継ぎプロジェクトでは、次のような差分が見つかりました。

• Gitに反映されていない本番の修正：公開サイトをメンテナンス表示に切り替える機能について、「Previewサーバーにはメンテナンス表示を適用しない」という分岐が、レイアウトファイルに本番サーバー上で直接加えられており、Gitには反映されていませんでした。Git上には存在しない差分のため、リポジトリと標準のSitecoreを比較するだけでは検出できません。この分岐は、公開サイトをメンテナンス表示にしている間にコンテンツを編集し、その内容をPreviewで確認するためのものでした。見落としていれば、新環境ではPreviewにもメンテナンス画面が表示され、メンテナンス中に編集した内容を確認できなくなるところでした。差分精査の過程でこれを特定し、必要な実装を新環境側で再現しました。
• 環境間の説明のつかない差分：本番環境と検証環境、さらに複数ある検証環境それぞれのあいだで、本来同一であるべき箇所に差分が存在していました。差分を洗い出したうえで、どの状態を「正」とするかを顧客と合意し、統一しました。
• Git管理外のインフラ設定：CDNのホストヘッダー設定が、過去の機能アップデートの過程で複数箇所で定義される状態になっていました。どちらの設定が優先されるかに依存した構成だったため、初期の切替作業では表面化せず、実際の切替作業で初めて顕在化しました。切替作業中に原因を特定し、設定を一元化して構成を正常化しました。

この経験から、LYZONでは以降の引継ぎプロジェクトで、Gitだけでなく実環境との突合を標準工程として組み込んでいます。

引継ぎプロジェクトの初期フェーズ（バージョンアップ作業に入る前）で実施すべき差分検出は、以下の順序で進めることを推奨します。ポイントは、「Gitと実環境の突合」と「標準のSitecore（バニラ）との比較」の二本立てで進めることです。前者で記録に残っていない変更を、後者でカスタマイズ箇所の全体像を洗い出します。

ステップ1：本番環境のフルバックアップ取得

まずは本番環境のWebルート配下、設定ファイル、データベース、メディアの完全なスナップショットを取得します。この時点で、前任ベンダーからの受領物とは別に、現状の本番環境を一次情報として確保することが重要です。

• サーバーの役割ごとに取得する：CM（コンテンツ管理）、CD（配信）、Previewなど、役割の異なるサーバーはそれぞれ別の差分を持っている可能性があります。前述の実例のように、特定の役割のサーバーにだけ存在する修正もあります。
• データベースの範囲を確認する：Core／Master／Webに加え、XP構成ではxConnect（xDB）やFormsなどのデータベースもあります。メディアライブラリは通常Masterデータベース内に格納されていますが、ファイル保存方式の場合はファイルも対象にします。
• 個人情報の扱いを決めておく：本番データベースには、xDBのコンタクト情報やフォームの入力データなどの個人情報が含まれます。後続のステップで検証環境に復元する場合は、マスキングするか、復元対象を必要なデータベースに絞るなどの方針を事前に決めておきます。

ステップ2：Gitリポジトリとのファイル単位比較

本番環境にデプロイされているコミット（またはタグ）を特定し、そこからビルドした成果物と、本番環境のWebルート配下をファイル単位で比較します。最新ブランチには未リリースの変更が含まれている可能性があるため、比較の基準にはしません。デプロイされているコミットが特定できない場合は、そのこと自体を差分として記録します。

比較対象は以下を優先します。

• bin配下のDLL（カスタムアセンブリ）：再ビルドするとハッシュ値は一致しないため、アセンブリのバージョンで当たりを付け、怪しいものは逆コンパイルして中身を比較します
• App_Config配下（Include、Environmentなど）の設定パッチファイル
• web.configおよびSitecore.config（web.configの変換を使っている場合は、変換後どうしで比較します）
• Layouts、Views、sublayouts配下のテンプレートファイル

ステップ3：標準のSitecore（バニラ）との比較

同じバージョンの標準のSitecoreと現行環境を比較し、カスタマイズされた箇所を網羅的に洗い出します。Gitとの比較だけでは、どれが標準のファイルで、どれがカスタムなのかが区別できません。また、Sitecore.configを直接書き換えているなど、本来の管理方式から外れた箇所もここで見つかります。

ステップ4：環境間の比較

本番環境と検証環境、複数の検証環境がある場合はそれぞれのあいだで、同じ観点の比較を行います。本来同一であるべき箇所に差分が見つかった場合は、どの状態を「正」とするかを顧客と合意したうえで統一します。

ステップ5：Sitecoreアイテムの差分抽出

ソースコードだけでなく、Sitecoreデータベース内のアイテム（テンプレート、レイアウト、レンダリング、設定項目等）についても差分を抽出します。このとき、本番環境に直接シリアライズツールを導入すると、それ自体が本番への変更になります。ステップ1で取得したバックアップを検証環境に復元し、そこでシリアライズツールを使って比較するのが安全です。

使用するツールは、Sitecoreのバージョンと既存の開発体制に合わせて選びます。Sitecore Content Serialization（SCS）は10.0以降で利用できます。9系以前の環境では、TDSやUnicornなど、既存プロジェクトで使われているツールを確認したうえで選定します。

比較にあたっては、次の2点に注意します。

• リポジトリにシリアライズデータがあるかを確認する：「リポジトリ側で定義されているが本番で削除されているアイテム」を検出できるのは、前任ベンダーがシリアライズデータをGitで管理していた場合に限られます。ない場合は、標準のSitecoreや検証環境のアイテムと比較します。
• 開発資産とコンテンツを分けて比較する：本番のアイテム差分の多くは、編集者によるコンテンツ更新です。テンプレート、レイアウト、レンダリング、/sitecore/system配下の設定など、開発資産にあたるアイテムを分けて比較することで、確認すべき差分を絞り込めます。

比較の結果、本番にのみ存在するアイテムや、リポジトリ側で定義されているが本番で削除されているアイテムを一覧化します。

ステップ6：差分の分類と棚卸し

検出した差分を以下の4つに分類します。

• 移行不要（過去の暫定対応などで、現在は役割を終えているもの）
• 修正なしで移行（新環境でもそのまま維持すべきもの）
• 修正して移行（新環境でも必要だが、新バージョンへの対応や管理方式の是正が必要なもの）
• 判断保留（当時の経緯が不明で、現行ベンダー・現行担当者ともに判断できないもの）

なかでも「移行不要」の判定は、見た目は不要でも、設定の読み込み順序の制御や検索インデックスの定義に暗黙に依存しているものがあるため、Sitecoreの内部構造を理解したうえで慎重に行う必要があります。この分類作業こそが、負の遺産解消の起点となります。

引継ぎプロジェクトにおけるバージョンアップは、単なるプラットフォーム更新ではなく、過去に蓄積された不要な設定や未使用機能を整理する好機です。ただし引継ぎプロジェクトでは、差分精査が「バージョンアップのため」だけでなく「引き継いだ環境を把握するため」の作業も兼ねることになります。この二重の役割を前提に工数を設計しておくことが重要です。

工程1：現行構成のアセスメント

稼働中の全モジュール、カスタマイズ内容、連携システムを一覧化し、それぞれの利用状況を把握します。リンクデータベース（アイテム間の参照関係）やコンテンツ更新履歴から、実際にはどのページからも使われていないテンプレートやレンダリングの候補を洗い出します。

ただし、リンクデータベースには、コードや設定ファイルの中からIDで参照しているものや、動的に読み込まれるものは記録されません。また、正確な結果を得るには事前にリンクデータベースを再構築しておく必要があります。リンクデータベースの結果だけで「未使用」と断定せず、ソースコードや設定ファイルとあわせて確認します。

前述の案件では、管理画面のカスタマイズ、パイプラインのカスタマイズ、サードパーティライブラリとの連携など、カスタマイズが広範囲に及んでおり、引継ぎ資料だけでは全容を追いきれませんでした。差分抽出と精査を通じてカスタマイズの全体像を再構築したことで、バージョンアップと並行して環境の技術的な把握も完了させることができました。

工程2：移行対象の選別

バージョンアップ後の環境に引き継ぐ機能と、廃止する機能を明確に線引きします。この際、Web担当者だけでなく、コンテンツ編集を行う事業部門や、連携先システムの管理者も巻き込み、責任範囲を明確化することが重要です。

工程3：標準化方針の策定

新環境では、どのようなディレクトリ構成、命名規則、設定パッチの管理方針を採用するかを定義します。設定パッチの配置ルールや権限設計をドキュメント化し、テンプレートとして整備しておくことで、担当者が替わっても判断根拠が失われない、属人化しない運用につながります。

前述の案件では、Sitecore.configを直接書き換える作りになっていたため、バージョンアップに際して、Sitecoreが推奨するパッチファイル方式に置き換えました。読み込み順序まで考慮して設計し直すことで、次回以降のバージョンアップでも標準ファイルとカスタム設定を分けて扱える状態に戻しています。

工程4：取り込みと切替の計画

Sitecore本体のバージョンアップでは、同じインスタンス上のサイトはまとめて新バージョンに切り替わるため、機能単位・サイト単位で段階的に移行することはできません。その代わりに、本番切替を複数回に分けて計画し、各回で動作検証とレビューを行います。

特に、バージョンアップ中も現行本番への改修案件がリリースされ続ける場合は、その取り込みタイミングを確保する必要があります。前述の案件では、並行案件のリリースごとにパッケージを並行プロジェクト側から受領して取り込む方式をとり、取り込みのタイミングを確保するために、本番切替を当初計画の2回から3回に増やしました。

また、負の遺産を再び持ち込まないためのゲートキーパーとして、取り込み時のレビュー工程を組み込むことが有効です。

引継ぎプロジェクトを成功させるには、発注側である情シス・Web担当者が以下の主導権を握ることが望まれます。

• 本番環境の管理者権限を発注側で保持し、引継ぎ完了後は前任ベンダーのアクセス権限を外して認証情報を変更する
• 前任ベンダーに対し、現時点でのGitと本番の差分の有無を文書で確認する
• 受領するドキュメントの一覧と、各ドキュメントの最終更新日を事前に提示させる
• 新ベンダー選定時には、差分検出・アセスメントの実績を評価軸に含める

これらを事前に設計しておくことで、バージョンアップ工程での調整工数を抑えられます。ただし、文書での確認があっても、前述の実例のように前任ベンダー自身が把握していない差分が残っている可能性はあります。

受領物の確認とは別に、2章の差分検出を実施することを前提にしてください。

Q. 前任ベンダーから引継ぎを受ける際、Gitリポジトリ以外に受領すべきものは何ですか。

Gitリポジトリに加え、本番環境のフルバックアップ（Webルート、設定ファイル、データベース、メディア）、CI/CDパイプラインの定義ファイル、各種認証情報、インフラ構成図、過去の障害対応履歴、カスタマイズ仕様書を受領することを推奨します。Sitecoreの場合は、ライセンスファイル、xConnectのクライアント証明書、Azureサブスクリプションやマネージドサービスの管理権限・契約情報もあわせて確認してください。認証情報は、メールなどで平文のまま受け渡さず、安全な方法でやり取りしたうえで、引継ぎ完了後に変更してください。また、App_Config配下の設定パッチの変更履歴や、Sitecoreアイテムのシリアライズデータの有無は必ず確認してください。

Q. 差分検出の作業期間はどの程度見込むべきですか。

期間は、サイトの規模そのものよりも、カスタマイズの範囲、比較対象となる環境の数（本番・検証環境、サーバーの役割ごとの台数）、Gitと本番環境の乖離の程度、引継ぎ資料の充実度によって大きく変わります。特に、経緯が分からない「判断保留」の差分が多いほど、その整理と関係者との合意形成に時間を要します。引継ぎプロジェクトでは環境把握のための工数も加わるため、スケジュールに余裕を持たせ、引継ぎを伴わない通常のバージョンアップとは別に見積もることをおすすめします。

Q. バージョンアップと負の遺産解消は同時に進めるべきですか、分けるべきですか。

原則として、バージョンアップのタイミングで負の遺産を整理することを推奨します。別フェーズに分けると、整理のためのテスト・リリース工程が二重に発生し、総工数が増加する傾向があります。進め方としては、差分の抽出・精査・修正をバージョンアップ本工程の前に事前工程として切り出し、その中で負の遺産の棚卸しもあわせて行う方法が有効です。総合テストに入る前に不確実性を減らせるため、スケジュールの見通しも立てやすくなります。