障害時の対応とロールバック

このページは、サーバーリソースパックの新しいバージョンを公開した後に「テクスチャが崩れている」「アイテムが表示されない」などの不具合が見つかったときに、何を確認し、どう前のバージョンへ戻す（ロールバックする）かをまとめたものです。リリース自体の通常手順はリソースパックの更新と公開を、開発環境の準備は開発バージョンの利用方法を参照してください。

「ロールバック」とは、公開してしまった新しいバージョンを取り消して、問題が起きる前の状態に戻すことです。

まず確認すること（切り分け）

ロールバック作業に入る前に、本当にリソースパックの新しいバージョンが原因かどうかを確認してください。

1. 報告してきたプレイヤーの人数・状況を確認します。1人だけの場合は、そのプレイヤーの手元のリソースパックの再ダウンロードがうまくいっていない、Minecraft側のキャッシュが残っている、といった可能性もあります。まずはMinecraftを再起動する、リソースパックを一度無効化してから再度有効化するよう案内してみてください。
2. 複数人・多くのプレイヤーで再現する場合は、直近のリリースが原因である可能性が高くなります。
3. GitHubのmofupack_officialリポジトリの「Actions」タブで、直近のリリースに対応する自動処理（Actions）が緑のチェックで正常終了しているか確認します。赤い×で失敗している場合は、後述の「GitHub Actionsが失敗（赤い×）したとき」を確認してください。
4. Actions自体は成功しているのに反映されていないように見える場合は、リソースパックの更新と公開にある/brp reload、/brp generatehashes、/brp reloadの3コマンドが正しい順番でサーバー内で実行されているか確認してください。実行できていなければ、まずこれを実行してみてください。

ロールバックの手順（方法A：とにかく早く前のバージョンに戻す）

原因のファイルが具体的にどれか分からなくても、「直前のバージョンでは問題がなかった」ということさえ分かれば実行できる、もっとも簡単な方法です。緊急時はまずこちらを検討してください。

1. GitHubのmofucraft/mofupack_officialリポジトリの「Releases」一覧を開き、問題が起きる前の最後の正常なバージョン（タグ名。例:9.24.1）を確認します。
2. そのリリースのページを開くと、タグ名の近くに、そのバージョンを作成した時点のコード状態（コミット）へのリンクがあります。念のためどのコミットだったかを控えておきます。
3. 「Releases」一覧から「Draft a new release」（新しいリリースを作成）を開きます。
4. リリースの対象（Target）を選ぶ欄で、通常のブランチ名ではなく、手順2で確認した「以前の正常だったコミット」を指定します。Target欄のドロップダウンには、ブランチだけでなく直近のコミットから選べる項目があるので、そちらから探します。見つからない・操作に迷う場合は無理をせず、後述のエスカレーション先に相談してください。
5. タグ名には、これまでに使われていない新しい番号を付けます（既存のタグ番号を使い回さないでください）。タグ番号の付け方のルールはリソースパックの更新と公開の「リリースを行える人と判断基準」を参照してください。
6. リリースを公開すると、通常のリリースと同じくGitHub Actionsが自動で実行されます。完了まで待ち（15分程度かかることがあります）、正常終了を確認したら、サーバー内で/brp reload、/brp generatehashes、/brp reloadを順番に実行してください。
7. この時点では、develop・releaseどちらのブランチへのマージも行わないでください。このロールバック用のリリースは「応急処置」であり、原因となった変更そのものはまだリポジトリ内に残っています。原因の特定・修正が終わってから、あらためて正しい手順でリリースし直してください。

ロールバックの手順（方法B：原因のコミットを特定して打ち消す）

原因になった変更（コミット）がはっきり分かっている場合は、その変更だけを打ち消す方法もあります。

1. GitHub Desktopで、問題の変更が含まれるブランチ（通常はdevelop）に切り替えます。
2. 画面上部の「History」タブを開き、コミットの一覧から原因と思われるコミットを探します。リリースページに書かれた変更内容の説明が手がかりになります。
3. 該当のコミットを右クリックし、「Revert Changes in Commit」（このコミットの変更を取り消す、といった表記の項目）を選びます。これにより、そのコミットの内容だけを打ち消す新しいコミットが自動的に作成されます。過去の履歴が消えるわけではないので、安全な操作です。
4. 「Push origin」でGitHubへ変更を送信します。
5. 開発バージョンの利用方法の手順でpullし、実際に問題が直っているかを手元のMinecraftで確認します。
6. 問題が直っていることを確認できたら、リソースパックの更新と公開の通常手順（動作のテスト→リリースの作成→Actionsの実行→releaseブランチへのマージ）に沿って、新しいバージョンとして公開し直します。

原因のコミットが1つに絞れない、複数人の変更が絡んでいて打ち消すと他の変更まで消えてしまう、といった場合は、無理に自己判断で進めず、後述のエスカレーション先に相談してください。

GitHub Actionsが失敗（赤い×）したとき

リリースを作成すると自動で走るGitHub Actionsの処理が、途中で失敗することがあります。失敗すると、GitHubの実行結果に赤い×が表示されます。

確認方法

1. GitHubのmofucraft/mofupack_officialリポジトリを開きます。
2. 上部の「Actions」タブを開きます。
3. 一覧の一番上あたりに、直近のリリース作成に対応する実行が表示されます。アイコンが緑のチェックなら成功、赤い×なら失敗、黄色い丸なら実行中です。
4. 赤い×の実行をクリックして開くと、どのステップで失敗したかが赤色で表示されます。失敗したステップをクリックすると、詳しいエラーメッセージ（ログ）が表示されます。

典型的な原因と対処

どこまで自分で対処してよいか／エスカレーションの目安

次のような対応は、リリースを行える人であれば自分の判断で進めて問題ありません。

• 失敗したActionsの「Re-run jobs」（再実行）
• developブランチ上の明らかなファイルミス（ファイル名・画像サイズ・文字コードなど）の修正と、リリースの作り直し
• 自分が加えた変更が原因だとはっきり分かっている場合の、GitHub Desktopでの取り消し（Revert Changes in Commit）
• 上記「方法A：とにかく早く前のバージョンに戻す」による緊急ロールバック

次のような場合は、自己判断で進めず、turu64さんまたは【要記入: 代理のエスカレーション先】に相談してください。

• FTPやDiscord Webhookなど、外部サービス連携のステップが失敗している場合
• 原因のコミットが特定できない、複数人の変更が絡んでいて切り分けが難しい場合
• GitHub organizationへの新規招待や、シークレットの追加・変更が必要になった場合
• 方法A・方法Bのロールバックを行っても問題が解決しない場合
• 何を触ってよいか判断に迷う場合

緊急時の連絡先: 【要記入: turu64さん本人の連絡手段、および連絡が取れない場合の代理担当者】

関連ページ

• リソースパックの更新と公開
• 開発バージョンの利用方法
• 権限・インフラ一覧