Aggiornare un’app esistente upgrade-existing-app
Utilizzare questa guida solo se l’app utilizza @adobe/llm-apps-runtime prima della versione 1.2.0 o i relativi widget EDS utilizzano il SDK delle app LLM prima del 0.1.13. Le app che soddisfano già entrambi i requisiti possono passare direttamente a Configura Adobe Analytics e Customer Journey Analytics.
In questa guida: Scopri come aggiornare e verificare il runtime di un’app precedente e il SDK EDS. Quindi torna alla guida all’impostazione di Analytics per abilitare Analytics e verificare la raccolta.
Prima di iniziare before-you-begin
È necessario accedere all’archivio del gestore e, per le app con widget EDS, all’archivio EDS collegato all’app. Se la tua app utilizza l’infrastruttura gestita di Adobe, richiedi l’accesso al codice prima di apportare aggiornamenti. Consulta Utilizzare l’infrastruttura gestita di Adobe.
Non è necessario creare un’altra app. Aggiorna solo i componenti che si trovano sotto le versioni supportate. Puoi riutilizzare la configurazione Adobe esistente che soddisfa i requisiti di installazione di Analytics.
Per le app con widget EDS, pubblica e verifica prima l’aggiornamento di SDK, quindi unisci l’aggiornamento di runtime e ridistribuisci l’app. I due aggiornamenti dell’archivio possono essere preparati indipendentemente, ma entrambi devono essere disponibili prima di testare la distribuzione abilitata per Analytics.
Controllare e aggiornare l’archivio azioni delle app LLM upgrade-runtime
-
Apri l’archivio del gestore collegato all’app e installane le dipendenze:
code language-bash npm install -
Controllare il runtime installato:
code language-bash npm ls @adobe/llm-apps-runtime -
Se il runtime è precedente alla versione 1.2.0, installa la versione corrente:
code language-bash npm install @adobe/llm-apps-runtime@latest npm ls @adobe/llm-apps-runtimeVerifica che la versione installata sia 1.2.0 o successiva. Mantieni una versione più recente supportata, se l’app ne utilizza già una.
-
Verificare che la dipendenza runtime e la relativa versione risolta soddisfino il requisito minimo. La versione dell’applicazione è separata dalla dipendenza runtime.
-
Eseguire i controlli del repository. Per il piatto bollente delle applicazioni LLM:
code language-bash npm test -- --runInBand npm run build npm run lintAnalizza gli errori prima di distribuirli. Se un controllo ha già esito negativo nella versione originale, registra tale baseline separatamente da eventuali errori introdotti dall’aggiornamento. Una build locale corretta non verifica la raccolta di analisi.
-
Eseguire il commit dell’aggiornamento delle dipendenze e del relativo file di blocco, quindi inviare e unire l’aggiornamento nel ramo predefinito dell’archivio del gestore, in genere
main. Cloni di distribuzione di quel ramo. Un aggiornamento presente solo localmente o su un ramo di funzionalità non unito non è incluso nella distribuzione.Quando esiste un file di blocco, la distribuzione installa le dipendenze con
npm ci, che utilizza le versioni registrate. La ridistribuzione non aggiorna automaticamente il runtime. Prima di eseguire la ridistribuzione, verifica la dipendenza aggiornata e la versione risolta nel ramo predefinito in GitHub.
Verifica e aggiorna l’archivio dei widget delle app LLM upgrade-sdk
Per le app con widget EDS, controlla il SDK nell’archivio EDS e nel runtime del server. L’aggiornamento di un archivio non aggiorna l’altro.
Alcuni archivi EDS includono script SDK copiati senza una dipendenza npm. Il browser carica direttamente gli script forniti, pertanto l’assenza di una voce di pacchetto non significa che SDK sia mancante. Aggiorna la distribuzione SDK copiata utilizzando il processo di aggiornamento SDK del progetto. L’aggiunta di una dipendenza npm permanente non è necessaria per un progetto che mantiene SDK come script copiati.
Per i progetti che gestiscono SDK tramite npm:
-
Dalla directory principale dell’archivio EDS, installa il SDK corrente e ne conferma la versione:
code language-bash npm install --save-dev @adobe/llmapps-sdk@latest npm ls @adobe/llmapps-sdkUtilizzare 0.1.13 o versione successiva. Mantieni una versione supportata successiva se il progetto ne utilizza già una.
-
Verificare che l’installazione abbia aggiornato la distribuzione SDK distribuita. Il hook di installazione sovrascrive gli script SDK copiati, quindi controlla eventuali personalizzazioni locali prima di confermare. L’aggiornamento solo della dichiarazione di dipendenza non aggiorna gli script utilizzati da EDS. Consulta Installare le app LLM SDK.
-
Eseguire i controlli dell’archivio EDS, ad esempio
npm run lint, e verificare che un widget esistente continui a eseguire il rendering e a rispondere alle interazioni. -
Esegui il commit della distribuzione di SDK aggiornata insieme a eventuali aggiornamenti di dipendenza e file di blocco. EDS fornisce direttamente gli script copiati, non il pacchetto npm installato.
Dopo entrambi i metodi di aggiornamento, invia e unisci l’aggiornamento nel ramo EDS utilizzato dall’URL script dell’azione. Verifica che l’URL serva il SDK aggiornato e che le relative librerie di supporto siano state caricate correttamente. Se l’URL utilizza il sito EDS live, completa i passaggi di pubblicazione per tale sito.
Passaggio successivo next-step
Torna a Configura Adobe Analytics e Customer Journey Analytics. Tutte le app devono abilitare Analytics e implementarle per raccogliere gli eventi; l’aggiornamento del runtime o di SDK da solo non abilita la raccolta.
Dopo aver salvato le impostazioni di Analytics, distribuisci in Stage e verifica nuovi eventi di interazione azione-chiamata e widget prima di distribuirli in Produzione. Verifica che l’azione e il widget continuino a funzionare e che una singola selezione di collegamento generi un evento di interazione widget.
Analytics inizia a raccogliere nuove interazioni dopo la distribuzione abilitata per Analytics. L’aggiornamento non ricostruisce le interazioni che si sono verificate prima dell’abilitazione della raccolta.