Migrare un sito di produzione production-migration

Utilizza questo flusso di lavoro per spostare un elenco concordato di pagine in Edge Delivery Services, il servizio Adobe Experience Manager che distribuisce i siti web. Inizia con una pagina di esempio per ciascun modello, imposta il modo in cui il contenuto e la struttura corrispondono al nuovo sito e importa più pagine solo dopo che gli esempi funzioneranno nell’editor utilizzato dagli autori. Se termini quali blocchi, contenuto predefinito o anteprima sono nuovi per l’utente, vedere Modalità di creazione e aggiornamento del sito e Struttura del contenuto.

Per alcune pagine dimostrative o per una prima valutazione, utilizza i flussi di lavoro demo e di prova più piccoli. Non hanno bisogno dei controlli necessari per un sito di produzione prima del rilascio.

Ambito e destinazioni concordati scope

Il lead e l’architetto della migrazione concordano l’ambito e le destinazioni. È necessaria l’autorizzazione per leggere l’origine, modificare l’archivio di destinazione e scrivere contenuti e risorse nella destinazione. Accetto chi firma il risultato e chi autorizza il rilascio. Se alcune pagine richiedono l’accesso, configurare autenticazione del sito protetto con un account di sola lettura dedicato. Se il sorgente blocca i visitatori automatizzati, organizza l’accesso con il relativo amministratore prima della catalogazione. Vedi Siti Source con protezione bot.

Record:

Input
Decisioni di mantenere
Inventario Source
Domini, URL di pagina, impostazioni internazionali, documenti, risorse e contenuti esclusi o ritirati.
Codice
Archivio, ramo di lavoro, revisione dei criteri e proprietario della versione.
Destinazione contenuto
Quale delle due opzioni di archiviazione viene utilizzata dal progetto.
Design
Mantenere l’aspetto di origine o applicare un nuovo design. Denomina il riferimento e la versione approvati.
Comportamento
Navigazione, moduli, ricerca, e-commerce, consenso, analisi, personalizzazione e altre integrazioni che devono funzionare. Identifica i proprietari.
Criterio URL
Percorsi di destinazione, reindirizzamenti, URL canonici, relazioni di lingua e collegamenti da mantenere.
Recupero
Linea di base del codice, processo di backup e ripristino dei contenuti e autorità di sovrascrittura o pubblicazione.

L’importazione di pagine copia il contenuto e la progettazione di ogni pagina. Le integrazioni e le funzioni di CMS vengono eseguite sui server di origine, ad esempio le funzionalità di ricerca, elaborazione dei moduli, regole di personalizzazione ed ereditarietà dei contenuti, pertanto l’importazione copia solo il relativo output in ogni pagina. Elencali in Comportamento e decidi come ciascuno funziona sul nuovo sito. Vedi Limitazioni.

Un’area di lavoro della console funziona su un sito alla volta. In un programma con più siti, concordare l’ordine e inviare e caricare il lavoro di ogni sito prima di aprire quello successivo con Cambia sito.

Riavviare un sito in esecuzione su Experience Manager relaunch-aem-site

