履歴を共有する操作と、アプリを公開先で動かす操作を分けます。確認用のURLで試してから、利用者が開く本番のURLを確かめます。
この回は、しくみを読むことと、実際の結果を確かめる練習を組み合わせます。付属見本はブラウザーだけで保存する一人用の版です。アカウント・データベース・共有は拡張課題として扱います。
push、build、deployを分ける
手元の読書メモが使えるようになったら、どこまで進んだのかを書きます。ファイルを編集した、履歴へ記録した、リモートへ共有した、公開用の成果物を作った、公開先へ反映した。この五つを分けると、途中で止まった場合にも次の操作を探せます。ひとつの「できました」にまとめないことが、公開の第一歩です。
Gitのpushは、保存した履歴をリモートへ送る操作です。資料 S5 リモートはGitHub等に置いた共有先で、利用者がアプリを開く場所とは役割が違います。公開の自動化を設定していれば、pushが次の工程を動かすきっかけになります。その設定があることと、pushそのものの役割は分けて覚えます。
buildは、プログラムを公開先で使うための形へ組み立てる工程です。Next.jsの公式資料では、開発用の起動、build、サーバーの起動を別の操作として示しています。資料 S7 開発中に画面が開いても、公開用の組み立てが成功するとは限りません。依存する道具や、公開先で使う設定の違いもここで表に出ます。
確認用の公開から、本番の確認まで
組み立てた版を確認用の環境へ配置し、確かめた版を本番へ反映します。Gitへの共有と、各環境への配置は役割が違います。自動化の起動条件は設定に従います。
- build
- 確認用へdeploy
- 確認用URLで検証
- 本番へdeploy
- 本番URLで検証
- pushからbuildが自動で始まるかはプロジェクト設定によります。
- 図に掲載した公開サービスは、読者に必須の契約先を意味しません。
deployは、公開先へ版を届け、そこで利用できる状態へ進める操作です。採用するサービスによって方法が違います。npm run deployという名前があっても、何をするかはそのプロジェクトのscriptsで決まります。資料 S6 知らないプロジェクトのコマンドを、そのまま読書メモへ移す前に、定義と配信先を確認します。
制作時に確認したAMPLの構成では、Cloudflare WorkersとOpenNextを使い、cf:buildとcf:deployを分けています。プロジェクトの案内には、GitHubへpushしただけでは本番へ反映されないとあります。CloudflareにもOpenNext向けの公式資料があります。資料 S19 これは工程を理解する具体例です。読者のアプリも同じ構成にする必要はありません。
公開の前に、確認用のURLを使います。一般にプレビューと呼ばれる段階です。本番と違うURLへ今回の版を出し、第9章の入力を試します。確認用という名前だけで非公開とは決めず、誰がURLを開けるかを調べます。試験用の題名とメモを使えば、動作の確認に本当の記録を持ち込まずに済みます。
一人用の版を公開しても、ブラウザー内の読書メモが自動で共有されるわけではありません。localStorageは開いているページのoriginごとに分かれます。資料 S31 手元のURLと公開URLでは、保存した記録の見え方が異なり得ます。アプリの画面を公開することと、データを複数端末で共有することを別の完成条件にします。
確認を終えたら、本番へ反映する版を決めます。どの変更が入り、どの確認をしたかを短く残します。AIが公開作業を手伝う場合も、配信先の名前とURLを依頼へ添えます。反映後はそのURLを開き、変更した箇所で一件を登録します。作業の成功メッセージと、利用者の画面の結果を両方見て終えます。
公開前にAIへ確認する
まちの読書メモの公開先と、使う公開手順を説明してください。
pushで自動反映される設定があるかを、ファイルから確認してください。
まず確認用URLで練習データを試し、結果を報告してください。
本番へ反映する前に、対象の版とURLを示してください。
手を動かす順番
- push・build・deployが何をするかを調べる
- 確認用URLで第9章の確認を行う
- 本番URLで今回変えた箇所を使う
名前、通信、保存先を確かめる
公開されたアプリには、利用者が開くURLがあります。サービスが用意したURLで使い始めることも、自分のドメインを付けることもできます。ドメインは、人が覚えやすい名前です。名前を決めたことと、その名前が正しい公開先へ向いていることは別なので、実際に開くところまで確かめます。
DNSは、その名前を通信先へ結び付ける仕組みです。資料 S2 住所録のたとえで考えると、アプリの中身を作る仕事と、住所録へ宛先を登録する仕事が分かれます。公開先の案内にあるレコードの種類と値を確認し、どの名前の設定を変えるかを書きます。すでにメール等に使っている設定を、まとめて書き換えないようにします。
DNSの変更には、見る場所やタイミングの違いが出ます。Cloudflareの資料は、TTLという値がレコードの有効な期間と、変更が利用者へ届く時間に関係すると説明します。資料 S18 直後に古い表示が見えても、すぐに別の設定へ変更を重ねず、現在の値と公開先の状態を確かめます。
公開URLの下の設定を分けて確かめる
利用者が開く名前、通信の保護、動く版、保存先を別々に確認します。HTTPSの設定だけで、利用者ごとのデータの許可まで決まるわけではありません。
- URLの名前
- DNS
- HTTPS
- 公開する版
- 保存先
- 誰が開けるか
- 確認用URLにも公開範囲の確認が必要です。
- 一人用のローカル保存と共有データベースを区別します。
URLの先頭にあるHTTPSも確認します。HTTPSはTLSを使って、ブラウザーとサーバーの間の通信を暗号化する仕組みです。資料 S17 保存したメモを誰に見せるかという許可とは役割が違います。通信が暗号化されていても、アプリが他人のメモを渡す設計なら、そのデータへのアクセスは防げません。
公開先の設定には、使うデータベースの接続先や秘密の設定も入ります。確認用の版が、本番の保存先へ書き込まないかを見ます。画面にプレビューと出ていても、保存先の設定まで分かれているとは限りません。URL、保存先、秘密の設定、利用者の四つを、環境ごとに並べると確認しやすくなります。
データベースを使う版では、公開用のキーと秘密のキーの置き場所をもう一度調べます。Supabaseの秘密のキーは、利用者のブラウザーへ渡すものではありません。資料 S9 設定欄へ値を入れた後も、画面のファイルへ値が混ざっていないかを確認します。AIへ説明を求めるときは、値の全文を貼らず、設定名と結果を伝えます。
スマートフォンで本番のURLを開きます。一人用のブラウザー保存なら、そこで新しく登録した記録は、その端末のそのブラウザーに保存されます。パソコンで作った一件が出ないことを、すぐに不具合とは扱いません。端末をまたいで同じ記録を使いたいなら、アカウントと共有する保存先を加える次の段階を選びます。
公開後の確認には、開く、登録する、一覧へ戻る、再読み込みする、の一往復を使います。さらに空欄での説明、長い題名の折り返し、別の利用者への拒否を、採用した版に応じて試します。URLが存在することから一歩進めて、使う人が期待した動作を得られることまで確認し、公開結果として残します。
環境ごとの確認メモ
開発用: 手元のURL／練習用データ／自分が確認する。
確認用: プレビューURL／試験用の保存先／開ける人の範囲を確認する。
本番: 利用者のURL／運用する保存先／今回反映した版を確認する。
一人用の版では、公開してもデータが端末間で同期するとは説明しない。
手を動かす順番
- 公開先のURLとDNSの宛先を確認する
- HTTPSとデータへの操作許可を分けて調べる
- 実際の端末で登録から再読込まで行う
演習：公開の道筋を一枚にする
まちの読書メモについて、履歴の共有先、確認用のURL、本番のURL、保存先を図へ書きます。未契約や未設定の項目は、予定として明示してください。
- pushの後に何が起きる設定なのかを調べる。
- 確認用と本番について、URLと保存先をそれぞれ書く。
- 公開する版に合わせ、スマートフォンで一往復を確かめる項目を作る。
解答例を読む
Gitの共有が成功したことと、本番へ反映されたことには別の証拠が必要です。
一人用の版では、パソコンとスマートフォンの記録が別々でも仕様どおりです。
未公開なら完成扱いにせず、確認できた範囲と次の操作を明記します。
この回で確かめること
- pushの後に何が起きる設定なのかを調べる。
- 確認用と本番について、URLと保存先をそれぞれ書く。
- 公開する版に合わせ、スマートフォンで一往復を確かめる項目を作る。