GitHub Enterprise Server は常に改善されており、機能とパッチのリリースによって新機能とバグ修正が導入されています。
通常、機能リリースは四半期ごとに行われ、新機能と機能のアップグレードが含まれます。
GitHub Enterprise Server 3.0 以降、すべての機能リリースは少なくとも 1 つのリリース候補から始まります。 リリース候補は、完全な機能一式を備えた機能リリースとして提案されています。 リリース候補には、実際に GitHub Enterprise Server を使用している顧客からのフィードバックを通じてのみ見つけることができるバグまたは問題がある可能性があります。
リリース候補が利用可能になり次第、リリース候補をテストすることで、最新の機能に早期アクセスできます。
パフォーマンス、安定性、セキュリティ上の理由:
- 運用環境にリリース候補をインストールしないでください。 リリース候補ビルドは、テスト環境またはステージング環境で使うことのみを目的としています。
- サポートされている以前のバージョンからリリース候補にアップグレードしないでください。 代わりに、新しいテスト環境にリリース候補をインストールします。
- リリース時にリリース候補から新しいバージョン (一般公開リリースを含む) にアップグレードしないでください。 代わりに、一般公開リリースが利用可能になり次第、リリース候補環境を破棄してください。
リリース候補をテストした際は、サポートに連絡してフィードバックをご提供ください。 詳しくは、「GitHub Support のドキュメント」を参照してください。
フィードバックを活用して、バグ修正やその他の必要な変更を適用し、安定した本番リリースを作成します。 新しいリリース候補ごとに、以前のバージョンで見つかった問題のバグ修正が追加されます。 リリースが広く普及可能になったら、GitHub は安定した機能リリースを公開します。
パッチ リリースは、ホットパッチとバグ修正のみで構成されており、より頻繁に発生します。 パッチ リリースは通常、最初のリリース時に利用可能になっています。リリース候補はありません。 パッチ リリースへのアップグレードには、通常 5 分未満のダウンタイムが発生します。
完全に新しい GitHub Enterprise Server インスタンスを設定し、そのインスタンスを任意に構成するには、「GitHub Enterprise Server インスタンスをセットアップする」と「GitHub Enterprise を設定する」を参照してください。
既存のインスタンスを新しいリリースにアップグレードするには、「リリース ノート」と「GitHub Enterprise Server をアップグレードする」を参照してください。 機能リリースは 2 リリースまで遅れている分にはアップグレードできるため、Upgrade Assistant を利用し、現在のリリース バージョンからのアップグレード パスを見つけてください。
Warning
新しい機能リリースにアップグレードすると、数時間のダウンタイムが発生し、その間、どのユーザーも Enterprise を使用できなくなります。 Enterprise 設定または REST API を使用して、グローバルアナウンスバナーを公開することにより、ダウンタイムについてユーザに通知できます。 詳細については、「Enterprise のユーザメッセージをカスタマイズする」および「GitHub Enterprise 管理用の REST API エンドポイント」を参照してください。