DocumentaçãoAEMGuia do usuário

Migrar um site de produção production-migration

Última atualização: 12 de novembro de 2026
  • Aplica-se a:
  • Experience Manager as a Cloud Service

Criado para:

  • Usuário
  • Admin
  • Desenvolvedor

Use esse fluxo de trabalho para mover uma lista acordada de páginas para o Edge Delivery Services, o serviço do Adobe Experience Manager que fornece sites. Comece com uma página de exemplo para cada modelo, defina como seu conteúdo e design serão mapeados para o novo site e importe mais páginas somente depois que as amostras funcionarem no editor que seus autores usarão. Se termos como blocos, conteúdo padrão ou pré-visualização forem novos para você, consulte Como seu site é criado e atualizado e Formatar a estrutura do conteúdo.

Para algumas páginas de demonstração ou uma primeira avaliação, use os fluxos de trabalho de demonstração e avaliação menores. Eles não precisam das verificações de que um site de produção precisa antes do lançamento.

Chegar a um acordo sobre escopo e destinos scope

O líder e o arquiteto da migração concordam com o escopo e os destinos. Você precisa de autorização para ler a origem, modificar o repositório de destino e gravar conteúdo e ativos no destino. Concorde com quem assina o resultado e com quem autoriza a liberação. Se algumas páginas exigirem entrada, configure a autenticação de site protegida com uma conta somente leitura dedicada. Se a origem bloquear visitantes automatizados, organize o acesso com o administrador antes da catalogação. Consulte Sites da Source com proteção de bot.

Gravar:

Entrada
Decisões de retenção
Inventário do Source
Domínios, URLs de página, localidades, documentos, ativos e conteúdo excluído ou removido.
Código
Repositório, ramificação de trabalho, política de revisão e proprietário da versão.
Destino do conteúdo
Qual das duas opções de armazenamento o projeto usa.
Design
Preservar a aparência da origem ou aplicar um novo design. Nomeie a referência e a versão aprovadas.
Comportamento
Navegação, formulários, pesquisa, comércio, consentimento, análise, personalização e outras integrações que devem funcionar. Identifique os proprietários.
Política de URL
Caminhos de destino, redirecionamentos, URLs canônicos, relacionamentos de idioma e links a serem retidos.
Recuperação
Linha de base de código, processo de backup e recuperação de conteúdo e autoridade para substituir ou publicar.

A importação de página copia o conteúdo e o design de cada página. As integrações e os recursos do CMS são executados nos servidores de origem, como pesquisa, processamento de formulários, regras de personalização e herança de conteúdo, para que a importação copie somente sua saída em cada página. Liste-os em Comportamento e decida como cada um deles funciona no novo site. Consulte Limitações.

Um espaço de trabalho do console funciona em um site de cada vez. Em um programa com vários sites, aceite a ordem deles e envie e carregue o trabalho de cada site antes de abrir o próximo com Alternar site.

Reiniciar um site executado no Experience Manager relaunch-aem-site

Depois que sua equipe decidir iniciar novamente, o fluxo de trabalho será o mesmo de qualquer outra origem. Esses pontos são específicos de uma origem Experience Manager:

  • Seus outros sites: o agente lê as páginas do site de origem e não altera a origem. Ele grava somente no repositório Git do novo site e no destino de conteúdo escolhido, de modo que os outros sites da Experience Manager da sua organização continuem sendo executados como estão, assim como o site de origem, até que você alterne seu domínio para a versão. Com a criação do Experience Manager, o upload grava páginas em /content/{site-name} e imagens na pasta Assets do site e substitui qualquer página já nesse caminho, portanto, concorda com o administrador da instância do autor. Consulte Carregar Conteúdo.
  • Como o agente lê a origem: O agente lê cada página à medida que um navegador a renderiza, não os componentes, modelos ou repositório da origem. Componentes, fragmentos de experiência e herança de conteúdo, portanto, não são transferidos como tal: sua saída aparece em cada página. Decida qual conteúdo compartilhado manter uma vez no novo site. Consulte O que resta do Trabalho no Projeto.
  • Para onde o conteúdo vai: O destino é sua escolha, como qualquer origem; consulte Onde o Conteúdo É Armazenado e Como os Autores o Editam. A criação do Experience Manager precisa de uma instância de autor do Experience Manager as a Cloud Service, de modo que uma instância de autor executada em outro lugar não pode ser o destino.
  • Repositórios: se o código estiver em um repositório conectado pelo Cloud Manager, o console também funcionará com ele. Consulte Usar Outro Host Git.
  • Decisões para sua equipe: idiomas, herança entre mercados e fluxos de trabalho de aprovação são as decisões de sua equipe. A importação fornece as páginas em seus caminhos de origem, não essas estruturas. Registre-as com as outras decisões de escopo antes de catalogar.

