Distribueren naar AEM as a Cloud Service deploying-to-aem-as-a-cloud-service

Inleiding introduction

De grondbeginselen van codeontwikkeling zijn in AEM as a Cloud Service vergelijkbaar met de oplossingen AEM On Premise en Managed Services. Ontwikkelaars schrijven code en testen deze lokaal, wat vervolgens wordt doorgegeven aan externe omgevingen op AEM as a Cloud Service. Cloud Manager, een optioneel hulpprogramma voor het leveren van inhoud voor Managed Services, is vereist. Dit leveringshulpmiddel is nu het enige mechanisme voor het opstellen van code aan AEM as a Cloud Service dev, stadium, en productiemilieu's. Voor snelle eigenschapbevestiging en het zuiveren alvorens die eerder vermelde milieu's op te stellen, kan de code van een lokaal milieu aan a Snelle Milieu van de Ontwikkelingworden gesynchroniseerd.

De update van AEM versieis altijd een afzonderlijke plaatsingsgebeurtenis van het duwen van douanecode. Op een andere manier bekeken, zouden de versies van de douanecode tegen de AEM versie moeten worden getest die op productie is omdat dat is wat het op de bovenkant wordt opgesteld. AEM versie-updates die daarna plaatsvinden (die vaak voorkomen en automatisch worden toegepast), zijn bedoeld om achterwaarts compatibel te zijn met de reeds geïmplementeerde klantencode.

In de rest van dit document wordt beschreven hoe ontwikkelaars hun praktijken moeten aanpassen zodat ze zowel met de updates van de AEM as a Cloud Service-versie als met de updates van de klant werken.

Klantenreleases customer-releases

Codering op basis van de juiste AEM versie coding-against-the-right-aem-version

Voor vorige AEM oplossingen, veranderde de huidigste AEM versie niet vaak (ruwweg jaarlijks met driemaandelijkse de dienstpakken) en de klanten zouden de productieinstanties aan de recentste snelstartversie op hun eigen tijd bijwerken, verwijzend naar API Jar. Toepassingen op AEM as a Cloud Service worden echter vaker automatisch bijgewerkt naar de nieuwste versie van AEM, zodat aangepaste code voor interne releases moet worden gebaseerd op de nieuwste AEM.

Net als bij bestaande niet-cloud AEM versies, wordt een lokale, offline ontwikkeling ondersteund op basis van een specifieke QuickStart en wordt verwacht dat deze ontwikkeling het meest geschikte middel is voor foutopsporing.

Om douanecode voor een interne versie te ontwikkelen, zou de relevante versie van AEM as a Cloud Service SDKmoeten worden gedownload en worden geïnstalleerd. Voor extra informatie over het gebruiken van de Hulpmiddelen van AEM as a Cloud Service Dispatcher, zie Dispatcher in de Wolk.

De volgende video biedt een overzicht op hoog niveau over hoe u code kunt implementeren in AEM as a Cloud Service:

Inhoudspakketten implementeren via Cloud Manager en Package Manager deploying-content-packages-via-cloud-manager-and-package-manager

Inzet via Cloud Manager deployments-via-cloud-manager

Klanten implementeren aangepaste code in cloudomgevingen via Cloud Manager. Cloud Manager transformeert lokaal geassembleerde inhoudspakketten naar een artefact dat voldoet aan het Sling Feature Model, dat is hoe een toepassing op AEM as a Cloud Service wordt beschreven wanneer deze in een cloudomgeving wordt uitgevoerd. Dientengevolge, wanneer het bekijken van de pakketten in Manager van het Pakketop de milieu's van de Wolk, omvat de naam "cp2fm"en de getransformeerde pakketten hebben alle meta-gegevens verwijderd. Er kan geen interactie met deze toepassingen plaatsvinden, wat betekent dat ze niet kunnen worden gedownload, gerepliceerd of geopend. Zie 🔗 voor gedetailleerde documentatie over de converter.
sling-org-apache-sling-feature-cpconverter op GitHub .

