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:
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
- 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.
- 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. - Esaminare il catalogo nella visualizzazione Pianificazione. Correggi i raggruppamenti di modelli e blocchi ed esamina gli URL con errori.
- 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.
- 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:
- 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.
- 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.
- 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. - 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.
- 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.
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/backpacksehttps://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.
-
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.
-
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.
-
Applica lo stile di origine o segui il flusso di lavoro di riprogettazione. Controlla gli stili globali prima di perfezionare i singoli blocchi.
-
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.
-
Carica una pagina di esempio nella destinazione del contenuto, quindi modificala, salvala, riaprila e visualizzala in anteprima:
- Caricamento e anteprima basati su documenti.
- Conversione, caricamento di pacchetti e verifica nell’editor universale la creazione di Experience Manager.
-
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.
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.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.Per orientare la struttura:
- Prima di eseguire la migrazione, esaminare il catalogo nella visualizzazione Planning e correggere i nomi e i raggruppamenti dei blocchi. Vedere Ottimizzazione del catalogo.
- 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. - Controllare ogni pagina di esempio nella visualizzazione documento del pannello di anteprima, che mostra sezioni, blocchi e contenuto predefinito. Vedi Visualizzazioni contenuto.
- 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.
- 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:
- 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.
- 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.
- 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.
- 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
- Concordare un ramo condiviso, ad esempio
maino un ramo di sviluppo. Ogni persona passa alla propria area di lavoro con Cambia ramo nella vista Codice. - 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.
- 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.
- 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.
- Importa un piccolo batch con lo script di importazione del modello.
- 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.
- Mantieni un record per ogni URL di origine: destinazione, stato di importazione, errori, approvazione ed eventuali esclusioni approvate.
- Continua modello per modello. Numero di pagine individuate, analizzate, importate, non riuscite, ignorate e disconnesse separatamente.
- 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
redirectscon 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.yamlnell’archivio, che può includere le lingue alternative (hreflang) di ogni pagina. Vedi Sitemap. - Motori di ricerca: i siti di anteprima e live,
*.aem.pagee*.aem.live, sono nascosti dai motori di ricerca; il dominio di produzione non lo è. Controllarerobots.txtprima 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.
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.
- Invia il codice disconnesso e rivedilo come richiesto dai criteri dell’archivio. L’unione in
mainaggiorna immediatamente il codice del sito attivo, quindi pianifica l’unione con la versione del contenuto. Consulta La pubblicazione delle modifiche. - Carica solo il contenuto e le immagini approvati nella destinazione confermata. Controlla gli errori per ogni pagina e immagine.
- Verificare il contenuto salvato con la revisione del codice prevista nel sito di anteprima,
*.aem.page. - 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. - 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.
- 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.