CI/CD: Introducción — qué es, por qué importa y quién lo hace
📚 Serie: CI/CD y la IA: De la teoría a la práctica
Este artículo sienta las bases de la serie: qué es un pipeline de CI/CD (integración y entrega continua), por qué existe y qué perfiles técnicos lo diseñan. Si ya conoces estos fundamentos, puedes saltar directamente al siguiente artículo.
Índice
- Nota del autor
- ¿Por qué necesita una empresa un CI/CD?
- ¿Qué es la Platform Architecture?
- ¿Un “arquitecto” diseña el CI/CD?
- ¿Tengo que aplicarlo todo?
Nota del autor
Aunque he trabajado bastante con CI/CD (tanto montándolo como trabajando con ello), siempre me sorprende con novedades (tanto cosas realmente nuevas como existentes desde hace años que no conocía y son de gran valor), por ello desde hace tiempo que tenía ganas de ordenar mi conocimiento y mis ideas, pues son muchos puntos y tecnologías las que se aplican. Luego no todas sirven para todas las situaciones, ni para todas las empresas, pero quería diseñar una arquitectura lo más completa posible desde un punto de vista moderno, con vistas hacia el futuro con IA aplicada al CI/CD y como considero que se da un valor máximo tanto a la empresa como al equipo con el que trabajo.
¿Por qué necesita una empresa un CI/CD?
El objetivo de una empresa es tener al menos un producto que vender y, para el caso que nos ocupa, uno Software. Este producto forma parte del valor de la empresa y hay que cuidarlo y mantenerlo. Sin embargo, un software avanzado suele ser un problema para la empresa, ya que puede ser complejo de mantener y actualizar. Por eso es importante tener una buena arquitectura para que el producto sea escalable, flexible y seguro.
Normalmente un consumidor de software quiere acceder a él inmediatamente. Hoy día la manera más común de entregarlo es a través de Internet o alguna red (como una red privada). Las formas más conocidas de entrega son:
- Descarga directa (o por streaming): Se obtienen los binarios, instaladores, ZIPs, etc. (ejemplos: App Store, Steam, web de descargas).
- SaaS (Software as a Service): El usuario accede a la aplicación directamente desde su navegador (ejemplos: Office 365, GitHub).
A estas formas de entregar software es a lo que se conoce como entorno de Producción (production environment).
Este producto puede ser monstruosamente grande (ejemplo: un sistema operativo, una suite de herramientas de desarrollo, una aplicación empresarial, etc.), donde muchas personas técnicas y de negocio pueden estar involucradas en el desarrollo. Aunque haya mucha profesionalidad de cada uno de ellos, cuando hay tantas personas involucradas se necesita una forma de gestionar todo el ciclo de vida para que el producto software sea entregado de manera segura, confiable y con calidad.
¿Qué es la Platform Architecture?
La Platform Architecture (arquitectura de plataforma) es la arquitectura que diseña cómo se construye, valida, promueve, despliega y asegura el software en toda la organización. Es decir, es la arquitectura que se encarga de la infraestructura del ciclo de vida del software.
Dentro de esta arquitectura, el CI/CD (integración y entrega continua) es la parte central:
- CI (Continuous Integration o Integración Continua): Validar código, tests, lint, build.
- CD (Continuous Delivery/Deployment o Entrega/Despliegue Continuo): Empaquetar y desplegar modelos/servicios.
¿Un “arquitecto” diseña el CI/CD?
Digamos que hay varios “arquitectos” (aunque luego una persona puede tomar varios roles), pues el CI/CD es una disciplina transversal y su diseño no recae solo en una persona, sino en un ecosistema de roles.
Los roles más comunes que intervienen en el diseño de un pipeline, desde la estrategia hasta la ejecución, son:
-
El Estratega — Solution / Cloud Architect (él no escribe el pipeline, pero pone las reglas del juego): Decide qué servicios de nube se usan, el presupuesto máximo y cómo se garantiza que el sistema no se caiga. Si él dice que la base de datos debe estar cifrada, el CI/CD debe incluir obligatoriamente ese paso de validación.
-
El Constructor — DevOps / CI-CD Engineer (es quien realmente dibuja los diagramas y programa el flujo): Elige la herramienta (GitHub Actions, Jenkins), define las etapas (Build, Test, Deploy), gestiona los secretos (contraseñas/llaves) y optimiza la velocidad. Es quien asegura que, si usas Node.js v24, el entorno de construcción tenga exactamente esa versión.
-
El Guardián — DevSecOps Engineer (seguridad: el CI/CD debe tenerla integrada): Diseña las “puertas de calidad” de seguridad. Configura herramientas que escanean el código en busca de contraseñas expuestas o librerías vulnerables antes de que el código llegue siquiera a probarse.
-
El Facilitador — Platform Engineer: En lugar de diseñar un pipeline para cada equipo, diseña una “Plataforma de Autoservicio”. Su objetivo es que un desarrollador pueda darle a un botón y tener un CI/CD estándar ya configurado, sin tener que llamar a un experto cada vez.
-
El Validador — QA / Test Automation Engineer (un CI/CD sin pruebas es solo una forma rápida de romper cosas en producción): Diseña la estrategia de pruebas automatizadas. Decide qué pruebas corren en cada etapa (unitarias, de integración, etc.) y define bajo qué condiciones de fallo el pipeline debe detenerse por completo.
-
El Usuario Clave — Lead Developer (es el “cliente” del pipeline, por tanto, su opinión es vital en el diseño): Define la estrategia de branching (cómo se mezclan las ramas de código). El pipeline debe adaptarse a la forma en que los programadores trabajan, no al revés.
Resumen (me he tomado la libertad de llamar en este punto “arquitectos” a todos estos perfiles, ya que crearán la arquitectura del CI/CD de la empresa):
| Perfil | Responsabilidad en el CI/CD |
|---|---|
| Solution Architect | Define DÓNDE desplegamos y cuánto cuesta. |
| DevOps Engineer | Diseña CÓMO viaja el código de A a B. |
| DevSecOps | Asegura que el viaje es SEGURO. |
| QA Engineer | Asegura que el código que viaja FUNCIONA. |
| Platform Engineer | Crea la CARRETERA para que todos la usen igual. |
¿Tengo que aplicarlo todo?
No. Creo que conviene entender lo máximo posible a nivel teórico del CI/CD actual y luego adaptarlo, usarlo según necesidades o pensar en qué añadir en un futuro. Como verás, no es trivial, pues esto evoluciona constantemente y hay que estar bien actualizados, aunque es un buen punto por el que comenzar.
