Na fase de implementação da jornada, você explorará as ferramentas através das quais pode tornar seu código e conteúdo prontos para serem transferidos para o AEM as a Cloud Service.
Nas partes anteriores da jornada, você passou pelo familiarizar-se com as mudanças no AEM as a Cloud Servicee determinado se a implantação está pronta para ser movida para a nuvem com o fase de preparação.
Este artigo continua com conselhos sobre como usar as ferramentas fornecidas pelo Adobe para garantir que seu código e conteúdo estejam prontos para serem movidos para a nuvem.
Este documento tem como objetivo:
Antes de começar, você deve se familiarizar com o Cloud Manager, pois ele é o único mecanismo para implantar código no AEM as a Cloud Service.
O Cloud Manager permite que as organizações gerenciem automaticamente o AEM na Nuvem. Inclui uma estrutura de integração contínua e entrega contínua (CI/CD) que permite que as equipes de TI e os parceiros de implementação acelerem a entrega de personalizações ou atualizações, sem comprometer o desempenho ou a segurança.
Você pode se familiarizar com o Cloud Manager consultando os recursos abaixo:
Jornada integrada para entender os recursos de autoajuda sobre integração ao Experience Manager as a Cloud Service.
Integração do Git com o Adobe Cloud Manager para saber mais sobre o uso de um único repositório Git para implantar código.
Configuração do Adobe Experience as a Cloud Service para saber mais sobre como gerenciar produtos e o acesso dos usuários no Admin Console.
As etapas exatas da sua transição para o Cloud Service dependem dos sistemas que você adquiriu e das práticas de ciclo de vida de desenvolvimento de software seguidas.
A figura a seguir mostra as principais etapas envolvidas na fase que envolve a conversão do código e do conteúdo para uso com o AEM as a Cloud Service:
Começaremos a detalhar as ferramentas que você deve usar para fazer isso nos capítulos abaixo.
Para migrar o conteúdo da instância de AEM atual para a instância de Cloud Service, use a Ferramenta de transferência de conteúdo do Adobe.
Com essa ferramenta, você pode especificar o subconjunto de conteúdo desejado que deseja transferir da instância de origem do AEM para a instância do AEM Cloud Service.
A migração de conteúdo é um processo de várias etapas que requer planejamento, rastreamento e colaboração entre equipes diferentes.
Para obter detalhes completos sobre como a ferramenta funciona e como o Adobe recomenda usá-la, consulte o Documentação da ferramenta Transferência de conteúdo.
É hora de começar a refatorar os recursos existentes para serem compatíveis com o Cloud Service.
Primeiro, observe a documentação que detalha as ferramentas básicas e comece a refatorar seu código:
Além disso, também é possível:
Assista a este vídeo para entender como instalar o SDK do Dispatcher localmente:
Assista a este vídeo para entender como configurar o SDK do Dispatcher:
Desenvolver e executar código no AEM as a Cloud Service requer uma mudança na mentalidade. Vale lembrar que o código deve ser resiliente, especialmente porque uma instância pode ser interrompida a qualquer momento. O código em execução no Cloud Service deve reconhecer o fato de que ele está sempre em execução em um cluster. Isso significa que sempre há mais de uma instância em execução.
Certas alterações são necessárias para que os projetos AEM Maven sejam compatíveis com a nuvem. O AEM as a Cloud Service exige uma separação de conteúdo e código em pacotes distintos para implantação no AEM:
/apps
e /libs
são consideradas áreas imutáveis do AEM, pois não podem ser alteradas após o início do AEM (ou seja, no tempo de execução). Isso inclui operações de criação, atualização ou exclusão. Qualquer tentativa de alterar uma área imutável no tempo de execução falhará.
Todo o restante no repositório (por exemplo, /content
, /conf
, /var
, /home
, /etc
, /oak:index
, /system
, /tmp
) são áreas mutáveis, o que significa que podem ser alteradas em tempo de execução.
Você pode saber mais consultando o Estrutura de pacotes recomendada documentação.
O Adobe fornece várias ferramentas para ajudar a acelerar algumas de suas tarefas de refatoração de código. Compreender essas ferramentas e os problemas que elas resolvem reduzirá a complexidade da migração e o tempo.
Depois de configurar o ambiente de desenvolvimento local, familiarize-se com o SDK as a Cloud Service do AEM consultando a documentação.
Para gerenciar o desenvolvimento contínuo do código no AEM ativo, juntamente com as tarefas de refatoração de código como parte da jornada de transição, a Adobe AEM recomenda que você programe um período de congelamento do código até concluir a reestruturação do projeto Maven para que ele seja compatível com o as a Cloud Service.
Quando a reestruturação do projeto estiver concluída, você poderá retomar o desenvolvimento de novos códigos com base nessa nova estrutura. Isso reduz as falhas de pipeline do Cloud Manager durante os testes e a implantação do código.
As tarefas de Transferência de conteúdo e Refatoração do código não precisam ser realizadas sequencialmente. Elas podem ser realizadas independentemente uma da outra. No entanto, é necessário ter a estrutura correta do projeto para garantir que o conteúdo seja renderizado com êxito no seu ambiente do Cloud Service.
O pipeline do Cloud Manager oferece suporte à execução de testes que são executados no ambiente de preparo.
Siga as práticas recomendadas nos documentos abaixo relacionados ao teste de qualidade do código:
A preparação do sistema de origem para migração envolve tarefas no nível do administrador do sistema e do AEM. Você pode começar verificando se o repositório de conteúdo está em um estado bem mantido, marcando a opção limpeza de revisão e a variável coleta de lixo do armazenamento de dados status da tarefa. Se você estiver executando a versão 6.3 do AEM (já que a ferramenta Transferência de conteúdo é compatível da versão 6.3 em diante), é recomendável executar a compactação offline, seguida da coleta de Lixo do Data Store.
Verificação de consistência de dados O é recomendado em todas as versões do AEM para garantir que o repositório de conteúdo esteja em bom estado para iniciar as atividades de migração.
É necessário acesso em nível de administrador do sistema para instalar e configurar AZCopy
Também é recomendável revisar todos os ativos, páginas, projetos AEM, usuários e grupos não utilizados para economizar tempo na migração. Consulte a Integridade do repositório de conteúdo seção.
Uma vez que o acesso a um clone de produção está estabelecido, prossiga para verificar a integridade do repositório. Como mencionado na seção anterior, o objetivo é limpar e compactar o repositório na origem antes de iniciar a migração. Essa etapa possivelmente economizará muito tempo, caso contrário, gastará na solução de problemas assim que a migração começar.
Item de Ação | Principais pontos |
---|---|
Usuários, grupos e permissões | Você precisa entender o volume de usuários, grupos e a complexidade em torno das associações. Procure oportunidades para limpar usuários e grupos não utilizados na origem antes da migração. |
Processamento de ativo incompleto | Tente concluir o processamento de ativos no sistema de origem antes de iniciar a migração para evitar possíveis preocupações na migração as a Cloud Service do AEM. |
Integridade do conteúdo | É recomendável consultar conteúdo incorreto e removê-lo antes de iniciar a migração. Por exemplo, procure ativos ou páginas que não têm representações originais ou que estão presas no processamento de fluxo de trabalho. Consulte também Integridade do ativo. |
A variável Estratégia e cronograma de migração de conteúdo A seção detalha mais como extrapolar os dados coletados e criar um plano de migração.
A coleta de dados pode ajudar você a planejar as atividades de migração e as tarefas associadas. Os tempos de extração e assimilação são especialmente úteis porque os pontos de dados podem ser associados a um tamanho específico do conjunto de migração. Dessa forma, esses pontos de dados podem ser extrapolados para criar um plano:
Esses pontos de dados também podem ajudar você Estabelecer KPIs e outras tarefas relacionadas à migração.
Com base nos pontos de dados coletados (veja acima), é possível criar um plano de migração que possa ser integrado a um plano de projeto de macro. Esta etapa permitirá que todas as principais partes interessadas visualizem e planejem as atividades de migração.
A tabela a seguir ilustra um plano de migração típico:
Iteração de migração | Data inicial | Data de Término Estimada | Dependências | Duração Estimada (em dias) | Detalhes adicionais / Itens de ação |
---|---|---|---|---|---|
PRDCLONE-AUTHOR-INITIAL-USRMAP-CSSTAGE-AUTHOR | |||||
PRDCLONE-PUBLISH-TOPUP-CSSTAGE-AUTHOR |
Como você pode ver na tabela acima, é útil seguir um formato de nomenclatura específico para identificar as iterações de migração, por exemplo: PRDCLONE para o ambiente de AEM de origem , AUTOR/PUBLICAÇÃO para o ambiente as a Cloud Service do AEM, CSSTAGE-AUTHOR para a instância as a Cloud Service do AEM e assim por diante.
Alguns detalhes importantes que influenciam seu plano de migração:
O número total de extrações necessárias
Número total de assimilações necessárias
Você pode usar o rastreador de migração para anotar os horários das execuções iniciais e complementares. Esses pontos de dados ajudarão você a formular requisitos realistas de congelamento de conteúdo antes do acréscimo final.
O rastreador também ajudará você a:
A tabela a seguir ilustra um rastreador de migração funcional:
Origem (Ambiente / Instância / URL) | Destino (Ambiente / Instância / URL) | Nome, tipo (inicial ou complementar) do conjunto de migrações | Tamanho do Conjunto de Migração (MB) | Mapeamento de usuários (Sim/Não) | Duração da extração (início, fim, tempo gasto) | Duração da assimilação (início, fim, tempo gasto) | Problemas/Resoluções/Detalhes |
---|---|---|---|---|---|---|---|
A seção a seguir mostra as etapas importantes e as tarefas associadas que podem ser usadas para formular uma estratégia de migração de conteúdo e uma linha do tempo.
Depois de entender completamente como avaliar se a instalação do AEM está pronta para ser transferida para a nuvem, à medida que aprendemos a usar as ferramentas necessárias para torná-la pronta, é hora de seguir para a fase de ativação.