Preparar e catálogo prepare

  1. Siga a configuração do console compartilhado ou a configuração de criação do Experience Manager se o conteúdo for para a criação do Experience Manager. Reutilize a configuração de um projeto existente, em vez de recriá-lo.
  2. Peça ao agente para catalogar o site autorizado: Scope site https://www.example.com. O catálogo de sites descobre páginas e as agrupa em modelos (páginas que compartilham um layout) e bloqueia variantes.
  3. Revise o catálogo na exibição do Planning. Corrija os agrupamentos de modelo e bloco e investigue os URLs com falha.
  4. Compare os URLs descobertos com a lista de páginas acordadas. Adicione páginas que a descoberta perdeu e decida explicitamente sobre URLs com falha, ignoradas, duplicadas ou excluídas.
  5. Escolha uma página de exemplo para cada modelo e variante importante. Cubra conteúdo longo, imagens incomuns, locais e páginas com muita interação.

O catálogo lê a origem e não importa nada. Uma execução com o status concluída ainda pode ter páginas com falha; consulte Resultados e Status. Antes de continuar, forneça um modelo ou uma exclusão aprovada a cada URL no escopo.

Como o agente migra em escala migration-at-scale

O agente não envia cada página por meio do modelo de IA. Interpretar cada página separadamente não aumentaria para milhares de páginas, e o modelo poderia tratar páginas semelhantes de forma um pouco diferente a cada vez. Em vez disso, o modelo de IA funciona o mapeamento em uma página de amostra por modelo, e o agente transforma esse mapeamento em um código que é executado nas outras páginas do modelo:

  1. Agrupar páginas em modelos. O catálogo de sites agrupa as páginas do site de origem em modelos, que são páginas que compartilham um layout. Se você migrar páginas sem um catálogo, cada página nomeada iniciará um modelo próprio.
  2. Migrar uma página de exemplo. Para cada modelo, o agente migra primeiro uma página real que mostra o layout típico do modelo e, idealmente, a maioria de seus blocos e variantes. O catálogo do site propõe um para cada modelo. Se outra página do modelo mostrar mais de seus blocos, escolha essa página: os blocos que falta na página de exemplo só serão adicionados posteriormente, quando uma página importada precisar deles. O modelo de IA mapeia o conteúdo da página de exemplo para o conteúdo e os blocos padrão, e cria os blocos necessários ou reutiliza os existentes.
  3. Gerar um script de importação. O agente grava um script de importação para o modelo: uma parte, o analisador, extrai o conteúdo de cada bloco do HTML de origem, e outra, o transformador, limpa a página como um todo. Os scripts são arquivos JavaScript na pasta tools/importer/ do projeto, com controle de versão no Git com o restante do código.
  4. Refine o padrão, não a página. Quando você solicita uma correção, o agente altera o bloco ou o script de importação que produziu o resultado em vez de editar a saída de uma página. A correção se aplica a cada página do modelo e modelos posteriores reutilizam os blocos que já existem.
  5. Importar as páginas restantes em massa. A importação em massa executa o script de importação nas outras páginas do modelo sem que o modelo de IA interprete cada uma. Em seguida, o agente compara as páginas importadas com suas páginas de origem, corrige o script de importação para páginas muito diferentes e importa essas páginas novamente.

Valide algumas páginas de cada modelo antes de importar todas. Consulte Importar em lotes.

O mesmo se aplica a alterações na estrutura do conteúdo, como qual conteúdo se torna um bloco ou onde uma página se divide em seções: altere o script de importação. É o código, revisado e mesclado como o restante, e a próxima importação o aplica a cada página do modelo. Uma edição em uma página importada permanece local, e a importação do modelo novamente o substitui.

