Como trabajar

Configuración

Configuración de repositorio:

Realizar la configuración descrita en code.

Crear manifiestos

Cada célula de trabajo (líder técnico) debe tener su propio repositorio de manifiestos.

El repositorio de manifiestos no es más que un repositorio en GitHub que contiene ramas para los ambientes QA y PROD de cada aplicación de nuestro dominio. Es recomendable utilizar un repositorio de manifiestos para cada namespace/proyecto, en donde se encuentren las ramas de manifiestos de todas las aplicaciones del mismo namespace.

Para crear un repositorio podemos utilizar el template que se encuentra en la organización de architecture-it.

Los manifiestos deben estar en la organización pertinente al equipo y no en architecture-it

Lar organizaciones disponibles son:

1. architecture-it
2. customer-experience
3. operations-innovation
4. corporate-solutions-gla
5. warehouse-andreani
6. infraestructure-services
7. administrative-solucions
8. data-office

para eso debemos seguir los siguientes pasos:

1. Entrar en la organización de architecture-it y crear un nuevo repositorio.

2. Seleccionar en la opción de repository template el template architecture-it/manifiestos-arquitectura.

3. No debemos marcar el check de Include all branches ya que solo necesitamos main.

4. Seleccionar en Owner la organización de destino.

5. Elegir un nombre acorde al repositorio.

Branches de manifiesto

La estrategia de despliegue necesita que para el ambiente de QA y PROD se cuente con la configuración pertinente. Por lo que debemos generar para cada aplicación dos branches.

La nomenclatura de la branch se correlacionará con el proyecto y nombre de la aplicación en OCP por lo que debemos tener criterio a la hora de nombrarlo.

la nomenclatura de nombrado es: {project}-{appname}-{qa | prod}

Ejemplo:

integra-publicador-qa

integra-publicador-prod

notificaciones-sms-api-qa

notificaciones-sms-api-prod

Notas importantes: - La longitud total de la rama más larga (PROD) no debe superar los 53 caracteres, por lo que es recomendable no utilizar nombres de aplicación (ni de namespace) demasiado largo. - Solo se pueden utilizar letras en minúscula y guiones para el nombre de la app.

Configuración de despligue.

Debemos realizar la configuración correspondiente para cada ambiente utilizando el value.yaml como se explica en manifiesto.

Solicitud de creación de pipeline

Se debe solicitar la creación del pipeline como se especifica en ticket

Despliegue

Para hacer un despliegue se debe realizar un cambio en la rama cicd del repositorio de código o en la rama del manifiesto. Esto desencadena el Pipeline de Azure DevOps Si el commit se realiza sobre una de las ramas de manifiestos, solo desencadenará un despliegue de la última imagen en el ambiente correspondiente a la rama. Si se realiza en la rama cicd del repositorio de código desencadenará el pipeline completo, construirá una nueva imagen y la desplegará en ambos ambientes una vez cumplidas las aprobaciones requeridas.

Restricciones de seguridad:

1. Se debe agregar reglas a la rama de cicd para que no sea posible realizar un push en esa rama sin antes hacer un PullRequest (PR).

2. Se debe configurar él workflow de CI para que se ejecute en cada PR a la rama cicd.

3. Los manifiestos deben ser exclusivamente manejado por los Líderes Técnicos

Environment variables

Debemos cargar siempre las environment variables dentro de los manifiestos, esto es más apuntando a los proyectos en NET que utilizan el appsettings.yml ya que el no hacerlo significará realizar todo el proceso de despliegue y upgrade de versión por un cambio de configuración. Si se modifica algo de los manifiestos el proceso de despliegue solo refresca el despliegue en OCP.