Requisitos de atualização

Recomendações

• Inclua o mínimo possível de atualizações no seu processo. Por exemplo, em vez de atualizar do GitHub Enterprise 3.10 para o 3.11 e depois para o 3.12, atualize do GitHub Enterprise 3.10 para o 3.12. Use o Assistente de atualização para localizar o caminho de upgrade começando na sua versão atual.
• Se a versão estiver muito desatualizada, atualize a sua instância do GitHub Enterprise Server para a versão mais atual possível a cada etapa do processo de atualização. 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. Navegue até a página Versões do GitHub Enterprise Server. Ao lado da versão para a qual você está atualizando, clique em Baixar e clique na guia Upgrade.
• Use uma instância de preparo para testar as etapas da atualização. Para obter mais informações, confira "Configurar uma instância de preparo".
• Ao executar múltiplas atualizações, certifique-se de que as migrações de dados e as tarefas de atualização em execução em segundo plano estejam totalmente concluídas antes de prosseguir para a próxima atualização de recurso. Para verificar o status desses processos, é possível usar os utilitários de linha de comando ghe-migrations e ghe-check-background-upgrade-jobs. Para obter mais informações, confira “Utilitários de linha de comando”.
• Tire um instantâneo antes de atualizar sua máquina virtual. Para obter mais informações, confira "Atualizar o GitHub Enterprise Server".
• Certifique-se de ter um backup recente e da sua instância. Para obter mais informações, confira o arquivo LEIAME.md do GitHub Enterprise Server Backup Utilities.

Requisitos

• Você precisa fazer upgrade de uma versão de recurso que esteja no máximo duas versões atrás. Por exemplo, ao atualizar para o GitHub Enterprise 3.12, você deve estar nas versões GitHub Enterprise 3.11 ou 3.10.
• Ao fazer a atualização com um pacote de atualização, agende um período de manutenção para usuários finais de GitHub Enterprise Server.
• Você pode atualizar o GitHub Enterprise Server para a versão mais recente do patch usando um hotpatch.

Você pode usar hotpatching para atualizar para uma versão de patch mais recente, mas não uma versão de recursos. Por exemplo, é possível atualizar da 2.10.1 para a 2.10.5 porque elas estão na mesma série de recursos, mas não da 2.10.9 para a 2.11.0 porque elas estão em séries de recursos diferentes.

Os hotpatches geralmente não exigem reinicialização. Se um hotpatch exigir uma reinicialização, as notas de versão do GitHub Enterprise Server indicarão o requisito.

Os hotpatches exigem uma execução de configuração, o que pode causar um breve período de erros ou falta de resposta para alguns ou todos os serviços em sua instância do GitHub Enterprise Server. Você não precisa habilitar o modo de manutenção durante a instalação de um hotpatch, mas isso garantirá que os usuários vejam uma página de manutenção em vez de erros ou tempos limite. Para obter mais informações, confira "Habilitar e programar o modo de manutenção".

• 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).
• A atualização do GitHub Enterprise Server 2.17 migra seus logs de auditoria do Elasticsearch para o 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 é importante, principalmente se o espaço livre em disco estiver próximo da quantidade de espaço em disco necessária para a migração.

Próximas etapas

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