About staging instances
GitHub recommends that you set up a separate environment to test backups, updates, or changes to the configuration for GitHub Enterprise Serverインスタンス. This environment, which you should isolate from your production systems, is called a staging environment.
For example, to protect against loss of data, you can regularly validate the backup of your production instance. You can regularly restore the backup of your production data to a separate GitHub Enterprise Server instance in a staging environment. On this staging instance, you could also test the upgrade to the latest feature release of GitHub Enterprise Server.
Tip: You may reuse your existing GitHub Enterprise license file as long as the staging instance is not used in a production capacity.
Considerations for a staging environment
To thoroughly test GitHub Enterprise Server and recreate an environment that's as similar to your production environment as possible, consider the external systems that interact with your instance. For example, you may want to test the following in your staging environment.
- Authentication, especially if you use an external authentication provider like SAML
- 外部のチケットシステ� との統合
- 継続的インテグレーションサーバとの統合
- GitHub Enterprise Server APIを利用する外部のスクリプトあるいはソフトウェア
- メール通知のための外部のSMTPサーバ
ステージングインスタンスのセットアップ
- GitHub Enterprise Serverバックアップユーティリティを使って本番インスタンスをバックアップしてく� さい。 詳細は「アプライアンスでバックアップを設定する」の「GitHub Enterprise Serverバックアップユーティリティ について」セクションを参照してく� さい。
- 新しいインスタンスをステージング環境として動作するようにセットアップしてく� さい。 ステージングインスタンスのプロビジョニングとインストールについては、本番インスタンスと同じガイドが利用できます。 詳細は「GitHub Enterprise Serverインスタンスをセットアップする」を参照してく� さい。
- Optionally, if you plan to test GitHub Actions functionality in your test environment, review the considerations for your logs and storage. For more information, see "Using a staging environment."
- バックアップをステージングインスタンスにリストアしてく� さい。 詳しい情� �については "アプライアンスでのバックアップの設定"の"バックアップのリストア"セクションを参照してく� さい。