Para alterar os modelos e os próprios blocos, como mover páginas para outro modelo ou fazer de um bloco uma variante de outro, use o modo de exibição de Planejamento ou pergunte no chat. O agente segue essas alterações na próxima vez que gerar blocos ou importar páginas, e as páginas já importadas não são alteradas. Para consolidar o design, consulte Redefinir estilo de Sites. Para consolidar o código de bloco, consulte Refatorar sem alterar o resultado.

NOTE
Um modelo no console é um grupo de páginas de origem com o mesmo layout, que o agente usa para planejar e importar. Não são os metadados da página template, que adicionam uma classe ao elemento body da página para que o código do projeto possa estilizar essas páginas de forma diferente. Para alinhar os dois, peça ao agente para definir os metadados no script de importação, para que cada página do modelo os receba na importação, por exemplo: "Para o modelo de artigo, defina os metadados de página template como article no script de importação e forneça às páginas de artigo uma coluna principal mais estreita."

Validar páginas de exemplo representatives

O líder da migração, os designers e os autores definem o primeiro modelo juntos. Comece com algumas de suas páginas. Por exemplo:

Migrar apenas estas páginas de produto: https://www.example.com/products/tents, https://www.example.com/products/backpacks e https://www.example.com/products/boots. Armazene o conteúdo como conteúdo baseado em documento em /products. Mantenha o texto aprovado, os links, os metadados e o significado da imagem. Reutilizar os blocos do projeto e as convenções de conteúdo. Relatar conteúdo ausente e interações que a importação não reproduz. Não carregue, envie nem publique.

Substitua os URLs e caminhos de exemplo pelos seus próprios e, para a criação no Experience Manager, diga que o conteúdo está armazenado no JCR.

  1. Revise a estrutura do conteúdo: as seções, o conteúdo padrão, os blocos, as variantes e os estilos de seção que o agente escolheu. Os autores editarão cada página migrada nesta estrutura, portanto, a fixará nas páginas de exemplo. Consulte Formatar a Estrutura de Conteúdo.

  2. Compare o texto importado, links, imagens, metadados e a ordem da seção com a origem. Quando um padrão estiver errado, corrija o script de importação, não a página. Consulte Como o agente migra em escala.

  3. Aplique o estilo de origem ou siga o fluxo de trabalho de redesign. Verifique os estilos globais antes de refinar blocos individuais.

  4. Preencha o cabeçalho, a navegação e o rodapé compartilhados separadamente da importação da página. O agente as migra, incluindo imagens de rodapé, uma vez para todo o site, para que cada página compartilhe um cabeçalho e um rodapé.

  5. Faça upload de uma página de exemplo para o destino do conteúdo e, em seguida, edite, salve, reabra e visualize-a:

  6. Registre o mapeamento acordado da origem para a saída, os modelos de bloco, as decisões de design e as exceções conhecidas antes de importar mais páginas.

Uma página que parece à direita ainda falha se os autores não puderem editá-la. Para criação no Experience Manager, verifique também os modelos de bloco, a configuração de componentes gerados, os erros de conversão e onde as imagens são armazenadas antes de importar mais.

Modelar a estrutura do conteúdo content-structure

Os autores editam cada página migrada na estrutura escolhida pelo agente na importação, e a importação em massa repete essa estrutura em cada página de um modelo. As páginas do Edge Delivery Services são feitas de seções que contêm conteúdo e blocos padrão; consulte Marcação, Seções, Blocos e Bloqueio Automático. O agente segue o Modelo de David e mantém a estrutura tão simples quanto o design permite, porque cada bloco e variante é mais uma coisa para os autores aprenderem.