Una volta che il team ha deciso sul rilancio, il flusso di lavoro è lo stesso di qualsiasi altra origine. Questi punti sono specifici per un’origine Experience Manager:

  • Altri siti: L’agente legge le pagine del sito di origine e non modifica l’origine. Scrive solo nell’archivio Git del nuovo sito e nella destinazione di contenuto scelta, in modo che gli altri siti Experience Manager dell’organizzazione continuino a funzionare così come sono, così come il sito di origine fino a quando non si cambia il dominio in release. Con l’authoring di Experience Manager, il caricamento scrive pagine in /content/{site-name} e immagini nella cartella Assets del sito e sostituisce tutte le pagine già presenti in tale percorso, quindi concorda con l’amministratore dell’istanza di authoring. Vedi Carica contenuto.
  • Modalità di lettura dell’origine da parte dell’agente: L’agente legge ogni pagina come browser la riproduce, non i componenti, i modelli o l’archivio dell’origine. I componenti, i frammenti di esperienza e l’ereditarietà dei contenuti non vengono quindi trasferiti come tali: l’output viene visualizzato in ogni pagina. Decidi quale contenuto condiviso conservare una volta nel nuovo sito. Vedi Il progetto rimane attivo.
  • Destinazione del contenuto: Scegliere la destinazione, come per qualsiasi origine; vedere Archiviazione del contenuto e modalità di modifica da parte degli autori. Per l’authoring di Experience Manager è necessaria un’istanza di authoring di Experience Manager as a Cloud Service, pertanto un’istanza di authoring eseguita altrove non può essere la destinazione.
  • Archivi: Se il codice si trova in un archivio connesso tramite Cloud Manager, anche la console funziona. Vedi Utilizzare Un Altro Host Git.
  • Le decisioni per il tuo team: Le decisioni del tuo team sono basate sulle lingue, sull’ereditarietà tra i mercati e sui flussi di lavoro di approvazione. L’importazione ti offre le pagine nei loro percorsi sorgente, non queste strutture. Registrali con le altre decisioni di ambito prima di catalogare.

Prepara e catalogo prepare

  1. Segui la configurazione della console condivisa o la configurazione di authoring di Experience Manager se il contenuto viene inviato all’authoring di Experience Manager. Riutilizzare la configurazione di un progetto esistente anziché ricrearla.
  2. Chiedere all’agente di catalogare il sito autorizzato: Scope site https://www.example.com. Il catalogo siti rileva le pagine e le raggruppa in modelli (pagine che condividono un layout) e blocca le varianti.
  3. Esaminare il catalogo nella visualizzazione Pianificazione. Correggi i raggruppamenti di modelli e blocchi ed esamina gli URL con errori.
  4. Confronta gli URL individuati con l’elenco di pagine approvato. Aggiungi le pagine che non sono state individuate e decidi esplicitamente in merito agli URL non riusciti, ignorati, duplicati o esclusi.
  5. Scegli una pagina di esempio per ciascun modello e variante importante. Coprire contenuti lunghi, immagini insolite, lingue e pagine con un’interazione intensa.

La catalogazione legge la sorgente e non importa nulla. Un’esecuzione con lo stato completato può avere ancora pagine non riuscite. Vedere Risultati e stato. Prima di procedere, assegna a ogni URL nell’ambito un modello o un’esclusione approvata.

Migrazione dell’agente su larga scala migration-at-scale

L’agente non invia ogni pagina tramite il modello di intelligenza artificiale. Interpretare separatamente ogni pagina non avrebbe la scalabilità a migliaia di pagine e il modello potrebbe trattare pagine simili in modo leggermente diverso ogni volta. Il modello di intelligenza artificiale elabora invece il mapping su una pagina di esempio per modello e l’agente trasforma il mapping in codice che viene eseguito sulle altre pagine del modello:

  1. Raggruppa le pagine in modelli. Il catalogo siti raggruppa le pagine del sito di origine in modelli, ovvero pagine che condividono un layout. Se esegui la migrazione di pagine senza un catalogo, ogni pagina a cui denomini avvia un modello personalizzato.
  2. Eseguire la migrazione di una pagina di esempio. Per ogni modello, l’agente esegue innanzitutto la migrazione di una pagina reale che mostra il layout tipico del modello e, idealmente, la maggior parte dei blocchi e delle varianti. Il catalogo del sito ne propone uno per ogni modello. Se in un’altra pagina del modello vengono visualizzati più blocchi, scegli quella pagina: i blocchi mancanti nella pagina di esempio vengono aggiunti solo in un secondo momento, quando sono necessari per una pagina importata. Il modello AI mappa il contenuto della pagina di esempio sul contenuto e sui blocchi predefiniti e crea i blocchi necessari o riutilizza quelli esistenti.
  3. Generare uno script di importazione. L’agente scrive uno script di importazione per il modello: una parte, il parser, estrae il contenuto di ciascun blocco dal HTML di origine e un’altra, il trasformatore, pulisce la pagina nel suo insieme. Gli script sono file JavaScript nella cartella tools/importer/ del progetto, con versione in Git e il resto del codice.
  4. Perfeziona il modello, non la pagina. Quando richiedi una correzione, l’agente modifica il blocco o lo script di importazione che ha prodotto il risultato invece di modificare l’output di una pagina. La correzione viene quindi applicata a ogni pagina del modello e i modelli successivi riutilizzano i blocchi già esistenti.
  5. Importa le pagine rimanenti in blocco. L’importazione in blocco esegue lo script di importazione sulle altre pagine del modello senza che il modello AI interpreti ciascuna di esse. L’agente confronta quindi le pagine importate con le relative pagine di origine, corregge lo script di importazione per le pagine che presentano troppe differenze e importa nuovamente tali pagine.

