Atualizações de versão do AEM aem-version-updates
Saiba como o Adobe Experience Manager (AEM) as a Cloud Service integração e entrega contínuas (CI/CD) para manter seus projetos na versão mais recente.
CI/CD ci-cd
O AEM as a Cloud Service usa integração contínua e entrega contínua (CI/CD) para garantir que seus projetos estejam na versão AEM mais atual. Esse processo atualiza com facilidade suas instâncias de produção, preparo e desenvolvimento sem causar interrupções para os usuários.
Antes que suas instâncias sejam atualizadas automaticamente, uma nova versão de manutenção do AEM é publicada com 3 a 5 dias de antecedência. Durante esse período, sua instância de desenvolvimento pode ser atualizada automaticamente ou, caso esteja disponível, você pode acionar a atualização para suas instâncias de desenvolvimento. As atualizações de versão são aplicadas automaticamente primeiro aos ambientes de desenvolvimento. Se a atualização for bem-sucedida, o processo de atualização continuará nas instâncias de estágio e produção. As instâncias de desenvolvimento e de preparo atuam como um quality gate (portal de qualidade) automatizado, em que os testes personalizados são executados antes que a atualização seja aplicada no ambiente de produção.
NIMU (Atualizações de manutenção não invasivas) nimu
As Atualizações de manutenção não invasivas são atualizações automáticas aplicadas sem envolver os pipelines do cliente.
Por meio do NIMU, o cliente pode usar o pipeline a qualquer momento, mesmo se uma atualização de versão de AEM estiver programada ou em andamento e as atualizações de manutenção não aparecerão mais no histórico de execução do pipeline do cliente, facilitando o acompanhamento do histórico de implantações de código.
Atualizar atividades
A versão atual do AEM ainda pode ser verificada para cada ambiente, como antes, usando o painel Ambientes de interface do usuário do Cloud Manager. Os mesmos quality gates (portais de qualidade) usados no pipeline são usados pelas atualizações de manutenção não invasivas, incluindo os testes escritos pelo cliente.
Uma notificação da interface do usuário do Cloud Manager será enviada sempre que uma Atualização de manutenção não invasiva for aplicada aos ambientes do seu programa. Você pode configurá-lo para que também seja enviado ao seu email.
Tipo de atualizações update-types
Há dois tipos de atualizações de versão do AEM:
-
Atualizações de manutenção do AEM
- Eles são usados principalmente para fins de manutenção, incluindo as correções de erros e atualizações de segurança mais recentes.
- O impacto é mínimo, pois as alterações são aplicadas regularmente.
-
- Elas são lançadas em um cronograma mensal previsível.
Falha ao atualizar update-failure
As atualizações do AEM passam por um pipeline de validação de produto intenso e totalmente automatizado, envolvendo várias etapas, garantindo que não haja interrupção do serviço para nenhum sistema em produção. As verificações de integridade são usadas para monitorar a integridade do aplicativo. Se essas verificações falharem durante uma atualização do AEM as a Cloud Service, a versão não continuará e o Adobe investigará por que a atualização causou esse comportamento inesperado.
Quando você implanta uma nova versão de código personalizado em seu ambiente, os Testes funcionais de produtos e personalizados desempenham uma função crucial. Eles garantem que os sistemas de produção permaneçam estáveis e funcionais mesmo após uma alteração ser aplicada. Esses testes também são aplicados no processo de atualização da versão do AEM.
Se a atualização para o ambiente de produção falhar, o Cloud Manager reverterá automaticamente o ambiente de preparo. Isso é feito automaticamente para garantir que, após a conclusão de uma atualização, os ambientes de preparo e de produção estejam na mesma versão do AEM.
Da mesma forma, se uma atualização automatizada de um ambiente de desenvolvimento falhar, os ambientes de preparo e produção não serão atualizados.
Práticas recomendadas best-practices
-
Uso do Ambiente de Preparo
- Use um ambiente diferente (não Preparo) para ciclos longos de QA/UAT.
- Após a conclusão do teste de sanidade no preparo, mova para verificar na produção.
-
Pipeline de produção
- Pause antes de implantar na produção.
- Cancelar o pipeline após uma implantação de preparo indica que o código é "um descarte" e não é um candidato válido para Produção. Consulte Configuração de um pipeline de produção.
-
Pipeline de Não Produção
- Configure um pipeline de não produção.
- Acelerar a velocidade/frequência de entrega para falhas de pipeline de produção. Identifique problemas em pipelines de não produção ativando o Teste funcional do produto, o Teste funcional personalizado e o Teste de interface do usuário personalizada.
-
Cópia de conteúdo
- Use a Cópia de Conteúdo para mover conjuntos de conteúdo semelhantes para um ambiente de não produção.
-
Teste funcional automatizado
- Inclua testes automatizados em seu pipeline para que você possa testar a funcionalidade crítica.
- O Teste funcional do cliente e o Teste personalizado da interface do usuário estão bloqueando, caso falhem, a versão do AEM não será lançada.
Regressão regression
Se você encontrar um problema relacionado à regressão, envie um caso de suporte por meio do Admin Console. Se o problema for um bloqueador e estiver afetando a Produção, um P1 deverá ser gerado. Forneça todos os detalhes necessários para reproduzir o problema de regressão.
Armazenamento de nó composto composite-node-store
Geralmente, as atualizações incorrem em tempo de inatividade zero, inclusive para a instância de criação, que é um cluster de nós. As atualizações contínuas são possíveis devido ao recurso de repositório de nós compostos no Oak.
Esse recurso permite que o AEM faça referência a vários repositórios simultaneamente. Em uma implantação em andamento, a nova versão do AEM contém seu próprio /libs
(o repositório imutável baseado em TarMK). É diferente da versão mais antiga do AEM, embora ambos façam referência a um repositório mutável compartilhado baseado em DocumentMK que contém áreas como /content
, /conf
, /etc
e outras.
Como as versões antigas e as novas têm suas próprias versões do /libs
, elas podem estar ativas durante a atualização contínua. E ambos podem assumir o tráfego até que o antigo seja totalmente substituído pelo novo.
Informações adicionais further-information
Para obter mais detalhes sobre temas relacionados: