Requisitos de atualização

Neste artigo

• Recomendações
• Requisitos

Recomendações

• Inclua o mínimo possível de atualizações no seu processo. Por exemplo, em vez de atualizar do GitHub Enterprise 2.17 para o 2.18 e depois para o 2.19, atualize do GitHub Enterprise 2.17 para o 2.19.

• Se a sua versão estiver muito defasada, atualize a sua instância do GitHub Enterprise Server para a versão mais atual disponível a cada etapa do processo. Ao usar a versão mais recente em cada atualização, você pode aproveitar as melhorias de desempenho e as correções de erros. Por exemplo, você poderia atualizar do GitHub Enterprise 2.7 para o 2.8 e depois para o 2.10. No entanto, atualizar do GitHub Enterprise 2.7 para o 2.9 e depois para o 2.10 usa uma versão mais recente na segunda etapa.

• Ao atualizar, use a versão mais recente do patch. Browse to the GitHub Enterprise Server Releases page. Next to the release you are upgrading to, click Download, then click the Upgrading tab.

• Use uma instância de preparo para testar as etapas da atualização. Para obter mais informações, consulte "Configurar instância de preparo".

• Ao fazer várias atualizações, aguarde pelo menos 24 horas entre cada atualização de recursos para permitir a conclusão total das migrações de dados e das tarefas em segundo plano.

Requisitos

• Você deve atualizar quando a versão do recurso estiver defasada por no máximo duas versões. Por exemplo, ao atualizar para o GitHub Enterprise 2.19, você deve estar nas versões GitHub Enterprise 2.18 ou 2.17.

• You can upgrade GitHub Enterprise Server to the latest patch release using a hotpatch, which does not require a maintenance window and usually does not require a reboot. You can use hotpatching to upgrade to a newer patch release, but not a feature release. For example, you can upgrade from 2.10.1 to 2.10.5 because they are in the same feature series, but not from 2.10.9 to 2.11.0 because they are in a different feature series.

• Um hotpatch pode causar tempo de inatividade se os serviços afetados (como kernel, MySQL ou Elasticsearch) exigirem reinicialização da VM ou do serviço. Você receberá uma notificação quando/se a reinicialização for necessária. Será possível reinicializar em outro momento.

• Procure disponibilizar um armazenamento adicional na raiz durante a atualização, já que o hotpatching instala várias versões de alguns serviços até a conclusão da atualização. Caso não haja espaço suficiente, você receberá uma notificação das verificações preliminares.

• Ao atualizar pelo hotpatching, sua instância não pode ficar carregada demais (isso pode afetar o processo). Pre-flight checks will consider the load average and the upgrade will fail if the load average is too high.

• If you're upgrading a GitHub Enterprise Server cluster to version 2.16, ensure that you define both a primary datacenter and a Consul configuration in the cluster configuration file before you upgrade. For more information, see "Initializing the cluster."

• Upgrading to GitHub Enterprise Server 2.17 migrates your audit logs from Elasticsearch to MySQL. Além disso, essa migração aumenta a quantidade de tempo e espaço em disco necessários para restaurar um instantâneo. Antes de migrar, verifique o número de bytes nos índices de log de auditoria do Elasticsearch com este comando:

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

  Use o número para estimar o espaço em disco necessário para os logs de auditoria do MySQL. O script também monitora seu espaço livre em disco durante o andamento da importação. Monitorar esse número é útil principalmente se o espaço livre em disco estiver próximo da quantidade de espaço em disco necessária para a migração.

Após ler essas recomendações e requisitos, você poderá atualizar para o GitHub Enterprise Server. Para obter mais informações, consulte "Atualizar o GitHub Enterprise Server."