Convalida alcune pagine di ciascun modello prima di importarli tutti. Vedi Importa in batch.

Lo stesso vale per le modifiche nella struttura del contenuto, ad esempio il contenuto che diventa un blocco o la posizione in cui una pagina si divide in sezioni: modifica lo script di importazione. È un codice, rivisto e unito come il resto, e la prossima importazione lo applica a ogni pagina del modello. Una modifica apportata a una pagina importata rimane locale e l’importazione del modello sovrascrive nuovamente tale pagina.

Per modificare i modelli e i blocchi stessi, ad esempio spostando le pagine in un altro modello o rendendo un blocco una variante di un altro, utilizzare la visualizzazione Planning o chiedere in chat. L’agente segue queste modifiche alla successiva generazione di blocchi o importazione di pagine e le pagine già importate non vengono modificate. Per consolidare la progettazione, vedere Restyle Sites. Per consolidare il codice di blocco, vedere Refactoring senza modificare il risultato.

NOTE
Un modello nella console è un gruppo di pagine sorgente con lo stesso layout, che l’agente utilizza per pianificarle e importarle. Non si tratta dei metadati della pagina template, che aggiunge una classe all'elemento body della pagina in modo che il codice del progetto possa assegnare loro uno stile diverso. Per allineare le due, chiedere all'agente di impostare i metadati nello script di importazione, in modo che ogni pagina del modello lo ottenga durante l'importazione, ad esempio: "Per il modello di articolo, impostare i metadati di pagina template su article nello script di importazione e assegnare alle pagine di articolo una colonna principale più stretta."

Convalida pagine di esempio representatives

Il lead di migrazione, i designer e gli autori stabiliscono insieme il primo modello. Inizia con alcune delle sue pagine. Ad esempio:

Eseguire la migrazione solo delle pagine seguenti: https://www.example.com/products/tents, https://www.example.com/products/backpacks e https://www.example.com/products/boots. Archivia il contenuto come contenuto basato su documenti in /products. Mantieni il testo approvato, i collegamenti, i metadati e il significato dell’immagine. Riutilizza i blocchi e le convenzioni di contenuto del progetto. Segnala contenuti e interazioni mancanti che l’importazione non riproduce. Non caricare, inviare o pubblicare.

Sostituisci gli URL e i percorsi di esempio con il tuo e, per l’authoring Experience Manager, supponi che il contenuto sia memorizzato in JCR.

  1. Rivedi la struttura del contenuto: le sezioni, il contenuto predefinito, i blocchi, le varianti e gli stili di sezione scelti dall’agente. Gli autori modificheranno ogni pagina migrata in questa struttura, in modo da poterla impostare sulle pagine di esempio. Vedi Forma la struttura del contenuto.

  2. Confronta con l’origine testo importato, collegamenti, immagini, metadati e ordine delle sezioni. Quando un pattern non è corretto, correggi lo script di importazione e non la pagina. Vedi Migrazione dell’agente su scala.

  3. Applica lo stile di origine o segui il flusso di lavoro di riprogettazione. Controlla gli stili globali prima di perfezionare i singoli blocchi.

  4. Completa l’intestazione, la navigazione e il piè di pagina condivisi separatamente dall’importazione delle pagine. L’agente esegue la migrazione di tali pagine, incluse le immagini del piè di pagina, una volta per l’intero sito, in modo che ogni pagina condivida un’intestazione e un piè di pagina.

  5. Carica una pagina di esempio nella destinazione del contenuto, quindi modificala, salvala, riaprila e visualizzala in anteprima:

  6. Registra la mappatura concordata dall’origine all’output, i modelli di blocchi, le decisioni di progettazione e le eccezioni note prima di importare altre pagine.

