CI/CD: conceptos

La integración continuaconsiste en incorporar con frecuencia los cambios realizados por los desarrolladores a un repositorio compartido y comprobar automáticamente que esos cambios pueden integrarse correctamente.

Cuando se produce un evento determinado —por ejemplo, un pusho una pull request— puede iniciarse automáticamente un proceso que construya el proyecto y ejecute diferentes comprobaciones.

Cambio de código
↓
Commit
↓
Push
↓
Build
↓
Tests
↓
 Resultado

Etapas habituales

Obtención del código.El sistema recupera del repositorio la versión que debe validar.

Instalación de dependencias.Se preparan las bibliotecas, paquetes y herramientas necesarias para construir o ejecutar el proyecto.

Construcción (build).Cuando la tecnología lo requiere, el código se compila o empaqueta para comprobar que puede generarse correctamente.

Pruebas automatizadas.Se ejecutan pruebas para detectar errores introducidos por los cambios.

Análisis de calidad.El pipeline puede incorporar linters, análisis estático, comprobaciones de estilo o controles de seguridad.

Generación de artefactos.Si las comprobaciones finalizan correctamente, puede producirse un paquete, ejecutable, imagen de contenedor u otro elemento preparado para su distribución.

La idea fundamental de la integración continua es obtener feedback rápido. Si un cambio provoca un error, el equipo debería conocerlo lo antes posible.

Ejemplo de proceso

Ante un nuevo push, un proceso de CI podría realizar automáticamente:

1. Descargar el código
2. Instalar dependencias
3. Compilar el proyecto
4. Ejecutar las pruebas
5. Analizar la calidad del código
6. Generar el artefacto

Si alguna de las comprobaciones obligatorias falla, el pipeline puede detenerse y evitar que el cambio continúe hacia las siguientes fases.

Un pipelinerepresenta de forma automatizada la secuencia de tareas que debe superar un cambio de software.

Cada plataforma utiliza su propia terminología, pero es habitual encontrar conceptos equivalentes a los siguientes.

Workflow.Define un proceso automatizado completo.

Stage.Representa una fase lógica del proceso, como construcción, pruebas o despliegue.

Job.Agrupa tareas que se ejecutan como parte del pipeline.

Step.Representa una acción concreta dentro de un trabajo.

Trigger.Es el evento o condición que inicia el proceso automatizado.

PUSH
│
▼
BUILD
│
▼
TEST
│
▼
QUALITY CHECK
│
▼
PACKAGE
│
▼
DEPLOY

No todos los proyectos necesitan todas estas etapas. El pipeline debe adaptarse a las características, riesgos y necesidades del software.

Condiciones

Los pipelines pueden utilizar condiciones para decidir qué acciones deben ejecutarse según el evento, la rama o el estado del proceso.

Push a rama de desarrollo
↓
Build + Tests

Push a rama principal
↓
Build + Tests + Package

Versión etiquetada
↓
Build + Tests + Package + Deploy

Artefactos

Un artefactoes un resultado generado durante el pipeline que puede conservarse o utilizarse en etapas posteriores.

Algunos ejemplos son:

• paquetes compilados;
• archivos ejecutables;
• informes de pruebas;
• documentación generada;
• imágenes de contenedores.

Una práctica habitual consiste en generar una vez el artefacto y promover ese mismo artefacto entre entornos, evitando generar versiones diferentes del software para cada despliegue.

Variables y secretos

Los pipelines suelen necesitar información de configuración. Las variablespueden almacenar valores como nombres de entorno, rutas o parámetros de construcción.

Los datos sensibles —como contraseñas, tokens o claves— deben gestionarse mediante los mecanismos específicos de secretosproporcionados por la plataforma, evitando incorporarlos directamente al código fuente o a la configuración pública del pipeline.

Un pipeline puede trabajar con distintos entornos durante el ciclo de vida de una aplicación.

Desarrollo
→ Pruebas
→ Preproducción
→ Producción

Cada entorno cumple una finalidad diferente y puede disponer de sus propias variables, secretos, permisos y reglas de despliegue.

La separación entre entornos ayuda a evitar que una modificación todavía no validada llegue directamente a producción.

Un pipeline debería ser automatizado, reproducible y observable. Conviene mantener su configuración junto al código cuando la plataforma lo permita y ejecutar las comprobaciones más rápidas en las primeras etapas.

• Automatizar las tareas repetitivas y reducir los pasos manuales innecesarios.
• Ejecutar las comprobaciones rápidas antes que las más costosas.
• Detener el pipeline cuando falle una validación obligatoria.
• Mantener separados el código, la configuración y los secretos.
• Aplicar el principio de mínimo privilegio a las credenciales utilizadas por la automatización.
• Conservar los logs y resultados necesarios para diagnosticar errores.
• Promover el mismo artefacto validado entre los diferentes entornos siempre que sea posible.
• Disponer de una estrategia para recuperar una versión estable cuando un despliegue presente problemas.

El objetivo no es construir el pipeline con más etapas posible, sino disponer de un proceso sencillo, fiable y adecuado al proyecto.

Documentación oficial para ampliar los conceptos y consultar la sintaxis y posibilidades de automatización de GitHub Actions.

• Documentación de GitHub Actions