Consejos y trucos para un flujo de CI/CD escalable

Cuando planificas un proyecto, no siempre sabes lo grande que será al final. Por eso es fundamental seguir unas pautas que hagan el proceso de desarrollo lo más fluido posible. Una herramienta especialmente útil para ello es un flujo de integración y entrega continuas, o flujo de CI/CD.

Al principio de un proceso de desarrollo típico, antes de que el proyecto esté listo para publicarse, tu flujo de CI tiene más o menos este aspecto:

Durante la fase de desarrollo se van añadiendo pasos al proceso hasta que queda como en la imagen de abajo. Aun así, en algunos proyectos verás muchos más pasos. Imagen original.

En este artículo te muestro un flujo de CI/CD típico y te doy consejos para escalarlo en proyectos más grandes. Ten en cuenta que estas recomendaciones parten de la base de que tu infraestructura está montada con Docker y herramientas de orquestación como Kubernetes.

Define tu flujo de control de versiones

Todas las herramientas de CI modernas se apoyan en sistemas de control de versiones, así que, para mantener tu flujo de CI a un buen nivel, necesitas un flujo de control de versiones bien definido. Si buscas ideas, te recomiendo Git Flow o GitHub Flow. Elige uno y adapta tu pipeline a tus necesidades.

Recomendaciones:

• Ejecuta los tests en cada push, en cualquier rama. Así tus desarrolladores detectarán los bugs antes y la revisión de código irá más rápida.
• Define qué ramas vas a usar para lanzar el build de las imágenes de Docker y desplegarlas, como se ve en la imagen anterior.
• Si tus releases pasan por un proceso de aprobación manual complicado, usa tags para lanzar las releases a producción.

Especifica tus entornos

Una vez tengas un flujo de git definido, intégralo con la lógica de tus builds y adáptalo al número de entornos que tengas. Al principio, lo normal es que despliegues todo a producción después de probarlo en local. Más adelante, puede que decidas tener entornos de desarrollo, UAT y producción.

Ejemplo:

Solemos usar la rama master para lanzar el despliegue al entorno de desarrollo. Después fusionamos master en la rama release, lo que dispara un despliegue a UAT, donde dejamos que un grupo reducido de usuarios pruebe la nueva versión. Si todo funciona bien y el equipo de QA da el visto bueno a la release, creamos un tag desde la rama release, que lanza el despliegue a producción.

Configura notificaciones

Conviene seguir todos los procesos del flujo de CI a través del canal de notificaciones que prefieras. Nosotros usamos Slack en nuestros proyectos.

• Crea un canal de notificaciones del sistema y configúralo para recibir avisos de todos los procesos de CI y de infraestructura.
• Configura notificaciones de éxito o fallo y avisos cuando empiece un build.

Mantén simple la imagen de Docker

Una buena práctica es no pasar variables de entorno a la imagen de Docker. Todas las variables de entorno deberían pasarse con el comando docker run o a nivel de la herramienta de orquestación (por ejemplo, Kubernetes). Esto también te ayudará a mantener simples los archivos de configuración de CI.

Unifica tu pipeline

Hoy en día, cada vez más empresas usan arquitecturas de microservicios; un pipeline unificado te ayuda a sacarle partido, porque te permite desplegar y configurar la CI de nuevos microservicios mucho más rápido. En Drone CI o Travis CI hay un montón de variables de entorno de CI que puedes usar en los pasos del pipeline (las encontrarás en variables de entorno de Travis CI y variables de entorno de Drone CI). Estos son algunos ejemplos de uso:

• Para etiquetar una imagen de Docker, puedes concatenar la rama y el número de build. El resultado será algo como «master-6». También puedes usar la versión del tag de git. tags: "${DRONE_COMMIT_BRANCH}-${DRONE_BUILD_NUMBER}"
• Usa el nombre del repositorio para los despliegues en tus herramientas de orquestación. Este es un ejemplo de despliegue de Drone CI a un clúster de Kubernetes con variables de entorno.

Define una convención de nombres para las imágenes de Docker

Conviene definir una estrategia para nombrar las imágenes de Docker según las particularidades y la importancia de cada entorno. Por ejemplo, en los entornos de desarrollo y UAT, donde no necesitas poder hacer rollback, puedes usar el nombre de la rama como tag, de modo que cada build nuevo sobrescriba la imagen anterior. En producción es mejor etiquetar las imágenes con el número de versión de la release (v1.0.0), lo que hace tu registro más ordenado y legible al reducir su tamaño.

Usa el patrón builder

Si puedes compilar y construir algo a nivel de CI, puede ser útil hacerlo como paso adicional antes de incluirlo en la imagen final. Echa un vistazo a este vídeo para entenderlo mejor.

Migraciones de base de datos en un paso aparte

No hagas las migraciones dentro del Dockerfile; hazlas en un paso independiente. Los comandos adicionales, como la compilación de assets o las migraciones, deben ejecutarse en pasos separados, no al arrancar Docker. Procura también que tus imágenes de Docker arranquen y estén operativas en el menor tiempo posible.

Evita librerías privadas y submódulos

Cualquier dependencia adicional, como módulos privados de npm o submódulos, puede darte problemas al configurar la CI. Por ejemplo, si tienes un submódulo y tu CI solo tiene acceso por defecto a tus repositorios por http y con un token de autorización, la configuración de tu máquina local a través de git no funcionará. Tendrás que sobrescribir el submódulo, y no todas las herramientas de CI lo permiten.

Ejemplo de sobrescritura de submódulos en Drone CI

Te encontrarás con problemas parecidos si usas módulos privados de npm, porque necesitarás claves de acceso o tener los módulos ya descargados dentro de la imagen de Docker.

Conclusión

Cuando configures la CI de un proyecto nuevo, dedica un tiempo a pensar y definir las convenciones de nombres, las posibles vías de crecimiento y la unificación de los pasos de build. Así podrás desplegar nuevos servicios más rápido, usar estas prácticas como base para nuevos proyectos e incorporar antes a nuevas personas del equipo al funcionamiento del pipeline.