Se gli autori non possono modificare una pagina con un aspetto corretto, la pagina non riesce. Per l’authoring Experience Manager, controlla anche i modelli di blocchi, la configurazione dei componenti generati, gli errori di conversione e dove vengono memorizzate le immagini prima di importarne di più.

Dare forma alla struttura del contenuto content-structure

Gli autori modificano ogni pagina migrata nella struttura scelta dall’agente al momento dell’importazione e l’importazione in blocco ripete tale struttura in ogni pagina di un modello. Le pagine Edge Delivery Services sono costituite da sezioni che contengono contenuto e blocchi predefiniti. Vedere Commenti, sezioni, blocchi e blocco automatico. L’agente segue il modello di David e mantiene la struttura semplice come lo consente la progettazione, perché ogni blocco e variante è un’altra cosa che gli autori possono imparare.

Struttura
Operazioni dell’agente durante l’importazione
Come guidarlo
Sezione
Divide la pagina in cui cambia lo sfondo o il layout. Lo spazio vuoto tra le parti di una pagina è la spaziatura, non una sezione.
Chiedere agli autori di unire le sezioni visualizzate come una parte della pagina o di dividerne una che esegua due processi.
Contenuto predefinito
Mantiene tutto ciò che un autore può digitare in un documento come contenuto predefinito: intestazioni, paragrafi, elenchi, collegamenti e immagini in linea. CSS la distingue in base alle esigenze di progettazione.
Se hai creato un blocco per contenuti di questo tipo, chiedi di utilizzare il contenuto predefinito e assegnargli uno stile CSS.
Blocca
Utilizza un blocco per elementi ripetuti, componenti interattivi e layout fissi affiancati. Elementi simili che scorrono e avvolgono diventano schede; le colonne contengono un set fisso di contenuti diversi affiancati. Lo sfondo di una foto appartiene al suo blocco, ad esempio un eroe. Riutilizza un blocco del progetto prima di crearne uno.
Denomina il blocco che un pattern deve utilizzare o chiedi di riutilizzarne uno esistente. Vedi Componi prima di creare un blocco.
Blocca variante
Crea una variante, ad esempio cards-compact, per una piccola differenza nell’aspetto scelto dagli autori. I contenuti con campi diversi o un processo diverso ottengono un blocco proprio. Il contenuto facoltativo e un numero diverso di elementi non costituiscono una variante.
Chiedi di unire le varianti che differiscono solo leggermente, o di trasformare una variante i cui campi differiscono in un blocco proprio.
Stile sezione
Assegna a una sezione uno stile nei metadati della sezione quando il relativo sfondo è diverso da quello della pagina, l’allineamento non è l’impostazione predefinita o il contenuto predefinito è posizionato accanto a un blocco. Lo stile viene denominato dopo l’aspetto, ad esempio dark, light-grey o centered. Il testo e i pulsanti nella sezione prendono il loro colore dallo stile, pertanto un colore da solo non crea mai un blocco o una variante.
Concordare l’elenco degli stili di sezione e dei relativi nomi, in modo che gli autori possano scegliere tra gli stessi elementi in ogni pagina.