Estrutura
O que o agente faz na importação
Como orientá-lo
Seção
Divide a página onde seu plano de fundo ou layout muda. O espaço vazio entre as partes de uma página é o espaçamento, não uma seção.
Peça para mesclar seções que os autores veem como uma parte da página, ou para dividir uma que faz dois trabalhos.
Conteúdo padrão
Mantém tudo o que um autor poderia digitar em um documento como conteúdo padrão: cabeçalhos, parágrafos, listas, links e imagens integradas. O CSS o apresenta de acordo com as necessidades de design.
Sempre que criar um bloco para conteúdo desse tipo, peça para ele usar o conteúdo padrão e estilizá-lo com CSS.
Bloquear
Usa um bloco para itens repetidos, componentes interativos e layouts lado a lado fixos. Itens semelhantes que fluem e envolvem se tornam cartões; as colunas mantêm um conjunto fixo de conteúdo diferente lado a lado. Um fundo de foto pertence ao seu bloco, como um herói. Ele reutiliza um bloco do projeto antes de criar um.
Nomeie o bloco que um padrão deve usar ou peça que ele reutilize um existente. Consulte Compor Antes de Criar um Bloco.
Bloquear variante
Cria uma variante, como cards-compact, para uma pequena diferença de aparência escolhida pelos autores. O conteúdo com campos diferentes ou com um trabalho diferente recebe um bloco próprio. O conteúdo opcional e um número diferente de itens não fazem uma variante.
Solicite que ela mescle variantes que diferem apenas levemente ou transforme uma variante cujos campos diferem em um bloco próprio.
Estilo da seção
Dá a uma seção um estilo em seus metadados de seção quando seu plano de fundo é diferente do da página, seu alinhamento não é o padrão ou seu conteúdo padrão fica ao lado de um bloco. Ele nomeia o estilo após a aparência, como dark, light-grey ou centered. O texto e os botões na seção tiram a cor do estilo, de modo que uma cor sozinha nunca cria um bloco ou uma variante.
Concordo com a lista de estilos de seção e seus nomes, para que os autores escolham entre os mesmos poucos em cada página.

Para orientar a estrutura:

  1. Antes de migrar, revise o catálogo na exibição Planning e corrija os nomes e agrupamentos de blocos. Consulte Refinando o Catálogo.
  2. Registre os blocos, as variantes e os estilos de seção do projeto em AGENTS.md, para que o agente os reutilize em páginas posteriores e em sessões posteriores. Consulte Convenções de Conteúdo de Documentos.
  3. Verifique cada página de exemplo na Exibição de documento do painel de visualização, que mostra suas seções, blocos e conteúdo padrão. Consulte Content Views.
  4. Corrija um padrão incorreto no script de importação para que a importação em massa repita a correção em cada página. Consulte Como o agente migra em escala.
  5. Peça a um autor para editar uma página de exemplo. Se eles hesitarem sobre qual bloco, variante ou estilo usar, há muitas opções.

Mantenha as escolhas que os autores fazem poucas. O sistema de design deve tomar as decisões que os autores não devem ter: quando um bloco precisa de mais do que um punhado de variantes ou opções, pergunte se algumas delas pertencem ao design.

Estimativa antes de confirmar estimate

O catálogo e as primeiras páginas de exemplo fornecem uma estimativa com base no trabalho de que o site precisa, não na contagem de páginas:

  1. Catalogar o site. O catálogo lista os modelos, as variantes de bloqueio, as localidades e os URLs que falharam. Consulte Preparar e catalogar.
  2. Validar páginas de exemplo dos modelos principais. Registre o que cada um precisava: novos blocos, correções para importar scripts, estilo e alterações na estrutura do conteúdo.
  3. Dimensione os modelos restantes a partir do que as páginas de exemplo precisavam. Modelos posteriores reutilizam os blocos que já existem, então, contabilizam os blocos que cada um adiciona. Uma página com um layout próprio conta como um modelo próprio.
  4. Adicione os itens que a importação não cobre: o comportamento que você registrou em Comportamento no escopo e o trabalho do projeto que sua equipe decide e cria.

Verifique a estimativa em relação ao registro por URL do primeiro lote.

Trabalhar como uma equipe collaboration

Várias pessoas podem trabalhar no mesmo projeto com o agente, cada uma em seu próprio espaço de trabalho do console. Eles compartilham código por meio do Git e conteúdo por meio do destino do conteúdo. O console não mostra quem está trabalhando em quê, e não mescla as alterações de duas pessoas na mesma página, então, concorde quem trabalha em quê e continue falando umas com as outras.

O escopo é mais importante com um agente do que sem um. Uma única solicitação pode alterar muitos arquivos, de modo que, quando duas pessoas alteram os mesmos blocos ou estilos ao mesmo tempo, alguém precisa resolver conflitos entre muitos arquivos manualmente.

Conduzir a migração phases

