デプロイ

以下はクライアントがホスティングする本番サーバーとは別に制作期間中の確認用テストサーバーについて認識しておくべき点を記載しています。

対応するメリット

制作期間中にブランチに紐付いたサイト断面をチームやクライアントと共有することで

意思決定
すり合わせ
迅速なフィードバック

が可能になります。

例：
メイン：https://example-test-server.dev.com/about/
制作途中（プルリクエスト中など）：https://issue-14.example-test-server.dev.com/about/

また、自動かつ継続的にデプロイする機構を事前に用意しておくことで、制作の内部ループの稼働時間を増やすことができ、必然的にコード品質の向上が促されます。

※内部ループは個々の開発者が日常的に行う短期的な作業に焦点を当てることを指します。外部ループはチーム全体で行う長期的な作業や開発とは直接関係のないプロジェクトに必要な事務的作業などを指します。

内部ループ→スループットに繋がります。ここに注力することがプロジェクトの売上に結びつきます
外部ループ→プロジェクトの中の経費です。合理的に削減できることが望ましいでしょう

VPSなどいわゆるレンタルサーバーを使用する場合はブランチごとのサブドメインを簡易に発行できるかを確認してください。別途設定が必要になるなど困難であればサーバーレスプラットフォームを検討してください。レンタルサーバーであっても手動でのFTPアップではなくGitHub Actionsなどで一定のワークフローを作成し自動化させてください。

CD（継続的デプロイ）の設定

GitHubリポジトリとサーバーレスプラットフォームを紐づけ、制作期間中のCD（継続的デプロイ）を可能にします。

サーバーレスプラットフォームの例

サイトを保護する

テストサーバーはベーシック認証などで外部からのアクセスを制限します。ベーシック認証のパスワードは推測されにくいランダム生成された

大文字小文字を含む英数記号10桁以上

で設定します。（解析されたとしても、既にサイトが公開されている程度の時間はかかっているでしょう）

また、ユーザー名とパスワードは以下の様な場所に適切に保存します。

プライベートリポジトリのテストサーバーにアップされないドキュメント内
GitHub Secrets、サーバーレスプラットフォームの環境変数
プロジェクトメンバーのみがアクセスできるクラウドサービス内のドキュメント

特にサーバーへアップされるJavaScriptファイル内などに直接ユーザー名とパスワードを記述することは避けてください。

const NAME = "super"
const PASS = "secret" // このファイルが持ち出されるとパスワードも持ち出されてしまう

...
// Exiting code
...

// basic auth script
const Credentials = function(name, pass) {
  this.name = name
  this.pass = pass
}

const NAME = import.meta.SECRETS_NAME
const PASS = import.meta.SECRETS_PATH // プラットフォームなどで設定した環境変数

...
// Exiting code
...

// basic auth script
const Credentials = function(name, pass) {
  this.name = name
  this.pass = pass
}

テストサーバーを適切に閉鎖する

無事プロジェクトがローンチされた後、いつまでもテストサーバーを残すことは管理コスト、セキュリティの両面から避けたほうが無難です。
どの程度の期間で閉鎖するかはクライントとすり合わせましょう。制作側で棚卸し期間等を設定し、そこを目安に閉鎖するか確認をするのが望ましいです。

例：
制作者「サイトリリース後2年程度でテストサーバーは任意で閉鎖する可能性があります。」
クライアント「OK」 or 「◯年程度維持してください。」 or 「リリース後に連絡しますので速やかに閉鎖してください。」