Code en aanpassingen bijwerken upgrading-code-and-customizations
Bij het plannen van een upgrade moeten de volgende onderdelen van een implementatie worden onderzocht en aangepakt.
Overzicht overview
- de Analysator van AEM - stel de Analysator van AEM in werking zoals die in verbeterings planning wordt beschreven, en die in detail op wordt beschreven die de Complexiteit van de Verbetering met de Analysator van AEMpagina beoordelen. Er verschijnt een AEM Analyzer-rapport met meer informatie over gebieden die moeten worden opgelost naast de niet-beschikbare API's/bundels in de doelversie van AEM. Het AEM Analyzer-rapport geeft een indicatie van incompatibiliteiten in uw code. Als er geen LTS bestaat, is uw implementatie al compatibel met 6,5 LTS. U kunt er nog steeds voor kiezen om nieuwe ontwikkelingen uit te voeren voor het gebruik van de 6.5 LTS-functionaliteit, maar dit is niet nodig voor het behoud van compatibiliteit.
- ontwikkelt de Basis van de Code voor 6.5 LTS - creeer een specifieke tak of een bewaarplaats voor de codebasis voor de versie van het Doel. Gebruik info van Compatibiliteit vóór upgrade om gebieden met code te plannen die moeten worden bijgewerkt.
- compileert met 6.5 LTS Uber jar - de basis POMs van de Update codebasis aan punt aan 6.5 LTS uber jar en compileert code tegen het.
- stelt aan 6.5 LTS Milieu op - een schoon geval van AEM 6.5 LTS (Auteur + publiceer) zou omhoog in een milieu moeten worden gestaan Dev/QA. De bijgewerkte codebasis en een representatieve steekproef van inhoud (van huidige productie) zouden moeten worden opgesteld.
- QA- Bevestiging en Bug bevestigen - QA zou de toepassing op zowel Auteur als publiceer instanties van 6.5 LTS moeten bevestigen. Alle gevonden fouten moeten worden gecorrigeerd en toegewezen aan de basis van de 6.5 LTS-code. Herhaal indien nodig de Dev-Cycle totdat alle bugs zijn opgelost.
Voordat u verdergaat met een upgrade, moet u beschikken over een stabiele basis voor toepassingscode die grondig is getest op AEM 6.5 LTS.
De basiscode bijwerken upgrade-code-base
Creeer een Specifieke Tak voor 6.5 LTS Code in de Controle van de Versie create-a-dedicated-branch-for-6.5-lts-code-in-version-control
Alle code en configuraties die vereist zijn voor uw AEM-implementatie, moeten met een of andere vorm van versiebeheer worden beheerd. Een specifieke tak in versiecontrole zou voor het beheren van om het even welke veranderingen nodig voor de codebasis in de doelversie van AEM moeten worden gecreeerd. Het iteratieve testen van de codebasis tegen de doelversie van AEM en de verdere insectenmoeilijke situaties wordt beheerd in deze tak.
AEM Uber Jar-versie bijwerken update-the-aem-uber-jar-version
De AEM Uber jar omvat alle AEM APIs als één enkele gebiedsdeel in uw Maven project pom.xml. Het is altijd verstandig om de Uber Jar op te nemen als één afhankelijkheid in plaats van afzonderlijke AEM API-afhankelijkheden op te nemen. Wanneer u de basiscode bijwerkt, wijzigt u de versie van Uber Jar zodat deze naar de 6.5 LTS-versie van AEM verwijst. Vervangen API's of methoden bijwerken zodat deze compatibel zijn met de doelversie van AEM. Compileer de codebasis opnieuw tegen de nieuwe versie van Uber Jar.
<dependency>
<groupId>com.adobe.aem</groupId>
<artifactId>uber-jar</artifactId>
<version>6.6.0</version>
<classifier>apis</classifier>
<scope>provided</scope>
</dependency>
Jars van de Uber voor AEM 6.5
uber-jar-6.5.x.jar- Bevat alle openbare API's van AEM 6.5.uber-jar-6.5.x-apis-with-deprecations.jar- Bevat zowel openbare API's als verouderde API's van AEM 6.5.
Jars van de Uber voor AEM 6.5 LTS
Voor AEM 6.5 LTS zijn er weer twee soorten Uber Jars:
uber-jar-6.6.x-apis.jar- Bevat alle openbare API's van AEM 6.5 LTS.uber-jar-6.6.x-deprecated-apis.jar- Alleen verouderde API's van AEM 6.5 LTS worden opgenomen.
Zeer belangrijk Verschil: AEM 6.5 vs. AEM 6.5 LTS Uber Jars
- Als u in AEM 6.5 zowel openbare als verouderde API's nodig hebt, kunt u de enkele jar
uber-jar-6.5.x-apis-with-deprecations.jarin hetpom.xml-bestand opnemen. - Als u in AEM 6.5 LTS zowel openbare als verouderde API's nodig hebt, moet u twee aparte jars opnemen,
uber-jar-6.6.x-apis.jarvoor openbare API's enuber-jar-6.6.x-deprecated-apis.jarvoor verouderde API's.
Gemaakte coördinaten voor afgekeurde APIs Jar
<dependency>
<groupId>com.adobe.aem</groupId>
<artifactId>uber-jar</artifactId>
<version>6.6.0</version>
<classifier>deprecated-apis</classifier>
<scope>provided</scope>
</dependency>
Notities ontwikkelaar developer-notes
- AEM 6.5 LTS bevat geen Google guava-bibliotheek buiten de box, de vereiste versie kan naar behoefte worden geïnstalleerd.
- Sling XSS-bundel gebruikt nu de Java HTML Sanitizer-bibliotheek en het gebruik van de
XSSAPI#filterHTML()-methode moet worden gebruikt voor het veilig renderen van HTML-inhoud en niet voor het doorgeven van gegevens naar andere API's.
Testprocedure testing-procedure
Er moet een uitgebreid testplan worden opgesteld voor het testen van upgrades. Het testen van de geüpgrade codebasis en de toepassing moet eerst in lagere omgevingen worden uitgevoerd. Eventuele fouten moeten op iteratieve wijze worden gecorrigeerd totdat de basis van de code stabiel is. Dit geldt alleen als omgevingen op een hoger niveau worden bijgewerkt.
De upgradeprocedure testen testing-upgrade-procedure
De verbeteringsprocedure zoals die hier wordt geschetst zou op Dev en milieu's QA zoals die in uw aangepast in werking gesteld boek worden gedocumenteerd (zie plannend Uw Verbetering). De verbeteringsprocedure zou moeten worden herhaald tot alle stappen in het verbeteringsloopboek worden gedocumenteerd en het verbeteringsproces is vlot.
Testgebieden voor de implementatie implementation-test-areas-
Hieronder vindt u een aantal belangrijke onderdelen van een AEM-implementatie die onder uw testplan moeten vallen zodra de omgeving is bijgewerkt en de geüpgrade codebasis is geïmplementeerd.
Testplan en resultaten document document-test-plan-and-results
Er moet een testplan worden opgesteld dat de bovengenoemde testgebieden voor de implementatie bestrijkt. Het is vaak zinvol om het testplan te scheiden van de taaklijsten Auteur en Publiceren. Dit testplan zou op Dev, QA, en de milieu's van het Stadium moeten worden uitgevoerd alvorens de milieu's van de Productie te bevorderen. Testresultaten en prestatiemetriek moeten in lagere omgevingen worden vastgelegd om vergelijkingen te kunnen maken bij het upgraden van de Stage- en Production-omgeving.