Inhoudspakketten die voor toepassingen op AEM as a Cloud Service zijn geschreven, moeten een duidelijke scheiding hebben tussen onveranderbare en muteerbare inhoud en Cloud Manager installeert alleen de veranderbare inhoud en voert ook een bericht uit zoals:

Generated content-package <PACKAGE_ID> located in file <PATH> is of MIXED type

De rest van deze sectie beschrijft de samenstelling en implicaties van onveranderbare en veranderbare pakketten.

Onveranderbare inhoudspakketten immutabe-content-packages

Alle inhoud en code die in de onveranderlijke gegevensopslagplaats voortkomen moeten in git worden gecontroleerd en door Cloud Manager worden opgesteld. Met andere woorden, in tegenstelling tot huidige AEM oplossingen, wordt de code nooit direct opgesteld aan een lopende AEM instantie. Deze workflow zorgt ervoor dat de code die voor een bepaalde release in een Cloud-omgeving wordt uitgevoerd, identiek is, waardoor het risico van onbedoelde codevariatie tijdens de productie wordt uitgesloten. Als voorbeeld, zou de configuratie OSGI aan broncontrole eerder dan beheerd bij runtime door middel van de de configuratiemanager van de AEM Webconsole moeten worden geëngageerd.

Aangezien de toepassingsveranderingen toe te schrijven aan het plaatsingspatroon door een schakelaar worden toegelaten, kunnen zij niet van veranderingen in de veranderbare bewaarplaats behalve de dienstgebruikers, hun ACLs, nodetypes, en de veranderingen van de indexdefinitie afhangen.

Voor klanten met bestaande codebases is het van essentieel belang dat de in AEM documentatie beschreven herstructureringsoefening in de opslagplaats wordt doorlopen om ervoor te zorgen dat inhoud die voorheen onder de /etc. viel, naar de juiste locatie wordt verplaatst.

Sommige extra beperkingen zijn van toepassing voor deze codepakketten, bijvoorbeeld, installeert hakenniet worden gesteund.

OSGI-configuratie osgi-configuration

Zoals hierboven vermeld, zou de configuratie OSGI aan broncontrole eerder dan door de Webconsole moeten worden geëngageerd. Te dien einde zijn onder meer de volgende technieken van toepassing:

Lees meer over configuratie OSGI bij het Vormen OSGi voor AEM as a Cloud Service.

Mabelinhoud mutable-content

Soms, zou het nuttig kunnen zijn om inhoudsveranderingen in broncontrole voor te bereiden zodat kan het door Cloud Manager worden opgesteld wanneer een milieu werd bijgewerkt. Het kan bijvoorbeeld redelijk zijn om bepaalde basismapstructuren uit te breiden. Of, regelup veranderingen in editable malplaatjes om beleidscomponenten toe te laten die door de toepassingsplaatsing werden bijgewerkt.

Er zijn twee strategieën om de inhoud te beschrijven die door Cloud Manager wordt geïmplementeerd in de gemuteerde opslagplaats, pakketten met gemuteerde inhoud en repoinit -instructies.

Tabelinhoudspakketten mutable-content-packages

De inhoud zoals de hiërarchieën van de omslagweg, de dienstgebruikers, en toegangscontroles (ACLs) worden typisch toegewijd in een bepaald archetype-Gebaseerd AEM project. De technieken omvatten het uitvoeren van AEM of het schrijven direct als XML. Tijdens het ontwikkelings- en implementatieproces verpakt Cloud Manager het resulterende veranderbare inhoudspakket. De veranderlijke inhoud wordt geïnstalleerd bij drie verschillende tijden tijdens de opstellen fase in de pijpleiding:

Voor het opstarten van een nieuwe versie van de toepassing:

Tijdens het opstarten van een nieuwe versie van de toepassing, maar vóór de omschakeling:

Na de overgang naar de nieuwe versie van de toepassing:

U kunt de installatie van veranderbare inhoud beperken tot auteur of publiceren door pakketten in te sluiten in de map install.auteur of install.publish onder /apps . De herstructurering om deze scheiding te weerspiegelen werd gedaan in AEM 6.5 en de details over geadviseerde projectherstructurering kunnen in AEM 6.5 documentatie worden gevonden.

Er is ook geen mechanisme om wijzigingen in het veranderbare inhoudspakket terug te draaien nadat deze zijn toegepast. Als klanten een probleem ontdekken, kunnen zij verkiezen om het in hun volgende codeversie of als laatste redmiddel te bevestigen, het volledige systeem aan een punt in tijd vóór de plaatsing herstellen.

Alle meegeleverde pakketten van derden moeten als compatibel met AEM as a Cloud Service worden gevalideerd, anders leidt de opname ervan tot een implementatiefout.

Zoals hierboven vermeld, zouden de klanten met bestaande codebasis aan de bewaarplaats herstructureringsoefening nodig door de 6.5 veranderingen in bewaarplaats moeten in overeenstemming zijn die in worden beschreven AEM 6.5 documentatie.

Opnieuw plaatsen repoinit

In de volgende gevallen verdient het de voorkeur de handmatige codering van expliciete instructies repoinit voor het maken van inhoud in de OSGI-fabrieksconfiguraties te gebruiken:

Het is aan te raden deze gevallen van wijziging van inhoud opnieuw te plaatsen om de volgende voordelen te bieden:

Wanneer Cloud Manager de toepassing implementeert, worden deze instructies onafhankelijk van de installatie van inhoudspakketten uitgevoerd.

Volg de onderstaande procedure om repoinit -instructies te maken:

Meer detail over repoinit kan in de het Verdelen documentatieworden gevonden

Package Manager "one offs" voor Mutable Content Packages package-manager-oneoffs-for-mutable-content-packages

Er zijn gebruiksgevallen waarin een inhoudspakket als "één uit" moet worden geïnstalleerd. Bijvoorbeeld, het invoeren van specifieke inhoud van productie aan het opvoeren om een productiekwestie te zuiveren. Voor deze scenario's, de Manager van het Pakketkan in milieu's op AEM as a Cloud Service worden gebruikt.

Aangezien Package Manager een runtimeconcept is, is het niet mogelijk om inhoud of code in de onveranderlijke opslagplaats te installeren, zodat zouden deze inhoudspakketten slechts uit veranderbare inhoud (hoofdzakelijk /content of /conf) moeten bestaan. Als het inhoudspakket inhoud bevat die gemengd is (zowel muteerbare als onveranderlijke inhoud), wordt alleen de veranderbare inhoud geïnstalleerd.

Alle inhoudspakketten die in Cloud Manager (zowel mutabel als onveranderbaar) zijn geïnstalleerd, worden in de gebruikersinterface van AEM Package Manager bevroren weergegeven. Deze pakketten kunnen niet opnieuw worden geïnstalleerd, worden herbouwd, of zelfs worden gedownload, en zijn vermeld met a "cp2fm" achtervoegsel, erop wijzend dat hun installatie door Cloud Manager werd beheerd.

Inclusief pakketten van derden including-third-party

Het is gebruikelijk voor klanten om vooraf gebouwde pakketten van derdebronnen zoals softwareverkopers zoals de vertaalpartners van de Adobe te omvatten. Het wordt aanbevolen deze pakketten te hosten in een externe opslagruimte en ernaar te verwijzen in de pom.xml . Deze methode is mogelijk voor openbare bewaarplaatsen en ook voor privé bewaarplaatsen met wachtwoordbescherming, zoals die in wordt beschreven wachtwoord beschermde gemandateerde bewaarplaatsen.

Als het opslaan van het pakket in een externe opslagplaats niet mogelijk is, kunnen klanten in een lokale, op bestandssysteem gebaseerde Maven-opslagplaats plaatsen, die als onderdeel van het project aan SCM is toegewezen. Er wordt naar verwezen door wat er van afhangt. De gegevensopslagruimte wordt gedeclareerd in de projectpom, zoals hieronder wordt geïllustreerd:

