Un cambio, de tu equipo al usuario

Imagina que un restaurante corrige el precio del reparto en su pantalla de pedidos. El programador guarda el archivo, ve que la página abre y dice: «Ya quedó». Pero la cocina sigue usando la versión anterior, caja calcula otro importe y el cliente recibe una cuenta distinta. El archivo cambió; el recorrido completo todavía no.

En software, una modificación necesita llegar a su destino con una explicación de qué cambió y una comprobación de su efecto. CI/CD organiza ese recorrido. No empieza con un servidor caro: empieza cuando puedes responder qué vas a entregar y cómo reconocerás que funciona.

Un cambio tiene más de un lugar donde fallar

1. Necesidad. Acordar la regla que debe cumplir.
2. Código. Implementar el cambio y registrar su versión.
3. Comprobación. Probar la regla y lo que ya funcionaba.
4. Entrega. Preparar archivos identificables.
5. Destino. Activar esos archivos con la configuración adecuada.
6. Uso. Confirmar versión y comportamiento.
7. Continuidad. Observar y poder recuperarse.

La automatización puede recorrer varios de estos pasos. El equipo sigue definiendo las reglas y las condiciones para avanzar. Si la regla del reparto está mal entendida, repetir el cálculo mil veces no la vuelve correcta.

El caso que seguiremos

Usaremos una aplicación ficticia: calcula un pedido en céntimos de sol. El envío cuesta S/ 5.00 si el subtotal es menor que S/ 100.00; desde S/ 100.00, inclusive, es gratuito. Tres productos de S/ 25.00 producen un total de S/ 80.00. Estos valores son reglas del ejercicio, no recomendaciones comerciales.

En esta historia distinguiremos el cálculo, sus comprobaciones, el paquete de entrega y la aplicación que utiliza el cliente. Los ejemplos no procesan pagos ni conservan datos. Su sencillez permite entender el recorrido sin esconderlo debajo de muchas tecnologías.