Per orientare la struttura:

  1. Prima di eseguire la migrazione, esaminare il catalogo nella visualizzazione Planning e correggere i nomi e i raggruppamenti dei blocchi. Vedere Ottimizzazione del catalogo.
  2. Registra i blocchi, le varianti e gli stili di sezione del progetto in AGENTS.md, in modo che l’agente possa riutilizzarli nelle pagine successive e nelle sessioni successive. Consulta Convenzioni sul contenuto del documento.
  3. Controllare ogni pagina di esempio nella visualizzazione documento del pannello di anteprima, che mostra sezioni, blocchi e contenuto predefinito. Vedi Visualizzazioni contenuto.
  4. Correggi un pattern errato nello script di importazione in modo che l’importazione in blocco ripeta la correzione su ogni pagina. Vedi Migrazione dell’agente su scala.
  5. Chiedere all’autore di modificare una pagina di esempio. Se esitano su quale blocco, variante o stile utilizzare, ci sono troppe scelte.

Mantieni le scelte degli autori minori. Il sistema di progettazione dovrebbe prendere le decisioni che gli autori non dovrebbero prendere: quando un blocco ha bisogno di più di una manciata di varianti o opzioni, chiedi se alcuni di loro appartengono alla progettazione.

Stima prima del commit estimate

Il catalogo e le prime pagine di esempio forniscono una stima in base al lavoro necessario per il sito, non al numero di pagine:

  1. Catalogare il sito. Il catalogo elenca i modelli, le varianti di blocco e le impostazioni internazionali e gli URL con errori. Vedi Prepara e catalogo.
  2. Convalida pagine di esempio dei modelli principali. Registra ciò di cui ciascuno ha bisogno: nuovi blocchi, correzioni per importare script, stili e modifiche alla struttura del contenuto.
  3. Ridimensiona i modelli rimanenti dalle pagine di esempio necessarie. I modelli successivi riutilizzano i blocchi già esistenti, quindi contano i blocchi aggiunti da ciascuno di essi. Una pagina con un layout proprio conta come modello proprio.
  4. Aggiungi gli elementi che non vengono importati: il comportamento registrato in Comportamento nell’ambito scope e il lavoro di progetto deciso e generato dal team.

Verifica la stima rispetto al record del primo batch per URL.

Lavora come team collaboration

Diverse persone possono lavorare sullo stesso progetto con l’agente, ognuna nel proprio area di lavoro della console. Condividono il codice tramite Git e il contenuto tramite la destinazione del contenuto. La console non mostra chi sta lavorando su cosa, e non unisce le modifiche di due persone alla stessa pagina, quindi concorda chi lavora su cosa e continua a parlare con gli altri.

L’ambito è più importante con un agente che senza uno. Una singola richiesta può modificare molti file, quindi quando due persone cambiano gli stessi blocchi o stili contemporaneamente, qualcuno deve risolvere manualmente i conflitti tra più file.

Guidare la migrazione phases

Una migrazione viene eseguita in più fasi. L’agente esegue la maggior parte del lavoro ripetitivo in ognuna di esse e il tuo team prende le decisioni e firma il risultato. Consenti a una persona, come il lead di migrazione, di eseguire le prime fasi; altre si uniscono una volta risolti i blocchi e gli script di importazione. Vedi Lavoro come team.

I collaboratori visivi possono lavorare sullo stile a partire dalla fase delle pagine di esempio. Vedi Apporta modifiche visive.

Iniziare con una persona, quindi dividere il lavoro divide-work

I primi passaggi gettano le basi su cui tutto il resto si basa: gli stili globali, i primi blocchi e gli script di importazione dei primi modelli. Lasciate che una sola persona li imposti. Prima di dividere l’opera, verifica che i blocchi corrispondano al contenuto reale e siano facili da utilizzare per gli autori. Vedi Forma la struttura del contenuto.

Una volta che il team è d’accordo sui blocchi, suddividi il lavoro in modo che le persone possano cambiare i file:

  • Per blocco: Una persona perfeziona il blocco delle schede mentre un’altra crea un carosello.
  • Per modello: Ogni persona perfeziona lo script di importazione di un modello diverso. Vedi Migrazione dell’agente su scala.
  • Per competenza: Una finestra di progettazione perfeziona lo stile dei blocchi esistenti mentre uno sviluppatore crea un’integrazione.

Non assegnare a due persone lo stesso blocco, gli stili globali o lo stesso script di importazione contemporaneamente a meno che non concordino su come coordinarsi.