<repository>
    <id>project.local</id>
    <name>project</name>
    <url>file:${maven.multiModuleProjectDirectory}/repository</url>
</repository>

Alle meegeleverde pakketten van derden moeten voldoen aan de AEM as a Cloud Service-coderings- en verpakkingsrichtlijnen die in dit artikel worden beschreven, anders leidt de opname ervan tot een implementatiefout.

Het volgende Geweven POM.xml fragment toont hoe de derdepakketten in het "Container"pakket van het project kunnen worden ingebed, typisch genoemd "all", als filevault-package-maven-stop - in Gemaakt insteekconfiguratie.

...
<plugin>
  <groupId>org.apache.jackrabbit</groupId>
  <artifactId>filevault-package-maven-plugin</artifactId>
  <extensions>true</extensions>
  <configuration>
      ...
      <embeddeds>

          ...

          <!-- Include any other extra packages  -->
          <embedded>
              <groupId>com.vendor.x</groupId>
              <artifactId>vendor.plug-in.all</artifactId>
              <type>zip</type>
              <target>/apps/vendor-packages/container/install</target>
          </embedded>
      <embeddeds>
  </configuration>
</plugin>
...

Hoe de Rolling Inzet werkt how-rolling-deployments-work

Als AEM updates, worden de klantenversies opgesteld gebruikend een het rollen plaatsingsstrategie om de onderbreking van de auteurcluster in de juiste omstandigheden te elimineren. De algemene volgorde van gebeurtenissen wordt hieronder beschreven, waarbij knooppunten met zowel de oude als de nieuwe versie van de klantcode dezelfde versie van AEM code uitvoeren.

Indexen indexes

Nieuwe of gewijzigde indexen veroorzaken een extra indexerende of herindexerende stap alvorens de nieuwe versie verkeer kan nemen. De details over indexbeheer in AEM as a Cloud Service kunnen onder Inhoud Onderzoek en het Indexerenworden gevonden. U kunt de indexerende status van bouwstijlpagina's op Cloud Manager controleren, en een bericht ontvangen wanneer de nieuwe versie klaar is om verkeer te nemen.

AEM as a Cloud Service werkt momenteel niet met indexbeheerprogramma's zoals ACS Commons zorgen voor Oak Index.

Replicatie replication

Het publicatiemechanisme is achterwaarts compatibel met AEM Replicatie Java™ APIs.

Voor het ontwikkelen en testen van replicatie met de cloud gereed AEM QuickStart, moeten de klassieke replicatiemogelijkheden worden gebruikt met een Auteur/Publish-installatie. Als het ingangspunt voor de gebruikersinterface van AEM auteur is verwijderd voor de cloud, gaan gebruikers naar http://localhost:4502/etc/replication voor configuratie.

Achterwaarts Compatibele Code voor het Draaien Plaatsingen backwards-compatible-code-for-rolling-deployments

Zoals hierboven beschreven, impliceert de het rollen van AEM as a Cloud Service plaatsingsstrategie dat zowel de oude als nieuwe versies tezelfdertijd kunnen werken. Wees daarom voorzichtig met codewijzigingen die niet achterwaarts compatibel zijn met de oude AEM versie die nog steeds wordt uitgevoerd.

Bovendien moet de oude versie worden getest op compatibiliteit met eventuele nieuwe, door de nieuwe versie toegepaste structuren voor veranderbare inhoud als er sprake is van terugdraaiing, omdat gemuteerde inhoud niet wordt verwijderd.

De Gebruikers van de dienst en ACL Veranderingen service-users-and-acl-changes

Het veranderen van de dienstgebruikers, of ACLs die tot inhoud of code toegang hebben, kon tot fouten in de oudere AEM versies leiden resulterend in toegang tot die inhoud of code met verouderde de dienstgebruikers. Om dit gedrag aan te pakken, wordt aanbevolen wijzigingen door ten minste twee releases te laten doorlopen, waarbij de eerste release als een koppeling fungeert voordat deze wordt opgeschoond in de volgende release.

