Doble hélice decorativa

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.

https://www.youtube.com/watch?v=Z2p2iY-b20M

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

¿Qué es AEM? ¿Para qué se utiliza AEM? Una explicación básica de AEM para principiantes - Arbory Digital Podcast Ep6
¿Qué es AEM? ¿Para qué se utiliza Adobe Experience Manager? Hemos intentado hacer una explicación básica de lo que es y hace AEM en 30 minutos o menos, y de alguna manera lo logramos, ¡a pesar de que el Departamento de Bomberos apareció aleatoriamente a los 19 minutos de la grabación del podcast!
Optimización del rendimiento del sitio en China para AEM y otras plataformas
¿Cuánto sabes sobre las herramientas que tienes a tu disposición para optimizar el rendimiento de tu sitio en China continental? E incluso si no tiene un sitio en chino, ¿debe preocuparse por el rendimiento en China? ¡TÚ SÍ!
¿Sigue existiendo AEM autoalojado? Revisado en el mundo actual de la entrega periférica
En la guerra actual entre la repatriación a la nube y los nuevos servicios de entrega perimetral ultrarrápidos, revisemos: ¿sigue existiendo el AEM autoalojado?