Uma migração é executada em fases. O agente faz a maior parte do trabalho repetitivo em cada um, e sua equipe toma as decisões e assina o resultado. Permitir que uma pessoa, como o lead de migração, execute as primeiras fases; outras se associem assim que os blocos e os scripts de importação forem liquidados. Consulte Trabalhar como uma equipe.

Os colaboradores visuais podem trabalhar no estilo a partir da fase de páginas de amostra. Consulte Fazer Alterações Visuais.

Comece com uma pessoa e divida o trabalho divide-work

As primeiras etapas estabelecem a base em que todo o resto se baseia: os estilos globais, os primeiros blocos e os scripts de importação dos primeiros templates. Deixe uma pessoa configurá-los. Antes de dividir o trabalho, verifique se os blocos se encaixam no conteúdo real e são fáceis de usar pelos autores. Consulte Formatar a Estrutura de Conteúdo.

Depois que a equipe concordar com os blocos, divida o trabalho para que as pessoas alterem arquivos diferentes:

  • Por bloco: uma pessoa refina o bloco de cartões enquanto outra cria um carrossel.
  • Por modelo: cada pessoa refina o script de importação de um modelo diferente. Consulte Como o agente migra em escala.
  • Por experiência: um designer refina o estilo dos blocos existentes enquanto um desenvolvedor cria uma integração.

Não forneça a duas pessoas o mesmo bloco, os estilos globais ou o mesmo script de importação ao mesmo tempo, a menos que elas concordem sobre como coordenar.

Compartilhar código em pequenas etapas share-code

  1. Concorde em uma ramificação compartilhada, como main ou ramificação de desenvolvimento. Cada pessoa alterna seu espaço de trabalho para ele com Ramificação do comutador na Visualização de código.
  2. Mantenha cada solicitação para o agente focada em um bloco, modelo ou tarefa. Envie o resultado por push assim que funcionar, com Criar nova PR: o console envia as alterações para uma nova ramificação, abre uma solicitação de envio para a ramificação compartilhada e deixa o espaço de trabalho na nova ramificação.
  3. Revisar e mesclar solicitações de pull com frequência. Pequenas alterações entram em conflito menos e são mais rápidas de serem revisadas, e uma solicitação de pull que permanece aberta por dias coleta conflitos.
  4. Antes de iniciar uma nova tarefa, alterne de volta para a ramificação compartilhada com Ramificação do comutador e puxe-a com Sincronização > Recepção > Código, para criar no trabalho mesclado de todos.

Se um pull não estiver disponível ou relatar um conflito, consulte Se Alguém Alterou a Ramificação.

Pequenos e frequentes impulsos também dão à equipe um histórico legível do que o agente mudou e o porquê. Para obter uma confirmação por solicitação, consulte Deixar um Registro de Cada Solicitação.

Coordenar alterações de conteúdo share-content

O conteúdo não tem mesclagem. Seu espaço de trabalho armazena cópias das páginas e um upload substitui a página no destino de conteúdo pela sua cópia. Se duas pessoas mudarem a mesma página, o último upload ganhará e as alterações da outra pessoa serão perdidas. Forneça cada página, ou conjunto de páginas, a uma pessoa de cada vez.

Para obter páginas que outras pessoas carregaram no seu espaço de trabalho:

  • Abra uma página que mostre um ícone de nuvem na exibição de conteúdo. O console o baixa para o espaço de trabalho.
  • Em projetos baseados em documentos, selecione Sincronizar > Extrair > Conteúdo para baixar todas as páginas do Experience Workspace. Ele substitui suas cópias locais, incluindo edições que você não carregou, portanto, carregue as edições que deseja manter primeiro.

Importar em lotes batches

Use o fluxo de trabalho de importação em massa do catálogo e os prompts de importação em massa depois de validar as páginas de exemplo.

  1. Importe um pequeno lote com o script de importação do modelo.
  2. Verifique páginas comuns e casos de borda. Se o script de importação estiver errado, corrija-o e importe as páginas afetadas novamente antes de continuar.
  3. Mantenha um registro para cada URL de origem: destino, estado de importação, erros, aprovação e qualquer exclusão aprovada.
  4. Continue modelo por modelo. Contagem de páginas descobertas, analisadas, importadas, com falha, ignoradas e aprovadas separadamente.
  5. Verifique novamente as páginas de exemplo anteriores ao alterar estilos compartilhados, scripts de importação, modelos de bloco ou código de bloco.

