Nueva función: Uso de repositorios privados de Git con AEM as a Cloud Service

En AEM as a Cloud Service o en el producto AEM 6.5 alojado de Adobe (AEM Managed Services o "AMS"), durante mucho tiempo ha existido el requisito de que la implementación de cualquier código en cualquier entorno alojado en Adobe requiere primero obtener ese código en el repositorio Git alojado de Adobe.

El razonamiento es bastante simple: el marco de CI/CD de Cloud Manager de Adobe tiene que ejecutar una serie de comprobaciones en el código, luego ejecutar compilaciones en ese código desde su servicio de compilación en contenedores y luego también poder etiquetar versiones en el repositorio una vez que se completen las implementaciones de producción.

Privado frente a Adobe Repos - Contexto

Durante mucho tiempo ha habido una serie de complejidades y limitaciones con las que los clientes de AEMaaCS y AMS han tenido que lidiar, al usar esto, lo que lo ha convertido en una característica muy deseable y buscada para poder usar un repositorio de Git privado con AEM alojado en la nube, como:

Mantenimiento de dos repositorios

El repositorio de git de Adobe es solo un repositorio de implementación . No está pensado para ser el Git principal con el que trabaje para desarrollar su sitio AEM. No tiene ningún Acuerdo de Nivel de Servicio para disponibilidad o copias de seguridad. Por lo tanto, al ejecutar el proyecto, debe mantener su propio repositorio interno, así como el repositorio de Adobe para la implementación, y luego administrar la sincronización entre esos repositorios.

El repositorio de Adobe carece de funciones como las solicitudes de incorporación de cambios

Hay una serie de funciones de las que carece la implementación de Git de Adobe, lo que hace que ciertas canalizaciones en fase inicial sean un poco difíciles. Por ejemplo, el Git de Adobe no tiene subprocesos ni solicitudes de incorporación de cambios.

Esto se convierte en un problema cuando la canalización de CI/CD de Adobe es el único lugar donde realmente se puede ejecutar el conjunto completo de pruebas de automatización de compilación que mostrarían cosas como violaciones de seguridad, degradación del rendimiento, violaciones de las reglas de Sonarqube, etc.
Por lo tanto, si tienes una nueva función en la que quieres abrir un PR en eso, digamos, que crees que hace que el sitio sea más rápido, tienes que abrir ese PR en tu propio Github, tu lead tiene que "aprobarlo" incluso si no sabemos si pasa las comprobaciones de compilación, luego lo confirmas a través del git de Adobe, momento en el que tal vez FALLE y entonces tu PR fue algo inútil.

Seguridad y gestión de usuarios

No hay controles detallados en el Git de Adobe para controlar la administración y el acceso de los usuarios. Por lo tanto, termina necesitando implementar su propia seguridad en su propio git, luego confíe en la automatización de compilación que cree por su parte para intentar limitar qué ramas, confirmaciones, cambios, etc. llegan al git de Adobe. Se puede hacer, pero solo agrega un nivel propenso a errores de complejidad de Rube Goldberg.

Repositorios privados de Git para AEM as a Cloud Service y AMS: ¿Qué lanzó Adobe?

Para ser claros, esta es una primera versión general de esta función (anunciada en Adobe Summit este año y en versión preliminar con varios clientes durante el año pasado). Como tal, no es compatible con TODAS las funciones que desee y hay una serie de limitaciones que debe tener en cuenta. Pero es un gran paso adelante para aquellos que viven en este mundo, así que trataré de esbozar algunas cosas que puede y no puede hacer.

Lo que ahora puede hacer:

Lo que aún no puedes hacer:

Perfeccionamiento de la canalización de AEM

Si esto parece algo que quizás desee probar usted mismo, la documentación se encuentra aquí sobre cómo comenzar con Github autoadministrado en AEM.

Sin embargo, si no está seguro de si esto es algo que desea implementar o no, o tiene otras preocupaciones de implementación o CI/CD de las que desea hablar, ¡estaré encantado de hablar!

Además, para obtener más información sobre el tema (si le gustan los podcasts), nuestro CTO Dwayne Hale y yo discutimos aquí los méritos y deméritos de ejecutar equipos AEM en la nube frente a los autoalojados.

Tad Reeves

Arquitecto Principal en Arbory Digital

AEM Architect & DevOps guy con 14 años de experiencia en AEM/CQ y 25+ años en infraestructura de sistemas. Ha estado practicando ciclismo de montaña por más tiempo de lo que ha estado haciendo administración de sistemas, y aunque es originario de Maine, tiene su hogar en las montañas del noroeste de Georgia.

Contacta con Tad en Linkedin

¿Te gustó lo que escuchaste? ¿Tiene preguntas sobre lo que es adecuado para usted? ¡Nos encantaría hablar! Contáctenos

Episodios de podcast y publicaciones de blog

category
AEM Technical Help, AEM News, Arbory Digital News, Customer Stories, Podcasts
tags
aem cloud
number of rows
1