Condividi codice in piccoli passaggi share-code

  1. Concordare un ramo condiviso, ad esempio main o un ramo di sviluppo. Ogni persona passa alla propria area di lavoro con Cambia ramo nella vista Codice.
  2. Mantieni ogni richiesta all’agente incentrata su un blocco, modello o attività. Invia il risultato non appena funziona, con Crea nuovo PR: la console invia le modifiche a un nuovo ramo, apre una richiesta di pull nel ramo condiviso e lascia l’area di lavoro nel nuovo ramo.
  3. Rivedi e unisci spesso le richieste di pull. Le piccole modifiche sono meno conflittuali e richiedono una revisione più rapida; una richiesta di pull che rimane aperta per giorni raccoglie i conflitti.
  4. Prima di avviare una nuova attività, torna al ramo condiviso con Cambia ramo e richiamalo con Sincronizza > Estrai > Codice, in modo da sfruttare il lavoro unito di tutti.

Se un pull non è disponibile o segnala un conflitto, vedere Se un altro utente ha modificato il ramo.

Piccole e frequenti spinte danno anche al team una storia leggibile di ciò che l’agente è cambiato e perché. Per ottenere un commit per richiesta, vedere Lascia un record di ogni richiesta.

Coordinare le modifiche al contenuto share-content

Il contenuto non presenta alcuna unione. L’area di lavoro contiene copie delle pagine e un caricamento sostituisce la pagina nella destinazione del contenuto con la tua copia. Se due persone cambiano la stessa pagina, l’ultimo caricamento vince e le modifiche dell’altra persona vanno perse. Assegna ogni pagina, o set di pagine, a una persona alla volta.

Per caricare nel tuo workspace le pagine che altri utenti hanno caricato:

  • Apri una pagina che mostra un’icona cloud nella visualizzazione contenuto. La console lo scarica nell’area di lavoro.
  • Nei progetti basati su documenti, seleziona Sincronizza > Estrai > Contenuto per scaricare ogni pagina da Experience Workspace. Sostituisce le copie locali, incluse le modifiche che non sono state caricate, quindi carica le modifiche che desideri mantenere per prime.

Importa in batch batches

Utilizza il flusso di lavoro di importazione in blocco del catalogo e richieste di importazione in blocco dopo aver convalidato le pagine di esempio.

  1. Importa un piccolo batch con lo script di importazione del modello.
  2. Controlla le pagine ordinarie e i casi edge. Se lo script di importazione non è corretto, correggilo e importa nuovamente le pagine interessate prima di continuare.
  3. Mantieni un record per ogni URL di origine: destinazione, stato di importazione, errori, approvazione ed eventuali esclusioni approvate.
  4. Continua modello per modello. Numero di pagine individuate, analizzate, importate, non riuscite, ignorate e disconnesse separatamente.
  5. Ricontrolla le pagine di esempio precedenti quando modifichi gli stili condivisi, gli script di importazione, i modelli di blocchi o il codice di blocco.

Una volta che gli autori iniziano a modificare le pagine migrate nella destinazione del contenuto, le loro pagine diventano l’origine della verità. L’importazione o il caricamento di queste pagine sovrascrive nuovamente il lavoro degli autori e uno script di importazione corretto non lo unisce, quindi concorda con gli autori.

Completa il sito complete-site

L’importazione automatizzata è una parte della consegna. Attuare e verificare i requisiti concordati, tra cui:

  • Intestazione, piè di pagina, navigazione, collegamenti interni e pagine di errore.
  • Immagini, download, font, autorizzazioni per le risorse ed eventuali riferimenti Dynamic Media conservati.
  • Titoli, descrizioni, URL canonici, dati strutturati, reindirizzamenti, sitemap e relazioni internazionali, se necessario.
  • Forms, search, commerce, funzioni per gli account, analytics, consenso e altre integrazioni.
  • Indicazioni per l’authoring, proprietà operativa, accesso e configurazione della distribuzione.

