Neue Funktion: Verwenden von privaten Git-Repositories mit AEM as a Cloud Service

In AEM as a Cloud Service oder dem von Adobe gehosteten AEM 6.5-Produkt (AEM Managed Services oder "AMS") gibt es seit langem die Anforderung , dass für die Bereitstellung von Code in einer von Adobe gehosteten Umgebung dieser Code zuerst in das gehostete Git-Repository von Adobe übertragen werden muss.

Die Begründung ist ziemlich einfach: Das Cloud Manager CI/CD-Framework von Adobe muss eine Reihe von Überprüfungen des Codes durchführen, dann Builds für diesen Code über den containerisierten Build-Dienst ausführen und dann auch in der Lage sein, Releases im Repository zu markieren, sobald die Produktionsbereitstellungen abgeschlossen sind.

Privat vs. Adobe Repos - Kontext

Es gab lange Zeit eine Reihe von Komplexitäten und Einschränkungen, mit denen AEMaaCS- und AMS-Kunden bei der Verwendung zu kämpfen hatten, was es zu einer äußerst wünschenswerten und gefragten Funktion gemacht hat, ein privates Git-Repository mit Cloud-gehostetem AEM verwenden zu können, wie z. B.:

Pflege von zwei Repos

Das Adobe Git-Repository ist nur ein Bereitstellungs-Repository . Es soll nicht das primäre Git sein, mit dem Sie arbeiten, um Ihre AEM-Site zu entwickeln. Es gibt kein SLA für Verfügbarkeit oder Backups. Beim Ausführen Ihres Projekts müssen Sie also Ihr eigenes internes Repository sowie das Adobe-Repository für die Bereitstellung verwalten und dann die Synchronisierung zwischen diesen Repositorys verwalten.

Adobe Repo fehlen Funktionen wie Pull Requests

Es gibt eine Reihe von Funktionen, die der Adobe Git-Implementierung fehlen, was bestimmte Pipelines in der Frühphase etwas schwierig macht. Das Adobe Git verfügt beispielsweise nicht über Threading oder Pull Requests.

Dies wird zu einem Problem, wenn die Adobe CI/CD-Pipeline der einzige Ort ist, an dem Sie wirklich die gesamte Suite von Build-Automatisierungstests ausführen können, die Dinge wie Sicherheitsverletzungen, Leistungseinbußen, Verstöße gegen Sonarqube-Regeln usw. aufdecken würden.
Wenn Sie also eine neue Funktion haben, für die Sie eine PR öffnen möchten, von der Sie glauben, dass sie die Website schneller macht, müssen Sie diese PR auf Ihrem eigenen Github öffnen, Ihr Lead muss sie "genehmigen", auch wenn wir nicht wissen, ob sie die Build-Prüfungen besteht, Sie übergeben sie dann an das Adobe Git, an welchem Punkt es vielleicht SCHEITERT und dann war Ihre PR irgendwie wertlos.

Sicherheit & Benutzerverwaltung

Es gibt keine fein abgestimmten Steuerelemente für das Adobe-Git, um die Benutzerverwaltung und den Benutzerzugriff zu steuern. Am Ende müssen Sie also Ihre eigene Sicherheit in Ihrem eigenen Git implementieren und sich dann auf die Build-Automatisierung verlassen, die Sie auf Ihrer Seite erstellen, um zu versuchen, zu begrenzen, welche Branches, Commits, Änderungen usw. in das Adobe Git gelangen. Es ist möglich, fügt aber nur eine fehleranfällige Ebene der Rube-Goldberg-Komplexität hinzu.

Private Git-Repositories für AEM as a Cloud Service & AMS: Was hat Adobe veröffentlicht?

Um es klar zu sagen: Dies ist eine erste allgemeine Version dieser Funktion (die dieses Jahr auf dem Adobe Summit angekündigt wurde und im vergangenen Jahr mit verschiedenen Kunden in der Vorschau war). Daher unterstützt es nicht JEDE Funktion, die Sie sich wünschen, und es gibt eine Reihe von Einschränkungen, die Sie beachten sollten. Aber es ist ein großer Schritt vorwärts für diejenigen, die in dieser Welt leben, also werde ich versuchen, ein paar Dinge zu skizzieren, die es tun kann und was nicht.

Was Sie jetzt tun können:

• Verwenden Sie Github.com in Cloud Manager Pipelines: Sie können jetzt ein github.com Git-Repository als Bereitstellungs-Repository in Adobe Cloud Manager hinzufügen.
  
  Anmerkung: Dies bezieht sich speziell auf die öffentliche https://github.com/ Website und nicht auf selbst gehostete Github oder andere Git-Anbieter. Adobe verwendet eine Github-App, um den Zugriff für Git authentifizieren und verwalten zu können, und dies ist derzeit ein erforderlicher Teil des Prozesses.

  

  Dies ist wahrscheinlich eine der größten Hürden bei der Implementierung anderer Git-Anbieter.

