Setup van het Enterprise Development Team voor AEM as a Cloud Service enterprise-setup

Leer hoe u uw ontwikkelingsteam voor ondernemingen kunt instellen en schalen en hoe AEM (Adobe Experience Manager) as a Cloud Service uw ontwikkelingsproces kan ondersteunen.

Inleiding introduction

Om klanten met de montages van de ondernemingsontwikkeling te steunen, integreert AEM as a Cloud Service volledig met Cloud Manager en zijn doel-gebouwde, geadviseerde pijpleidingen CI/CD. Deze pijpleidingen en de diensten worden gebouwd gebaseerd op beste praktijken, die grondig het testen en de hoogste codekwaliteitverzekeren.

Cloud Manager-ondersteuning in de ontwikkeling van een Enterprise-team cloud-manager

Om snel aan boord te kunnen gaan, biedt Cloud Manager alles wat nodig is om meteen aan de slag te gaan met het ontwikkelen van digitale ervaringen, waaronder een Git-opslagplaats voor aanpassingen, die vervolgens worden gebouwd, geverifieerd en geïmplementeerd door Cloud Manager.

Met Cloud Manager kunnen ontwikkelingsteams vaak werken aan het doorvoeren van wijzigingen zonder afhankelijk te zijn van het personeel van de Adobe.

Er zijn drie typen omgevingen beschikbaar in Cloud Manager.

De code kan aan ontwikkelmilieu's worden opgesteld gebruikend een niet productiepijplijn. Voor het opvoeren en productiemilieu's, die altijd samen gaan en zo bevestiging vóór productieplaatsing als beste praktijken verzekeren, gebruikt een productiepijpleiding kwaliteitsspoortenom de toepassingscode en de configuratieveranderingen te bevestigen.

De productiepijpleiding stelt de code en de configuratie aan het opvoeren milieu eerst op, test de toepassing, en stelt definitief aan productie op.

Een Cloud Service-SDK die altijd wordt bijgewerkt met de nieuwste AEM as a Cloud Service-verbeteringen, maakt lokale ontwikkeling mogelijk rechtstreeks met behulp van de lokale hardware van de ontwikkelaar. Deze aanpak maakt een snelle ontwikkeling met zeer lage omlooptijden mogelijk. Op die manier kunnen ontwikkelaars in hun vertrouwde lokale omgeving blijven en kiezen uit een groot aantal verschillende ontwikkelingsprogramma's, en overstappen op ontwikkelomgevingen of productie wanneer ze dat nodig achten.

Cloud Manager ondersteunt flexibele instellingen voor meerdere teams die kunnen worden aangepast aan de behoeften van een onderneming. Om stabiele plaatsingen over veelvoudige teams te verzekeren, bevestigt de gepositioneerde pijpleiding Cloud Manager en test de code van alle teams samen. Deze benadering helpt situaties te voorkomen waarin de veranderingen van één team de productie voor alle teams beïnvloeden.

Voorbeeld van een echte wereld real-world-example

Elke onderneming heeft verschillende vereisten met inbegrip van verschillende teamopstelling, processen, en ontwikkelingswerkstromen. De hieronder beschreven setup wordt door de Adobe gebruikt voor verschillende projecten die ervaring bieden boven op AEM as a Cloud Service.

De Adobe Creative Cloud-toepassingen, zoals Adobe Photoshop of Adobe Illustrator, bevatten bijvoorbeeld inhoudsbronnen, zoals zelfstudies, voorbeelden en hulplijnen die beschikbaar zijn voor eindgebruikers. Clienttoepassingen verbruiken inhoud van AEM as a Cloud Service zonder kop. Ze maken API-aanroepen naar de AEM Cloud-publicatielaag om gestructureerde inhoud op te halen als JSON-streams. Bovendien, wordt het Netwerk van de Levering van de Inhoud (CDN) in AEM as a Cloud Servicegebruikt om zowel gestructureerde als ongestructureerde inhoud met optimale prestaties te dienen.

De teams die aan dit project bijdragen volgen het volgende proces.

Elk team gebruikt zijn eigen ontwikkelworkflow en heeft een aparte Git-opslagplaats. Voor instapprojecten wordt een extra gedeelde Git-opslagplaats gebruikt. Deze Git-opslagplaats bevat de basisstructuur van de Cloud Manager Git-opslagplaats, inclusief de gedeelde Dispatcher-configuratie.

Voor het instappen van een nieuw project moet in het projectbestand Maven van de reactor een lijst worden opgenomen in de hoofdmap van de gedeelde Git-opslagplaats. Voor Dispatcher-configuratie wordt een nieuw configuratiebestand gemaakt in het Dispatcher-project. De hoofdconfiguratie van Dispatcher omvat dan dit dossier. Elk team is verantwoordelijk voor zijn eigen Dispatcher-configuratiebestand. Wijzigingen in de gedeelde Git-opslagplaats zijn zeldzaam en zijn gewoonlijk alleen vereist wanneer een nieuw project wordt gestart. Het belangrijkste werk wordt gedaan door elk projectteam binnen hun eigen bewaarplaats van het Git.

