Requisitos de actualización

Recomendaciones

• Incluye tantas nuevas actualizaciones como sea posible en tu proceso de actualización. Por ejemplo, en lugar de actualizar desde GitHub Enterprise 3.13 a 3.14 a 3.15, podrías actualizar desde GitHub Enterprise 3.13 a 3.15. Use el Asistente para actualización para buscar la ruta de actualización de la versión actual.
• Si estás varias versiones por detrás, actualiza tu instancia de GitHub Enterprise Server tanto como sea posible con cada paso del proceso de actualización. Utilizar la versión más reciente posible en cada actualización te permite aprovechar las mejoras de desempeño y las correcciones de errores. Por ejemplo, podrías actualizar desde GitHub Enterprise 2.7 a 2.8 a 2.10, pero actualizar desde GitHub Enterprise 2.7 a 2.9 a 2.10 utiliza una versión posterior en el segundo paso.
• Utiliza el lanzamiento de patch más reciente cuando actualices. Vaya a la página de versiones de GitHub Enterprise Server. Junto a la versión a la que va a actualizar, haga clic en Download y después en la pestaña Upgrading.
• Utiliza una instancia de preparación para probar los pasos de actualización. Para más información, consulta Configurar una instancia de preparación.
• Al ejecutar varias actualizaciones,asegúrate de que las migraciones de datos y las tareas de actualización que se ejecutan en segundo plano están completamente completas antes de continuar con la siguiente actualización de características. Para comprobar el estado de estos procesos, puede usar las utilidades de la línea de comandos ghe-migrations y ghe-check-background-upgrade-jobs. Para obtener más información, consulta Utilidades de la ea de comandos.
• Toma una captura de pantalla antes de que mejores tu máquina virtual. Para más información, consulta Tomar una instantánea.
• Asegúrate de que tienes un respaldo reciente y exitoso de tu instancia. Para más información, vea Archivo README.md de GitHub Enterprise Server Backup Utilities.

Requisitos

• Debe actualizar desde una versión de actualización de características que esté como máximo dos versiones por detrás. Por ejemplo, para actualizar a GitHub Enterprise 3.15, debes estar en GitHub Enterprise 3.14 o 3.13.
• Cuando hagas una mejora mediante un paquete de mejora, programa una ventana de mantenimiento para los usuarios finales de GitHub Enterprise Server.
• Puedes actualizar GitHub Enterprise Server a la versión de revisión más reciente mediante una revisión en caliente.

Puedes utilizar los hotpatches para subir de categoría a un nuevo lanzamiento parchado, pero no a un lanzamiento de características. Por ejemplo, puedes subir de nivel de 2.10.1 a 2.10.5 porque están en la misma serie de características, pero no de 2.10.9 a 2.11.0, porque están en una serie de características diferente.

Las revisiones en caliente no siempre requieren un reinicio. Al instalar la revisión en caliente, verá un mensaje en el terminal si alguno de los paquetes necesita reiniciarse para completar la actualización. Puede programar este reinicio en un momento que le convenga, pero se recomienda reiniciar tan pronto como sea práctico, especialmente si hay alguna corrección de seguridad.

Las revisiones en caliente requieren una ejecución de configuración, lo que puede provocar un breve período de errores o falta de respuesta en algunos servicios de tu instancia de GitHub Enterprise Server o en todos ellos. No es necesario habilitar el modo de mantenimiento durante la instalación de una revisión en caliente, pero si lo hace, se garantiza que los usuarios vean una página de mantenimiento en lugar de errores o tiempos de espera. Consulta Habilitar y programar el modo de mantenimiento.

• Es posible que un hotpatch requiera tiempo de inactividad si los servicios afectados (como kernel, MySQL, o Elasticsearch) requieren un reinicio de VM o un reinicio del servicio. Se te notificará cuando se necesite reiniciar. Puedes completar el reinicio más tarde.
• Es necesario que haya un almacenamiento raíz adicional disponible cuando se actualiza a través de un hotpatch, ya que instala múltiples versiones de determinados servicios hasta que se completa la actualización. El control de prevuelo te notificará si no tienes suficiente almacenamiento de disco raíz.
• Cuando se actualiza a través de un hotpatch, tu instancia no puede estar muy cargada, ya que puede impactar el proceso del hotpatch.
• Actualizar a GitHub Enterprise Server 2.17 migra tus registros de auditoría desde Elasticsearch a MySQL. Esta migración también incrementa la cantidad de tiempo y el espacio en disco que lleva restaurar una instantánea. Antes de migrar, controla el número de bytes en tus índices de registro de auditoría de ElasticSearch con este comando:

curl -s http://localhost:9201/audit_log/_stats/store | jq ._all.primaries.store.size_in_bytes

Utiliza el número para estimar la cantidad de espacio de disco que los registros de auditoría de MySQL necesitarán. El script también controla tu espacio libre en disco mientras la importación está en progreso. Controlar este número es especialmente útil si tu espacio libre en disco está cerca de la cantidad de espacio en disco necesaria para la migración.

Al actualizar, las comprobaciones previas al vuelo evalúan si los requisitos mínimos para los recursos de hardware del sistema, como la memoria, los núcleos de CPU y el almacenamiento en disco raíz y de usuario están disponibles para la instancia. Si las comprobaciones previas al vuelo determinan que no hay recursos suficientes o que fallan de otro modo, se le notificará y se anulará la actualización.

Pasos siguientes

Después de revisar estas recomendaciones y requisitos, puedes actualizar el GitHub Enterprise Server. Para más información, consulta Información general del proceso de actualización.