• Ausführen von Codequalitätspipelines auf PRs: Ein sehr nützlicher Teil dieser "Linksverschiebung" in der Pipeline, die Sie dadurch durchführen können, ist das Öffnen von PRs in GitHub, die dann eine Cloud Manager Code Quality Pipeline starten können, die dann ihre Ergebnisse DIREKT IN DIE PR zurückmelden kann. Dies ist enorm wichtig, um überprüfen zu können, ob eine PR wirklich genehmigungsfähig ist oder ob sie zur Überarbeitung zurückgehen sollte.

  

• PR-Pipelines werden automatisch erstellt und automatisch beschnitten: Wenn Sie eine PR öffnen, die eine Pipeline in Codequalität in Ihrem Cloud Manager startet, wird eine Pipeline speziell für diese PR erstellt und speziell für diese PR ausgeführt und ausgegeben. Wenn diese PR geschlossen wird, entfernt Cloud Manager diese Pipeline automatisch, damit Sie nicht mit einer Million PR-Pipelines verstopft werden.
  
  Dieses Verhalten ist in Ihrem Projekt konfigurierbar.

  

• Ausführen von Full-Stack-Pipelines : Nach einer Prüfung der Codequalität und der Genehmigung von PRs kann man dann Cloud Manager Full-Stack-Pipelines so einrichten, dass sie direkt aus Ihrem Github-Repository ausgeführt werden können, ohne das Cloud Manager Adobe Repo überhaupt zu durchlaufen.
  
  Diese Bereitstellungen können bis zur Produktion reichen.

• Funktioniert sowohl auf AMS (AEM 6.5) als auch auf AEM as a Cloud Service: Dies unterstützt beide Arten von Infrastrukturen, mit den gleichen Einschränkungen.

Was Sie noch nicht tun können:

• Verwenden Sie andere Nicht-GitHub-Git-Repos : Diese Funktion funktioniert nur auf https://github.com. Also, wenn Sie "company.github.com" haben oder "gitlab.com" oder "bitbucket.com" oder Azure-Repos oder einen anderen Nicht-GitHub-Git-Anbieter verwenden, funktioniert dies für Sie noch nicht.
  
  Adobe hat gesagt, dass sie aktiv daran arbeiten, andere Git-Anbieter basierend auf den Kundenbedürfnissen zu priorisieren und zu aktivieren - wenn Sie also einen BEDARF haben, verschwenden Sie keine Zeit und wenden Sie sich an jeden Adobe-Mitarbeiter, den Sie kennen und der Ihnen zuhört.

• Keine Konfigurations-, Front-End- oder Web-Tier-Pipelines: Derzeit funktioniert diese Funktion nur mit der "Full-Stack-Pipeline", die alles in Ihrem AEM-Projekt bereitstellt. Wenn Sie die anderen Submodulpipelines verwenden, z. B. die Web-Tier-Pipeline zum Bereitstellen von Nur-Dispatcher-Code oder die Config-Pipeline zum Bereitstellen Ihrer CDN-Konfigurationen, ist dieses Feature noch nicht für Sie geeignet.

• Git-Trigger funktioniert noch nicht: Wenn Sie versuchen, eine Pipeline (Codequalität oder Bereitstellung) mit einem Git-Trigger zu starten, sodass die Bereitstellung gestartet wird, sobald der Code festgeschrieben wurde, funktioniert dies noch nicht.

  

  Auch wenn "Deployment Trigger: On Git Changes" aktiviert ist, müssen Sie die Bereitstellung derzeit noch manuell auslösen. Dies wird nun auch im Abschnitt "Einschränkungen" der Dokumentation erwähnt. (Hut ab vor Sathish Balan , der darauf hingewiesen hat!)

Perfektionieren Ihrer AEM-Pipeline

Wenn dies nach etwas aussieht, das Sie vielleicht selbst ausprobieren möchten, finden Sie hier die Dokumentation zu den ersten Schritten mit selbstverwaltetem Github in AEM.

Wenn Sie sich jedoch nicht sicher sind, ob Sie dies implementieren möchten oder nicht, oder wenn Sie andere Bereitstellungs- oder CI/CD-Sorgen haben, über die Sie sprechen möchten, spreche ich gerne mit Ihnen!

Um mehr zu diesem Thema zu erfahren (wenn Sie Podcasts mögen), diskutieren unser CTO Dwayne Hale und ich hier die Vor- und Nachteile des Betriebs von Cloud- und selbst gehosteten AEM-Geräten.

Gefällt Ihnen, was Sie gehört haben? Haben Sie Fragen dazu, was für Sie das Richtige ist? Wir würden uns freuen, mit Ihnen zu sprechen! Kontaktieren Sie uns

Podcast-Episoden & Blogbeiträge