Depois que os autores começam a editar as páginas migradas no destino do conteúdo, suas páginas se tornam a fonte da verdade. Importar ou carregar essas páginas novamente substitui o trabalho dos autores e um script de importação corrigido não o mescla, portanto, concorde primeiro com os autores.

Concluir o site complete-site

A importação automatizada é uma parte da entrega. Implementar e verificar os requisitos acordados, incluindo:

  • Cabeçalho, rodapé, navegação, links internos e páginas de erro.
  • Imagens, downloads, fontes, permissões de ativos e qualquer referência mantida do Dynamic Media.
  • Títulos, descrições, URLs canônicos, dados estruturados, redirecionamentos, mapas de site e relacionamentos de localidade onde necessário.
  • Forms, pesquisa, comércio, recursos da conta, análise, consentimento e outras integrações.
  • Orientação do autor, propriedade operacional, acesso e configuração de implantação.

O agente implementa o lado do código desses blocos, por exemplo, que chamam a API de pesquisa ou comércio, formulários e o código que carrega a análise e o consentimento. Ele não pode configurar sistemas fora do seu repositório e conteúdo, como o serviço de pesquisa, a CDN ou a conta do Analytics, e não decide seus requisitos. Forneça a documentação da API e o comportamento acordado, e nomeie um proprietário para cada sistema externo que assinar o resultado. Consulte Serviços e Aplicativos do Connect, para formulários, Envios de formulário e para páginas de produtos, Páginas do Commerce.

Imagens e documentos assets

A forma como as imagens chegam ao novo site depende do destino do conteúdo:

  • Experience Workspace: enquanto você trabalha no console, uma página importada ainda pode fazer referência a imagens no site de origem. Ao fazer upload da página, o console faz o upload de suas imagens com ela, incluindo as imagens baixadas da origem, em uma pasta chamada em homenagem à página com um ponto à esquerda. Em seguida, aponta a página para as cópias carregadas. Se uma imagem estiver ausente, em um formato não compatível ou ambíguo, o console a relata e não carrega a página. Após o upload, ele verifica se todas as imagens chegaram. Consulte Carregar Conteúdo.
  • Criação no Experience Manager Selecione Carregar imagens ao carregar o pacote de conteúdo e escolha uma pasta em /content/dam/. O padrão é /content/dam/site. Consulte Carregar Conteúdo.
  • Adobe Dynamic Media: as imagens que a origem fornece do Dynamic Media, incluindo Scene7 e Dynamic Media com URLs OpenAPI, ficam lá. A página importada faz referência a elas e o código do projeto as renderiza.

O Edge Delivery Services fornece imagens em tamanhos e formatos que se ajustam a cada tela. Compare arquivos grandes, vídeos e imagens do SVG com os limites de tipos e tamanhos de arquivo.

Verifique os links para documentos, como PDFs, nas páginas de exemplo. Cada link deve apontar para uma cópia no novo site, não para o site de origem que você desativará.

URLs, redirecionamentos e metadados de pesquisa urls-seo

O agente pega o caminho de cada página do URL de origem. Ela coloca em minúsculas o caminho, remove .html, transforma um / à direita em index e substitui outros caracteres, como espaços e sublinhados, por hifens. /About_Us.html torna-se /about-us. Todo URL que muda dessa forma ou que você altera de propósito precisa de um redirecionamento.

O agente não cria redirecionamentos, mapas de site ou alternativos de idioma sozinho. Solicite-o como uma tarefa e analise o resultado:

  • Redirecionamentos: uma planilha redirects com colunas Source e Destination, uma linha por URL, sem curingas. Peça ao agente para listar os URLs de origem cujo caminho foi alterado, como linhas para a planilha. Consulte Redirecionamentos.
  • Metadados da página: a importação mantém o título, a descrição e a imagem social de cada página em seu bloco de metadados. Para definir metadados para várias páginas ao mesmo tempo, use uma planilha do metadata. Consulte Metadados em massa.
  • Mapa do site e idiomas: Um arquivo helix-sitemap.yaml no repositório, que pode incluir as alternativas de idioma (hreflang) de cada página. Consulte Mapas de site.
  • Mecanismos de pesquisa: os sites de visualização e ao vivo, *.aem.page e *.aem.live, estão ocultos dos mecanismos de pesquisa; seu domínio de produção não está. Verifique robots.txt antes da transferência. Consulte robots.txt.
  • Índice de consulta: Listas de páginas, como listas de artigos e pesquisa de site, lidas de um índice de consulta que inclui somente páginas publicadas. Consulte Indexação.