De bewaarplaats van het Git voor elk wordt opstelling gebruikend AEM Archetype van het Projecten volgt zo de beste praktijken voor vestiging AEM Projecten. De enige uitzondering hierop is de Dispatcher-configuratie, die wordt uitgevoerd in de gedeelde Git-opslagplaats, zoals hierboven beschreven.

Elk team gebruikt een vereenvoudigde Git-workflow met twee vertakkingen + N, volgens het Git-flowmodel:

De ontwikkeling wordt gedaan in een eigenschaptak. Wanneer de eigenschap rijpt, wordt het samengevoegd in de ontwikkelingstak. Voltooide en gevalideerde functies worden gekozen uit de ontwikkelingstak en samengevoegd in de stabiele vertakking.

Alle wijzigingen worden doorgevoerd via PR's (verzoeken om uitwissen). Kwaliteitskoppels valideren automatisch elke PR. Sonar wordt gebruikt voor kwaliteitscontrole van de code en er wordt een reeks testreeksen uitgevoerd om ervoor te zorgen dat de nieuwe code geen regressie introduceert.

De installatie in de Cloud Manager Git-opslagplaats heeft twee vertakkingen.

Elke duw aan de bewaarplaats van het Git van een team in of de ontwikkeling of de stabiele tak teweegbrengt de actie van a GitHub.

Alle projecten volgen de zelfde opstelling voor de stabiele tak. Een duw naar de stabiele tak van een project wordt automatisch geduwd aan de stabiele tak in de bewaarplaats van de Git van Cloud Manager. Een duw naar de stabiele tak brengt de productiepijpleiding in Cloud Manager in werking. Elke duw door om het even welk team in een stabiele tak brengt de productiepijpleiding teweeg. De productieplaatsing wordt bijgewerkt als alle kwaliteitspoorten overgaan.

Penselen naar de ontwikkelingsvertakking worden anders verwerkt. Een duw aan een ontwikkelaartak in de bewaarplaats van de it van een team teweegbrengt ook een actie GitHub teweeg. Deze actie duwt automatisch de code in de ontwikkelingstak in de bewaarplaats van het Git van Cloud Manager. Deze code-push activeert echter niet automatisch de niet-productiepijplijn. Een aanroep van de Cloud Manager API activeert deze.

Het runnen van de productiepijpleiding omvat het controleren van de code van alle teams via de verstrekte kwaliteitsspoortaten. Nadat de code aan stadium wordt opgesteld, worden de tests en de controles in werking gesteld zodat werkt alles zoals verwacht. Wanneer alle poorten worden doorgegeven, worden de wijzigingen doorgevoerd in de productie zonder onderbreking of downtime.

Voor lokale ontwikkeling, wordt SDK voor AEM as a Cloud Servicegebruikt. Met de SDK kunnen een lokale auteur, publicatie en Dispatcher worden ingesteld. Deze workflow maakt offline ontwikkeling en snelle doorlooptijden mogelijk. Soms wordt alleen de auteursomgeving gebruikt voor ontwikkeling, maar als u snel Dispatcher- en publicatieomgevingen instelt, kunt u alles lokaal testen voordat u naar de Git-opslagplaats gaat.

De leden van elk team controleren gewoonlijk de code van de gedeelde Git voor hun eigen projectcode. Andere projecten hoeven niet te worden gecontroleerd omdat de projecten onafhankelijk zijn.

Deze real-world opstelling kan als blauwdruk worden gebruikt en dan aan de behoeften van een onderneming worden aangepast. Met het flexibele vertakkings- en samenvoegingsconcept van Git kunt u de hierboven vermelde workflows variëren en aanpassen aan de behoeften van elk team. AEM as a Cloud Service steunt al deze variaties zonder de kernwaarde van de gedenkwaardige Cloud Manager-pijpleiding op te offeren.

Overwegingen bij de installatie van meerdere teams considerations

Met de Cloud Manager Git-opslagplaats en de productiepijpleiding gaat de volledige productiecode altijd door alle kwaliteitskates, waarbij deze als één uitzettingseenheid wordt behandeld. Op deze manier is het productiesysteem altijd zonder onderbreking of onderbreking.

Zonder een dergelijk systeem, omdat elk team afzonderlijk kan implementeren, bestaat daarentegen het risico dat een update van één team kan leiden tot problemen met productiestabiliteit. Daarnaast is coördinatie en geplande uitvaltijd nodig om updates uit te voeren. Met een toenemend aantal teams wordt de coördinatie-inspanning veel complexer en snel onbeheersbaar.

Als een probleem wordt ontdekt in de kwaliteitskates, wordt de productie niet beïnvloed, en het probleem kan worden ontdekt en worden bevestigd zonder het personeel van de Adobe dat wordt vereist om binnen te stappen. Zonder Cloud Service en zonder altijd de volledige plaatsing te testen, kunnen de gedeeltelijke plaatsingen stroomonderbrekingen veroorzaken die een verzoek vereisen om terug te draaien of zelfs volledig te herstellen van een steun. Gedeeltelijke tests kunnen ook aanleiding geven tot aanvullende problemen die later moeten worden opgelost, waarvoor opnieuw coördinatie en ondersteuning van het personeel van de Adobe vereist is.