L’agente implementa il lato codice di questi, ad esempio blocchi che chiamano l’API di ricerca o di e-commerce, moduli e il codice che carica analisi e consenso. Non può configurare sistemi esterni all’archivio e ai contenuti, come il servizio di ricerca, la rete CDN o l’account di analisi, e non decide i tuoi requisiti. Fornisci la documentazione API e il comportamento concordato, e assegna un nome al proprietario di ciascun sistema esterno che firma il risultato. Consulta Servizi e applicazioni Connect, per moduli, Invii modulo e per pagine di prodotti, Pagine Commerce.

Immagini e documenti assets

Il modo in cui le immagini raggiungono il nuovo sito dipende dalla destinazione del contenuto:

  • Experience Workspace: mentre lavori nella console, una pagina importata può ancora fare riferimento a immagini nel sito di origine. Quando carichi la pagina, la console carica le immagini in essa contenute, incluse quelle scaricate dalla sorgente, in una cartella denominata dopo la pagina con un punto iniziale. Quindi indirizza la pagina alle copie caricate. Se un’immagine risulta mancante, in un formato non supportato o ambiguo, la console la segnala e non carica la pagina. Dopo il caricamento, verifica che tutte le immagini siano arrivate. Vedi Carica contenuto.
  • Authoring Experience Manager: seleziona Carica immagini quando carichi il pacchetto di contenuti e scegli una cartella in /content/dam/. Il valore predefinito è /content/dam/site. Vedi Carica contenuto.
  • Adobe Dynamic Media: le immagini che l’origine fornisce da Dynamic Media, inclusi Scene7 e Dynamic Media con URL OpenAPI, rimangono lì. La pagina importata fa riferimento a tali elementi e il codice del progetto ne esegue il rendering.

Edge Delivery Services offre immagini di dimensioni e formati adatti a ogni schermo. Controlla i file di grandi dimensioni, i video e le immagini SVG rispetto ai limiti per i tipi di file e le dimensioni.

Controllare i collegamenti ai documenti, ad esempio i PDF, nelle pagine di esempio. Ogni collegamento deve fare riferimento a una copia nel nuovo sito e non al sito di origine che verrà ritirato.

URL, reindirizzamenti e metadati di ricerca urls-seo

L’agente prende il percorso di ogni pagina dal relativo URL di origine. Il percorso viene convertito in minuscolo, rimuove .html, converte un / finale in index e sostituisce altri caratteri, ad esempio spazi e trattini bassi, con trattini. /About_Us.html diventa /about-us. Ogni URL che cambia in questo modo, o che cambi di proposito, ha bisogno di un reindirizzamento.

L’agente non crea reindirizzamenti, sitemap o lingue alternative. Chiedeteli come attività, e rivedete il risultato:

  • Reindirizzamenti: Un foglio di calcolo redirects con colonne Source e colonne Destination, una riga per URL, senza caratteri jolly. Chiedi all’agente di elencare gli URL di origine il cui percorso è stato modificato, come righe per il foglio. Vedi Reindirizzamenti.
  • Metadati pagina: L’importazione mantiene nel blocco di metadati il titolo, la descrizione e l’immagine social di ogni pagina. Per impostare i metadati per più pagine contemporaneamente, utilizzare un foglio di calcolo metadata. Vedi Metadati in Blocco.
  • Mappa del sito e lingue: un file helix-sitemap.yaml nell’archivio, che può includere le lingue alternative (hreflang) di ogni pagina. Vedi Sitemap.
  • Motori di ricerca: i siti di anteprima e live, *.aem.page e *.aem.live, sono nascosti dai motori di ricerca; il dominio di produzione non lo è. Controllare robots.txt prima del passaggio del mouse. Consulta robots.txt.
  • Indice query: Elenchi di pagine, ad esempio elenchi di articoli e ricerche nel sito, letti da un indice di query che include solo pagine pubblicate. Vedere Indicizzazione.

Verifica e disconnetti acceptance

Concorda con il proprietario del sito su cosa deve funzionare prima del rilascio e testalo sui siti di anteprima e live. Il proprietario del sito firma il risultato con tester e autori.