Verificar e aprovar acceptance

Concorde com o proprietário do site sobre o que deve funcionar antes do lançamento e teste-o na pré-visualização e nos sites em tempo real. O proprietário do site assina o resultado com testadores e autores.

Área
Desconectado quando
Abrangência
Cada URL dentro do escopo tem um destino ou uma exceção aprovada. As páginas com falha e ignoradas são resolvidas ou gravadas.
Conteúdo
O texto, os links, os ativos, os metadados e o conteúdo local estão completos e corretos.
Criação
Os autores podem editar campos e blocos típicos, salvar, reabrir e visualizar o resultado em seus respectivos editores.
Design
Layouts aprovados para desktop e dispositivos móveis funcionam em conteúdo real, incluindo texto longo e variantes de blocos.
Função
A navegação, a interação com o teclado, os formulários, as integrações e as jornadas de usuário acordadas funcionam.
Qualidade
As verificações de acessibilidade, desempenho e SEO e segurança relevantes atendem aos requisitos acordados do projeto. As ferramentas de acessibilidade automatizadas encontram apenas os problemas que uma regra pode detectar, por isso, também testam páginas de exemplo com um teclado e um leitor de tela. Teste de desempenho com PageSpeed Insights; no GitHub, o Edge Delivery Services executa a mesma verificação em cada solicitação de pull para as URLs de teste em sua descrição.
Operações
A revisão do repositório, a publicação do conteúdo, a recuperação, o monitoramento e a propriedade do suporte são documentados e testados conforme necessário.

Cada sinal automatizado verifica uma coisa: um status de importador que o script executou, um pacote gerado cujo conteúdo foi convertido, uma pontuação de similaridade visual em que uma página se parece com a origem e uma pontuação do Lighthouse como uma página é carregada em um teste de laboratório. A prontidão da produção precisa de todas as áreas da tabela.

Liberação, recuperação e entrega handoff

O proprietário da versão coordena a mesclagem de códigos, a publicação de conteúdo e a transferência de domínio e, em seguida, confirma que os proprietários contínuos do site a assumiram.

  1. Envie o código desconectado e solicite a revisão de acordo com a política do repositório. Mesclar para main atualiza o código do site ativo imediatamente, portanto, planeje a mesclagem com a versão de conteúdo. Consulte Como As Alterações Entram Em Vigor.
  2. Carregue somente o conteúdo e as imagens desconectados no destino confirmado. Revise os erros de cada página e imagem.
  3. Verifique o conteúdo salvo com a revisão de código pretendida no site de visualização, *.aem.page.
  4. Obtenha a aprovação de lançamento do site e siga a publicação configurada e o processo de transferência de domínio. A publicação disponibiliza as páginas em *.aem.live; a transferência é o que as atende em seu próprio domínio, por meio da CDN gerenciada pela Adobe ou de sua própria CDN. Trabalhe a lista de verificação de ativação antes da transferência.
  5. Verifique os URLs ativos, redirecionamentos, jornadas principais e monitoramento após o lançamento. Telemetria Operacional mostra como visitantes reais experimentam o desempenho do site.
  6. Forneça a entrega do projeto, o registro por URL, exemplos de autor, resultados de aprovação, exceções e contatos de recuperação.

Quando algo falhar, mantenha o URL ou caminho exato, a operação e o log de erros. Tente novamente o menor escopo afetado depois de corrigir a causa. Não reinicie um lote bem-sucedido porque uma página falhou.

As operações de envio de código, upload de documentos, importação de um pacote de conteúdo para o Experience Manager e publicação são operações separadas em sistemas separados. Uma falha parcial pode deixar apenas algumas alterações aplicadas e nenhuma reversão desfaz todas elas. Recupere código por meio do Git e conteúdo e imagens por meio do histórico de versões do destino de conteúdo ou do processo acordado.

recommendation-more-help
experience-manager-cloud-service-help-main-toc