公開後の修正では、現在表示できている状態を残してから更新します。手元の最新ファイルだけでなく、サーバー上の直前版も復旧用に保管してください。
公開作業を小さなリリースとして扱う
更新前の状態を残し、問題が起きた場合に直前版へ戻せる順番で作業します。
文章1か所の変更でも、公開中のサイトへ反映する操作です。変更内容、確認方法、公開するファイル、戻すファイルを作業前に整理します。
複数の修正をまとめて公開する場合は、どの変更がどのファイルに入っているかをGitの差分で確認します。関係のない制作途中の変更を一緒に公開しません。
更新前・更新後の状態を残す
更新前のサーバーファイルと、更新に使うローカルのGitコミットを記録します。更新後にもコミットと公開日時を記録すると、どのコードが表示されているか追跡できます。
次の図では、「更新前・更新後の状態を残す」で押さえる違いを左右で比較しています。
- 更新内容と対象URL
- 変更したファイル
- 公開前に確認したGitコミット
- 公開日時
- 公開後の確認結果
- 問題時に戻すバックアップ
更新前に変更範囲を確認する
git statusとgit diffで変更したファイルを確認し、ブラウザで動作を検証してからコミットします。
差分をアップロードする
変更したHTML、CSS、JavaScript、画像だけを同じ場所へ上書きします。ファイルを削除・移動した場合は、HTMLから古いパスを参照していないか確認します。
次の図では、「差分をアップロードする」の仕組みや関係を確認できます。
古い表示が残る場合を切り分ける
次の図では、「古い表示が残る場合を切り分ける」で押さえる違いを左右で比較しています。
- 強制再読み込みまたはシークレットウィンドウで確認する
- Networkで実際に取得したファイルとステータスを確認する
- CDNやサーバーキャッシュを使っている場合は管理画面で削除する
- アップロード先と公開URLが一致しているか確認する
404が出たときの確認順
- Networkで404になったRequest URLを確認する
- HTML・CSS・JavaScriptのどこから参照しているか検索する
- サーバーの指定場所にファイルがあるか確認する
- 大文字・小文字と拡張子を比較する
- 公開URLの階層を基準にパスを見直す
404を隠すために同じファイルを複数の場所へ置かず、参照元と正しい保存場所を1つに決めて修正します。
表示崩れが出たときの確認順
最初にNetworkで新しいCSSを取得できているか確認します。取得できている場合はElementsとComputedで、対象要素へどのCSSが適用されているか見ます。
キャッシュを削除しても直らない場合は、更新したCSSの構文、セレクター、読み込み順を確認します。別の変更を追加して偶然直すのではなく、原因を特定します。
問題があれば直前版へ戻す
原因を特定できないまま公開状態を壊し続けず、バックアップした直前版を同じ場所へ戻します。復旧後にローカルで原因を直し、もう一度確認してから更新します。
ロールバック後も確認する
バックアップを戻しただけで終わらず、公開URL、Network、Consoleを再確認します。ロールバックしたファイルとブラウザが取得したファイルが一致していることを確認してください。
復旧後は、失敗した変更をそのまま再アップロードしません。ローカルで原因を再現し、修正と確認を終えてから新しいコミットとして公開します。
STEP 03で身につける公開の型
- ローカルで変更する
- ブラウザとDevToolsで確認する
- Gitへコミットする
- 公開前のサーバーをバックアップする
- 対象ファイルをアップロードする
- 公開URLを別環境で確認する
- 公開記録を残す
この型は、STEP 05でWordPressを公開するときにも使います。WordPressではファイルに加えてデータベースがあるため、バックアップ対象が増えます。
STEP 03の到達点
これで、ローカルで完成したLPをサーバーへ置き、URLから確認し、更新と復旧まで行える状態になりました。