Area
Disconnesso quando
Copertura
Ogni URL nell’ambito ha una destinazione o un’eccezione approvata. Le pagine non riuscite e quelle saltate vengono risolte o registrate.
Contenuto
Il testo, i collegamenti, le risorse, i metadati e il contenuto delle impostazioni internazionali sono completi e corretti.
Authoring
Gli autori possono modificare i campi e i blocchi tipici, salvare, riaprire e visualizzare in anteprima il risultato nel proprio editor.
Design
I layout approvati per desktop e dispositivi mobili funzionano su contenuti reali, incluse varianti di testo lunghe e blocchi.
Funzione
Navigazione, interazione con la tastiera, moduli, integrazioni e percorsi di utenti concordati funzionano.
Qualità
Accessibilità, prestazioni, SEO (Search Engine Optimization) e controlli di sicurezza pertinenti soddisfano i requisiti concordati del progetto. Gli strumenti di accessibilità automatizzata individuano solo i problemi che una regola può rilevare, quindi testa anche le pagine di esempio con una tastiera e un’utilità per la lettura dello schermo. Prestazioni di test con Informazioni PageSpeed; su GitHub, Edge Delivery Services esegue lo stesso controllo su ogni richiesta di pull per gli URL di test nella relativa descrizione.
Operazioni
La revisione dell’archivio, la pubblicazione dei contenuti, il ripristino, il monitoraggio e la proprietà del supporto sono documentati e testati in base alle esigenze.

Ogni segnale automatizzato controlla una cosa: uno stato di importazione eseguito dallo script, un pacchetto generato che il contenuto è stato convertito, un punteggio di somiglianza visiva che una pagina assomiglia alla sua origine e un punteggio di Lighthouse sul modo in cui una pagina viene caricata in un test di laboratorio. La preparazione alla produzione richiede ogni area della tabella.

Rilascio, recupero e consegna handoff

Il proprietario della versione coordina il processo di unione del codice, la pubblicazione dei contenuti e il passaggio al dominio, quindi conferma che i proprietari del sito lo hanno rilevato.

  1. Invia il codice disconnesso e rivedilo come richiesto dai criteri dell’archivio. L’unione in main aggiorna immediatamente il codice del sito attivo, quindi pianifica l’unione con la versione del contenuto. Consulta La pubblicazione delle modifiche.
  2. Carica solo il contenuto e le immagini approvati nella destinazione confermata. Controlla gli errori per ogni pagina e immagine.
  3. Verificare il contenuto salvato con la revisione del codice prevista nel sito di anteprima, *.aem.page.
  4. Ottieni l’approvazione della versione del sito e segui la pubblicazione configurata e il processo di cutover del dominio. La pubblicazione rende le pagine disponibili su *.aem.live; il cutover è ciò che serve loro sul tuo dominio, tramite la rete CDN gestita da Adobe o la tua rete CDN. Elabora l’elenco di controllo per la pubblicazione prima del passaggio.
  5. Controlla gli URL live, i reindirizzamenti, i percorsi di chiavi e il monitoraggio dopo il rilascio. La telemetria operativa mostra come i visitatori reali percepiscono le prestazioni del sito.
  6. Fornisci il passaggio di consegne del progetto, il record per URL, esempi di authoring, risultati di approvazione, eccezioni e contatti di ripristino.

Se qualcosa non va a buon fine, conserva l’URL o il percorso esatto, l’operazione e il registro degli errori. Riprovare l’ambito interessato più piccolo dopo aver corretto la causa. Non riavviare un batch riuscito perché una pagina non è riuscita.

Il push del codice, il caricamento di documenti, l’importazione di un pacchetto di contenuti in Experience Manager e la pubblicazione sono operazioni separate su sistemi separati. In caso di errore parziale, possono essere applicate solo alcune modifiche e nessun singolo rollback le annulla tutte. Recupera il codice tramite Git, i contenuti e le immagini attraverso la cronologia delle versioni della destinazione del contenuto o del processo concordato.

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