Continuous Delivery Web Services

[dirodriguezm]

Descripción

El flujo actual de CI/CD para web services está de la siguiente forma:

1. Build image, update app and chart versions, push image to GHCR
2. Build GH Pages, create chart release
3. Deploy chart to EKS

Este flujo funciona bien para staging, pero aún falta la parte de deployment a producción. Inicialmente estaba pensado para que se haga deploy a prod con la acción de release, pero luego observamos que es relativamente sencillo automatizar completamente el proceso, saltando el paso manual de release, si hacemos un deployment a staging y verificando de manera automática el deployment con un "smoke test".

La automatización del proceso sería de la siguiente forma:

Deploy Staging -> Test deployment -> (success) -> Deploy production
                                  -> (fail)    -> Rollback

Esto agiliza el proceso, pero deja un problema más por resolver. La versión que se usa para los deployment en prod generalmente proviene de los tags que se generan en un release. Al eliminar el paso de release manual necesitamos una forma de asignar correctamente una versión. Se decidió usar CalVer como estrategia de versionamiento.

---

Otro de los problemas que tiene el flujo CI/CD actual es que la actualización del repositorio Helm se realiza en forma "paralela" al flujo de deployment, en otro workflow de GH Actions.

El repositorio de Helm es actualizado mediante el action helm-releaser-action que a su vez gatilla la actualización de Github Pages para el repo de web-services. La action de github pages es relativamente rápida, por lo que usualmente, la pipeline de dagger que se encarga de actualizar el deployment en EKS ya contiene la versión más reciente. Pero esto no se asegura, ya que si la action de github pages tarda más de lo que demora la pipeline de dagger, entonces la versión que se despliega en EKS no va a ser la más reciente.

deployment action      github pages action
------------------------------------------

release chart --------> update github page

       |                        | (esta parte debería esperar)
       v                        v
deploy latest chart <------------
version

La alternativa a esto es realizar la actualización del repositorio Helm (github pages) manualmente dentro de la pipeline de dagger (o en su defecto, dentro del mismo workflow al menos) para que esté sincronizada la actualización del chart con su posterior deployment.

Tasks

Preview Give feedback

1. Usar CalVer para versionamiento (YY.MM.Micro-modifier) #180
   +0
   
2. Actualizar chart repo como parte de un único workflow (a.k.a. no usar chart-releaser-action) #192
   +0
   
3. Agregar paso de rollback en caso de fallo en staging #181
   +0
   
4. Agregar paso de deployment a production post success a staging #182
   +0
   
5. Fix mongo credentials #243
   +0
   
6. Alerts API Deployment #250
   +0