Skip to main content

Requisitos de atualização

Antes de atualizar o GitHub Enterprise Server, veja as recomendações e requisitos a seguir para planejar sua estratégia de atualização.

Observações:

  • Os pacotes de upgrade estão disponíveis em enterprise.github.com para as versões compatíveis. Verifique a disponibilidade dos pacotes de atualização necessários para concluir a atualização. Se um pacote não estiver disponível, entre em contato com o Suporte do GitHub Enterprise para obter assistência.
  • Se você estiver usando o Clustering do GitHub Enterprise Server, confira "Como fazer upgrade de um cluster" no Guia de Clustering do GitHub Enterprise Server para obter instruções específicas exclusivas sobre o clustering.
  • As notas de versão do GitHub Enterprise Server mostram uma lista abrangente dos novos recursos de cada versão do GitHub Enterprise Server. Para obter mais informações, confira a página de versões.

Recomendações

  • Inclua o mínimo possível de atualizações no seu processo. Por exemplo, em vez de atualizar do GitHub Enterprise 3.4 para o 3.5 e depois para o 3.6, atualize do GitHub Enterprise 3.4 para o 3.6. 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 o your GitHub Enterprise Server instance para a versão mais atual disponível a cada etapa do processo de upgrade. 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 "Como configurar uma instância de preparo".
  • Ao executar várias atualizações, espere pelo menos 24 horas entre atualizações de recursos para permitir que as migrações de dados e as tarefas de atualização executadas em segundo plano sejam totalmente concluídas.
  • Tire um instantâneo antes de atualizar sua máquina virtual. Para obter mais informações, confira "Como criar um instantâneo".
  • 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.6, você deve estar nas versões GitHub Enterprise 3.5 ou 3.4.
  • 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 GitHub Enterprise Server para a versão mais recente do patch usando um hotpatch, que não requer uma janela de manutenção e geralmente não requer reinicialização.

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

  • 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 é ú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.

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 "Como atualizar o GitHub Enterprise Server".