プレビュー・テスト・デプロイ——公開前後に確認すること

プレビューは公開前に見る確認画面

前の記事では、GitHubへの保存、mainへの反映、本番公開を分けて考えました。今回は、変更が読者に届く前後に何を確認するかを見ていきます。まずは、公開前に見た目や操作を確かめるプレビューです。

どこを見ればいい？

例えば、AIページに新しい記事を追加したとします。プレビューを開き、見出しや文章、画像が意図した順番で表示されるか確かめます。リンクやボタンを押したとき、期待した場所に移動するかも確認できます。

画面の幅によって見え方は変わります。パソコンでは読みやすくても、スマートフォンでは文字や画像が画面からはみ出すことがあります。両方の幅で確認し、実機で見ていなければ「実機は未確認」と区別しましょう。

プレビューと本番は同じ？

プレビューは確認のための画面で、読者がいつも見る本番サイトとは別のURLや環境になる場合があります。プレビューで修正が見えても、それだけで本番に反映されたことにはなりません。プレビューの仕組みがないサイトもあります。

確認用URLを開いたら、「これはプレビュー？ それとも本番？」「どのブランチや変更を表示している？」とChatGPTに確認します。古い変更を表示している画面と、今確認したい変更を取り違えないためです。

プレビューURLの扱い

プレビューは誰でも見られるものとは限りません。ログインやアクセス制限がある場合もあります。表示を確認できなかった人がいれば、見られた人の確認だけで全員が確認できたと決めず、理由を調べます。

ChatGPTへの依頼は「見た目を確認して」だけでも始められますが、「記事のタイトル、画像、次の記事へのリンクをスマートフォン幅でも確認して」のように、見たい場所を伝えると結果を読みやすくなります。

本番とそっくりな画面でも、アドレスが違えば別の確認画面かもしれません。見た目だけで判断せず、URLと対象を一緒に聞く習慣をつけましょう。

なるほど！ まずは何が起きているか、ひとつずつ確かめればいいんだね。

テストは決めた条件を確かめる

テストは、期待した動きやデータの条件が満たされるかを確かめることです。たとえば、記事一覧に追加した記事が現れるか、記録を保存した後に表示が変わるか、といった条件を確認できます。自動で繰り返せるテストもあります。

何を確かめている？

実際にどんな条件を調べるかは、用意されたテストによって異なります。リンクの行き先を調べるテストと、文章の誤字を見つける確認は別です。画像が読み込めるかを調べても、写真の構図が好みかどうかまでは分からないことがあります。

サイトを配信できる形にまとめる作業はビルドと呼ばれます。ビルドやテストが成功すると、少なくともその工程で検査した条件を満たした手掛かりになります。ただし、名前も内容も異なるため、何を実行したかを具体的に聞きましょう。

成功の意味を知る

テスト成功は、すべてを確認したという意味ではありません。ChatGPTに「何を、どの画面幅で確認した？」「表示の確認と、自動テストは両方行った？」と尋ねれば、成功の範囲を把握できます。

たとえば「自動テスト成功、PC表示を確認、スマートフォン実機は未確認」なら、それぞれが明確です。画面幅を小さくして表示を見たことと、実際のiPhoneで操作したことも同じではありません。

失敗と未確認を分ける

失敗したテストは、どの工程で何が起きたかを確認します。実施できなかったテストは「失敗」ではなく「未実施」として報告してもらいます。判断に必要な確認が足りなければ、公開前にどう補うか考えましょう。

たとえば、新しい記事が一覧に表示されるかを機械的に確認した後、実際の一覧を開いてタイトルや画像の切れ方を見ることもできます。それぞれ異なる観点なので、一方の結果をもう一方の確認結果と呼ばないようにします。

確認する項目は修正の内容に合わせて選びます。文章だけの変更でもリンクや表示順が変わることがあるため、「今回は何を確認する必要がある？」と事前に相談できます。

デプロイは変更を届ける公開処理

デプロイは、作成したサイトの変更を、サイトを動かす環境へ届ける処理です。読者が使う本番環境へのデプロイを、本番公開と呼ぶことがあります。届け先が確認用の環境である場合もあるため、「どこへのデプロイ？」と聞くことが大切です。

自動で始まる場合と手動の場合

サイトの設定によっては、mainの更新をきっかけにデプロイが自動で始まります。別の操作を行って手動で開始するサイトもあります。公開の仕組みは一律ではなく、設定を確かめてから進めます。

GitHub Actionsは、リポジトリの設定に沿って、テストやデプロイなどを自動実行できる仕組みです。すべてのサイトがActionsを使うわけではありませんし、使っていても実行される内容は設定によって違います。詳しくは後の記事で扱います。

処理が始まった後も確認

「公開処理を開始しました」は、完了の報告ではありません。実行中・成功・失敗などの結果を確認し、何をどの環境へ届けようとしたかも尋ねます。成功した場合でも、本番ページの表示まで見たかどうかは別の確認です。

例えば「mainへの反映は完了。公開処理は失敗。本番ページは未確認」という報告なら、どこで止まったかが分かります。mainが更新されていることと、公開処理が成功したことは別なので、片方の状態から他方を決めつけません。

再実行の前に状況を調べる

結果が不明な場合は、同じ公開をすぐ繰り返す前に、実行履歴と本番の状態を確認しましょう。すでに公開が完了している可能性もあります。必要に応じて原因を調べ、サイトの決められた手順で対応します。

公開方法を質問する例は「このサイトではmainへの反映後に自動で公開される？ 手動操作が必要？ 実行結果はどこで確認できる？」です。今のサイトの設定を調べた答えと、一般的な説明を分けてもらうと混乱しにくくなります。

公開後は読者の画面を確かめる

公開処理が成功したら、読者が普段アクセスする本番URLを開き、今回の変更が見えるか確認します。記事の例なら、見出し、本文、画像、一覧からのリンクなど、依頼した箇所を見てみましょう。

本番URLで見る

パソコンとスマートフォン相当の画面幅でレイアウトを確認し、必要なボタンも操作します。確認用データを使う場合は、実際の利用者の記録に影響しない方法を選びます。画面が開くことと、すべての機能が正しく動くことも別です。

プレビューと本番では、接続先や設定などが異なることがあります。公開前に問題がなくても、本番では画像やリンクが正しく表示されない可能性があります。だから公開後にも読者の画面を確認します。

見えないときに調べること

変更が見えなければ、「正しいURLか」「公開した変更は目的のものか」「公開処理は成功したか」を調べます。ブラウザや配信側に以前の内容が残っている場合もありますが、原因を決めつけず、一つずつ切り分けます。

コツエイゴでは、公開を明示的に依頼した際、決められた手順で対象のmainを公開し、結果と実際の画面を確認します。サイトによって手順は異なるため、この例をそのまま他のサイトに当てはめず、設定を調べましょう。

報告は確認範囲まで

ChatGPTからの報告は、「何を実行し、どこで確認し、何が未確認か」まで聞くと役立ちます。たとえば「公開処理は成功、本番記事をPC・スマホ幅で表示確認、実機操作は未確認」です。次の記事では、こうした終了地点を依頼の段階で伝える方法を学びます。

公開後の報告に「確認済み」とだけ書かれていたら、「本番のどのURLを開き、何を見た？」と聞きます。特定の記事ページだけを見たのか、一覧やリンク先も確かめたのかで、次に必要な確認が変わります。