Indexwijzigingen index-changes

Als er wijzigingen in indexen worden aangebracht, is het belangrijk dat de nieuwe versie de indexen blijft gebruiken totdat deze worden beëindigd, terwijl de oude versie een eigen aangepaste set indexen gebruikt. De ontwikkelaar zou de technieken moeten volgen van het indexbeheer die onder Inhoud Onderzoek en het Indexerenworden beschreven.

Conservatieve codering voor terugdraaiversies conservative-coding-for-rollbacks

Als een mislukking na de plaatsing wordt gemeld of ontdekt, is het mogelijk dat het terugschroeven van prijzen aan de oude versie wordt vereist. Zorg ervoor dat de nieuwe code compatibel is met eventuele nieuwe structuren die door die nieuwe versie worden gemaakt, aangezien de nieuwe structuren (alle veranderbare inhoud) niet worden teruggedraaid. Als de oude code niet compatibel is, moeten fixes worden toegepast in verdere versies van de klant.

Rapid Development Environment (RDE) rde

Snelle Milieu's van de Ontwikkeling(of RDEs voor kort) staan ontwikkelaars toe om veranderingen snel op te stellen en te herzien, die de hoeveelheid tijd minimaliseren noodzakelijk om eigenschappen te testen die reeds om aan een lokaal ontwikkelingsmilieu worden bewezen te werken.

In tegenstelling tot gewone dev milieu's, die code als pijpleiding van Cloud Manager opstellen, gebruiken de ontwikkelaars bevel-lijn hulpmiddelen om code van een lokale ontwikkelomgeving aan RDE te synchroniseren. Nadat de veranderingen met succes in RDE worden getest, stel hen aan een regelmatige milieu van de Ontwikkeling van de Wolk door de pijpleiding van Cloud Manager op, die de code door de aangewezen kwaliteitspoorten zet.

Modi uitvoeren runmodes

In bestaande AEM oplossingen hebben klanten de mogelijkheid instanties uit te voeren met willekeurige uitvoeringsmodi en om OSGI-configuratie toe te passen of om OSGI-bundels op die specifieke instanties te installeren. De wijzen van de looppas die typisch worden bepaald omvatten de dienst (auteur en publiceer) en het milieu (rde, dev, stadium, prod).

AEM as a Cloud Service daarentegen is meer overtuigd over welke uitvoeringsmodi beschikbaar zijn en hoe de OSGI-bundels en de OSGI-configuratie aan hen kunnen worden toegewezen:

AEM as a Cloud Service staat het gebruik van uitvoeringsmodi niet toe om inhoud voor specifieke omgevingen of services te installeren. Als een ontwikkelomgeving moet worden voorzien van gegevens of HTML die zich niet in de het opvoeren of productie milieu's bevinden, kan de Manager van het Pakket worden gebruikt.

De ondersteunde configuraties in de uitvoeringsmodus zijn:

De configuratie OSGI die de meest passende looppaswijzen heeft wordt gebruikt.

Wanneer plaatselijk het ontwikkelen, wordt een looppas wijzestartparameter, -r, gebruikt om de loopwijzeConfiguratie te specificeren OSGI.

$ java -jar aem-sdk-quickstart-xxxx.x.xxx.xxxx-xxxx.jar -r publish,dev

Configuratie van onderhoudstaken in Source Control maintenance-tasks-configuration-in-source-control

De configuraties van de Taak van het onderhoud moeten in broncontrole worden voortgeduurd omdat het Hulpmiddelen > het scherm van Verrichtingen niet beschikbaar in de milieu's van de Wolk is. Dit voordeel zorgt ervoor dat veranderingen opzettelijk worden voortgeduurd eerder dan reactief worden toegepast en worden vergeten. Zie Taken van het Onderhoud in AEM as a Cloud Servicevoor extra informatie.