Migrieren von AEM-Produktionsinhalten zu QA und DEV
QA-Tester stehen bei der Validierung neuer Builds vor einem Dilemma: Sie möchten reale Testfälle haben, aber es ist schwierig, den tatsächlichen Produktionsinhalt nachzubilden.
Inhaltsautoren erstellen (und veröffentlichen) ständig neue Inhalte innerhalb des Produktionsautors. Die Menge an Inhalten kann sehr groß sein! Einige Unternehmen veröffentlichen 100, wenn nicht sogar 1.000 Seiten pro Tag. Wie kann ein Team von QA-Testern sicherstellen, dass die neuen Inhalte, die erstellt werden, mit den neuesten Entwicklungs-Builds funktionieren, die getestet werden? Was ist, wenn es Breaking Changes gibt, die nicht durch die Testinhalte abgedeckt sind, die in der Qualitätssicherung zu Testzwecken generiert werden? Diese Lücken werden erst bemerkt, wenn der neueste Build in die Produktion geschoben wird!
Was ist die Lösung? Migrieren Sie ganz einfach die eigentlichen Produktionsinhalte in die QA-Umgebung!
Das Migrieren dieser Inhalte ist jedoch nicht trivial. Es gibt ein paar Optionen (einige werden in späteren Beiträgen behandelt). Eine Methode besteht darin, Migrationen mit dem Befehlszeilentool VLT durchzuführen. Dieses Tool kann verwendet werden, um regelmäßige Synchronisierungen von PROD-Inhalten mit Ihren Umgebungen auf niedrigerer Ebene durchzuführen (z. B. jeden Sonntag um 2 Uhr morgens) oder bei Bedarf (direkt vor Beginn der Tests). Sie haben auch die Kontrolle darüber, welche Inhalte von PROD nach DEV/QA verschoben werden, und müssen nicht das gesamte Content-Repository senden, sondern nur eine Teilmenge oder einen gezielten Content-Baum (Beispiel: /content/en_us/site/test) .
Ich habe eine generische Version eines vlt rcp Skripts veröffentlicht, das ich bereits 2012 für die erste Migration von adobe.com zu schreiben begonnen habe. Ich benutze es seit diesem Upgrade/dieser Migration (wir sind von 5.3 auf > 5.5 umgestiegen und haben die allererste CQ 5.5-Site weltweit gestartet). Das Skript ist in unserem öffentlichen gitlab-Repo zu finden. Die Variablen innerhalb des Skripts und deren Verwendung sind in der entsprechenden README-Datei dokumentiert.
In der Regel führen wir dieses Skript entweder bei Bedarf (./vlt_rcp_content_sync.sh) aus oder planen es über einen Cron-Job, um es in regelmäßigen Abständen auszuführen. Dadurch sollte es so geplant werden, dass es am 1. und 3. Sonntag um 2 Uhr morgens läuft, zum Beispiel:
0 2 1-7,15-21 * * [ `date +\%u` = 7 ] && /
/vlt_rcp_content_sync.sh
Hank Thobe
Business Director bei Arbory Digital
Technischer Projektmanager und Business Director, der AEM-Experten leitet und unterstützt, um qualitativ hochwertige Dienstleistungen und Lösungen für verschiedene Branchen und Sektoren bereitzustellen.
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