# Funciona en mi máquina, así que envía la máquina Curso exprés sobre CI/CD y contenedores. 21 conceptos — deploy, works on my machine, continuous integration, shift left, continuous delivery y deployment, artifact, pipeline, fail fast, container, Docker, image, Kubernetes, desired state, rolling update, rollback, canary, blue-green, infrastructure as code — cada uno con su nombre en inglés, un diagrama, una ficha y un ejemplo. Al final: una chuleta con todos los conceptos y cómo se conectan. - **Author:** Fedor Chishchin - **Level:** intermediate - **Reading time:** ~35 minutos de lectura - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/es/learn/cicd-express --- ## 1. El problema del deploy Escribir código es solo la mitad del trabajo; ponerlo de forma segura frente a los usuarios es la otra mitad. Durante mucho tiempo esa segunda mitad fue lenta, manual y aterradora — y entender por qué es la clave de todo lo que la arregla. ### Mapa del curso: 21 conceptos en siete grupos > Un mapa de metro: primero ves las líneas completas, luego recorres estación por estación. El curso sigue un cambio en su camino del portátil al usuario. Primero el **problema**: por qué los deploys manuales dan miedo. Luego **CI** (revisar cada cambio), **CD** (llevarlo a los usuarios), el **pipeline** (la máquina que hace todo eso), los **contenedores** (el mismo entorno en todas partes), la **orchestration** (muchos contenedores en muchos servidores) y los **deploys seguros** (cómo publicar de modo que puedas deshacerlo). _Diagram: Siete grupos de conceptos — los capítulos los siguen._ ### Cómo leer cada concepto > Un pasaporte: los mismos campos para todos, así que es fácil compararlos. Cada concepto de abajo tiene la misma forma: su **nombre en inglés** (el término que encontrarás en la documentación y en el trabajo), una imagen de la vida cotidiana, un **diagrama** y una **ficha** con campos — el problema o «qué es», la idea, un ejemplo, el coste o la pega, y los conceptos relacionados. El curso tiene una gran idea: **enviar debería ser aburrido, automatizado e idéntico en todas partes.** ### Deploy — y por qué hacerlo a mano da miedo > Un cirujano realizando una operación delicada a mano, de memoria, a medianoche, cansado — un solo resbalón y el paciente cae. Eso es un deploy manual a producción. Un **deploy** no es más que «poner en marcha la nueva versión». La vieja forma era un humano siguiendo pasos a mano: copiar archivos a un servidor, ejecutar algunos comandos, cruzar los dedos. Es lento, propenso a errores y tan arriesgado que los equipos hacen deploy rara vez — lo que hace que cada release sea enorme, lo que lo hace aún más arriesgado. Hecho a mano, se convierte en el momento más estresante de la semana. Todo el campo de CI/CD existe para volver aburrido ese momento. _Diagram: El círculo vicioso: hacer deploy a mano da miedo → los equipos hacen deploy rara vez → los releases se vuelven enormes → da aún más miedo._ #### Deploy (release, rollout) - **Qué es:** Poner en marcha una nueva versión de la app para los usuarios. - **Ejemplo:** Un deploy manual: entrar por SSH al servidor, copiar los archivos, reiniciar el proceso — y esperar lo mejor. - **Pega:** A mano es lento y arriesgado — así que se hace rara vez, y cada release se vuelve enorme. - **Relaciones:** Lo automatizan **Continuous Delivery** y el **Pipeline**; lo hacen seguro **Rollback**, **Canary** y **Blue-green**. ### Works on my machine — la trampa clásica > Una receta que sale perfecta en tu cocina y falla en la de otra persona — distinto horno, distinta harina, distinta altitud. La receta no era la historia completa. El código que funciona bien en el portátil de un desarrollador a menudo se rompe en producción, porque los dos **entornos** difieren — distintas versiones, ajustes, librerías, sistema operativo. **«Funciona en mi máquina»** es el remate de toda una clase de bugs causados por estas brechas. El portátil y el servidor no son el mismo lugar, así que «funcionó donde lo construí» no garantiza nada sobre dónde se ejecuta. _Diagram: El mismo código, otro entorno: otra versión del runtime, otras librerías, otro SO — y un bug que solo existe en producción._ #### Works on my machine (environment drift, deriva del entorno) - **Qué es:** Un bug que aparece solo en otro entorno, porque los entornos difieren. - **Ejemplo:** Node 20 en el portátil, Node 16 en el servidor — el código que usa una función nueva del lenguaje falla solo en producción. - **Pega:** El código no es toda la historia: también importan las versiones, los ajustes, las librerías y el SO que lo rodea. - **Relaciones:** Lo cura el **Container** — la app lleva su entorno consigo — y el **Artifact** — pruebas lo que envías. ### Boring releases — enviar debería ser aburrido > Un ascensor en el que entras sin pensarlo, cien veces al día — porque está automatizado, probado y es seguro. Nunca usarías uno que necesitara un procedimiento manual y nervioso en cada viaje. El objetivo de todo en este curso es volver el envío **aburrido**: tan automatizado, probado y repetible que haces releases de cambios pequeños muchas veces al día sin drama. De forma contraintuitiva, hacer deploy _más_ a menudo es _más_ seguro — cada release es diminuto (**small batches**), así que si algo se rompe, la causa es obvia y el arreglo es pequeño. Los releases raros, gigantes y manuales son los peligrosos. Aburrido es el mayor cumplido que un deploy puede ganar. _Diagram: Arriba: dos releases enormes y aterradores. Abajo: diez pequeños — si uno se rompe, está claro cuál._ #### Boring releases (small batches, releases pequeños y frecuentes) - **Problema:** Un release grande son cientos de cambios, y cuando se rompe nadie sabe cuál lo causó. - **Idea:** Enviar cambios pequeños a menudo — de forma automática y sin drama. - **Ejemplo:** En lugar de un release al mes — varios releases diminutos al día, cada uno de un par de líneas. - **Coste:** Hace falta automatización: nadie puede hacer deploy tan a menudo a mano. - **Relaciones:** Solo es posible con **CI**, **Continuous Delivery** y **Rollback**. > **La pregunta de encuadre:** «¿Enviar un cambio aquí es un acto tranquilo, automatizado y cotidiano — o un evento lento, manual y angustiante que evito hacer demasiado a menudo?» > Los deploys manuales son lentos, arriesgados y raros — lo que los hace más arriesgados. El objetivo es lo contrario: un envío tan automatizado y pequeño que sea aburrido, hecho muchas veces al día. ## 2. Continuous Integration La primera mitad de CI/CD trata de detectar problemas en el instante en que aparecen, construyendo y probando automáticamente cada cambio a medida que llega — para que el código compartido siempre funcione. ### Continuous Integration (CI) — cada cambio construido y probado > Un corrector ortográfico que se ejecuta en cada frase mientras escribes, señalando el error de inmediato — no un revisor que encuentra cien errores un mes después, cuando todo está enredado. **Continuous integration (CI)** significa que cada vez que alguien propone un cambio, un sistema automatizado construye el proyecto y ejecuta los tests sobre él — en minutos, sin que lo toque ninguna mano humana. Si el cambio rompe el build o falla un test, lo sabes al instante, mientras es pequeño y está fresco en tu mente. CI es un guardia siempre activo que revisa cada contribución antes de que pueda causar problemas. _Diagram: Cada commit va al servidor de CI: build y tests. Pasa — se puede fusionar; falla — el autor lo sabe en minutos._ #### Continuous Integration (CI) - **Problema:** Un cambio roto se nota semanas después, cuando ya está enredado con todo lo demás. - **Idea:** Construir y probar automáticamente cada cambio en el momento en que llega. - **Ejemplo:** En cada pull request un servicio de CI (GitHub Actions, por ejemplo) ejecuta el build y los tests y le pone una marca verde o roja. - **Coste:** Necesitas buenos tests automatizados — CI solo comprueba lo que comprueban tus tests. - **Relaciones:** Detecta pronto (**Shift left**), mantiene una **Green main branch**; es la primera etapa de cualquier **Pipeline**. ### Shift left — detecta la rotura mientras es pequeña > Notar un solo ladrillo colocado torcido es fácil de arreglar; descubrirlo solo después de construir tres pisos encima es un desastre. Temprano es barato; tarde es caro. El valor de CI está en el momento. Un bug detectado en el instante en que se introduce es trivial de arreglar — sabes exactamente qué cambió. El mismo bug descubierto semanas después, enterrado bajo todo lo construido encima, puede llevar días desenredar. Esta es la idea de **shift left** — mover el descubrimiento de los problemas hacia la izquierda en la línea del tiempo, más cerca del momento del cambio. CI mueve el descubrimiento de la rotura de «mucho más tarde, mezclado con todo» a «ahora mismo, en aislamiento». _Diagram: Cuanto más tarde se encuentra un bug, más cuesta arreglarlo. CI desplaza el descubrimiento a la izquierda — al propio commit._ #### Shift left (catch it early, detéctalo pronto) - **Qué es:** Encontrar los problemas lo antes posible — cerca del momento del cambio. - **Ejemplo:** Un test falla 3 minutos después del commit — sabes qué línea lo causó. El mismo bug en producción un mes después — días de investigación. - **Pega:** Las comprobaciones deben ser rápidas: si CI tarda una hora, la gente deja de esperarlo. - **Relaciones:** El valor central de **CI**; el mismo espíritu que **Fail fast**. ### Green main branch — mantén main siempre funcionando > Una cocina compartida donde todos deben limpiar antes de irse — así siempre se puede usar para la siguiente persona, nunca es un montón que otro tiene que ordenar primero. El propósito más profundo de CI es mantener la **main branch** — la versión compartida y de confianza — siempre en estado funcional. Un cambio solo entra en main si compila y pasa los tests, así que main nunca se convierte en un desastre roto que bloquea a todo el equipo. Esto es lo que hace posible enviar con frecuencia y confianza: cuando main siempre funciona, puedes hacer un release desde ella en cualquier momento. _Diagram: La rama A pasó CI y se fusionó en main. La rama B falló CI — se queda fuera hasta que se arregle._ #### Green main branch (main always green, main siempre en verde) - **Problema:** Una main rota bloquea a todo el equipo y detiene cualquier release. - **Idea:** Solo lo que compiló y pasó los tests entra en main. - **Ejemplo:** Una regla del repositorio: el botón «Merge» queda desactivado hasta que las comprobaciones de CI estén en verde. - **Coste:** A veces esperas a CI y arreglas tests antes de fusionar. - **Relaciones:** Lo hace cumplir **CI**; permite a **Continuous Delivery** hacer release desde main en cualquier momento. > **La pregunta de CI:** «¿Se construye y se prueba automáticamente cada cambio antes de unirse al código compartido — para detectar la rotura de inmediato y que main siempre funcione?» > Continuous integration construye y prueba cada cambio en el momento en que llega, detectando la rotura mientras es pequeña y manteniendo la main branch siempre en estado funcional. ## 3. Continuous Delivery Si CI se asegura de que cada cambio sea bueno, CD automatiza llevar ese buen cambio a los usuarios — convirtiendo el release de un ritual manual en un botón, o en ningún botón. ### Continuous Delivery (CD) — automatiza el release, no solo las pruebas > Una línea de fábrica que no se detiene en el control de calidad, sino que lleva el producto aprobado hasta el muelle de carga y al camión — nadie cargando cajas a mano. **Continuous delivery (CD)** amplía CI: después de que un cambio pasa todas las comprobaciones automáticas, el sistema también lo prepara automáticamente para el release y puede enviarlo a producción. Los pasos manuales y propensos a errores del deploy se convierten en código que se ejecuta igual cada vez. **CI demuestra que el cambio es bueno; CD lleva ese buen cambio a los usuarios** — sin que un humano teclee comandos con cuidado en un servidor a medianoche. _Diagram: CI se encarga de «el cambio es bueno», CD de «está delante de los usuarios». Todo el camino está automatizado._ #### Continuous Delivery (CD) - **Problema:** El cambio está demostrado como bueno, pero sigue publicándose a mano — despacio, con errores. - **Idea:** Los pasos del release son código; cada buen cambio queda automáticamente listo para enviarse. - **Ejemplo:** Tras una ejecución verde de CI, un script construye el paquete, lo guarda y lo despliega en producción con un botón. - **Coste:** Describes todo el camino del release como código una vez, y tienes que confiar en tus tests automatizados. - **Relaciones:** Se apoya en **CI**; envía el **Artifact**; se ejecuta dentro del **Pipeline**. ### Continuous Delivery vs Continuous Deployment — con botón o sin botón > Un paquete sellado, con su dirección y esperando junto a la puerta, frente a otro que ya se ha entregado al mensajero — ambos listos para salir, pero uno espera a que tú des la orden. Hay una diferencia sutil. **Continuous delivery** significa que cada buen cambio queda automáticamente _listo_ para hacer deploy, pero un humano pulsa el botón para publicarlo. **Continuous deployment** va más allá: cada cambio que pasa se publica en producción automáticamente, sin ningún botón. Ambos son «CD»; la diferencia es si una persona aprueba el último paso. _Diagram: Arriba — delivery: un humano aprueba el último paso. Abajo — deployment: pasó las comprobaciones, directo a producción._ #### Continuous Delivery vs Continuous Deployment (las dos D de CD) - **Qué es:** Delivery — listo para publicar, un humano pulsa el botón. Deployment — se publica solo, sin botón. - **Ejemplo:** Un banco publica al pulsar un botón tras la aprobación (delivery); un servicio web envía cada commit en verde por sí solo (deployment). - **Pega:** La elección depende de cuánto confíes en tus comprobaciones automáticas. - **Relaciones:** Ambos son tipos de **Continuous Delivery**; sin botón, **Canary** y **Rollback** importan aún más. ### Artifact — lo que envías > Una caja sellada y etiquetada, empaquetada una vez y luego enviada, almacenada y entregada como una sola unidad — no vuelta a montar con piezas sueltas en cada parada. El pipeline produce un **artifact** — un único paquete de tu aplicación, construido, versionado y listo para ejecutarse. Lo construyes una vez y ese mismo artifact pasa por testing, staging y producción, así que lo que probaste es exactamente lo que envías. Si reconstruyeras en cada etapa, podrían colarse diferencias sutiles. **Build once, deploy everywhere** — un artifact, construido una vez, desplegado en todas partes — elimina toda una clase de sorpresas del tipo «pero pasó en testing». _Diagram: Construido una vez — la versión v1.4.2 va a test, a staging y a producción. Sin reconstrucciones por el camino._ #### Artifact (build once, deploy everywhere, construir una vez y desplegar en todas partes) - **Qué es:** Un paquete de la app construido y versionado, listo para ejecutarse. - **Ejemplo:** `app v1.4.2` — el mismo paquete pasa por test, staging y producción. - **Pega:** Si reconstruyes en cada etapa, lo que llega a producción ya no es lo que probaste. - **Relaciones:** El resultado del **Pipeline**; en los contenedores el artifact es la **Image**; hace posible el **Rollback**. > **La pregunta de CD:** «Una vez demostrado que un cambio es bueno, ¿fluye a los usuarios automáticamente como un único artifact probado — o alguien sigue construyéndolo y desplegándolo a mano?» > Continuous delivery automatiza el release de cada buen cambio como un único artifact construido — ya sea que un humano pulse el botón final (delivery) o se envíe solo (deployment). ## 4. El pipeline CI y CD los ejecuta un pipeline: una cadena de montaje automatizada por la que viaja un cambio, del commit a producción, deteniéndose si algo sale mal por el camino. ### Pipeline — una cadena de montaje automatizada > La línea de una fábrica de coches: el chasis pasa por soldadura, pintura e inspección en orden, cada estación hace su trabajo antes de pasarlo — ningún paso omitido, nadie cargando a mano. Un **pipeline** es la secuencia de **etapas** automatizadas por las que pasa un cambio camino de producción — normalmente **build**, luego **test**, luego **deploy**. Un commit entra por un extremo y, si todo va bien, por el otro sale un release en vivo, sin pasos humanos en medio. El pipeline es la máquina concreta que hace real CI/CD: ahí vive de verdad el «automatiza todo el camino». _Diagram: Commit → build → test → deploy → release en vivo. Todo lo que está dentro del marco lo hace la máquina, no una persona._ #### Pipeline (CI/CD pipeline) - **Qué es:** Una secuencia definida de etapas automatizadas del commit a producción. - **Ejemplo:** Un archivo de configuración en el repositorio describe tres etapas: `build` → `test` → `deploy`; el servicio de CI las ejecuta en cada commit. - **Pega:** El pipeline también es código: necesita mantenimiento, y un pipeline lento frena a todo el equipo. - **Relaciones:** El hogar de **CI** y **Continuous Delivery**; protegido por **Fail fast**; produce el **Artifact**. ### Fail fast — rojo es parar, verde es seguir > Una cadena de montaje con un cordón que cualquiera puede tirar para detenerlo todo en el instante en que aparece un defecto — y un semáforo en la línea: en verde el trabajo sigue; en rojo todo espera hasta que se despeja el problema. Un buen pipeline está hecho para **fail fast**: si el build se rompe o un test falla en cualquier etapa, el pipeline se detiene y el cambio no avanza más. Los pipelines hablan en **verde** (pasó) y **rojo** (falló). Esta señal simple sustituye el juicio manual y angustiado por una puerta inequívoca. La regla del equipo es fácil: **nunca construyas sobre rojo, nunca envíes en rojo**. _Diagram: Los tests se pusieron en rojo — la línea se detuvo: deploy nunca se ejecuta, producción queda intacta. Verde sigue, rojo para._ #### Fail fast (red / green, rojo / verde) - **Problema:** Un cambio roto puede llegar rodando hasta producción si la línea no se detiene. - **Idea:** Cualquier etapa en rojo detiene el pipeline de inmediato; solo el verde avanza. - **Ejemplo:** Fallaron dos tests — la etapa `deploy` ni siquiera arranca; el equipo arregla primero. - **Coste:** Los tests inestables detienen la línea sin motivo — hay que arreglarlos. - **Relaciones:** La propiedad de seguridad del **Pipeline**; el mismo espíritu que **Shift left**. > **La pregunta del pipeline:** «¿Viaja cada cambio por la misma línea automatizada de build-test-deploy, deteniéndose en seco en cuanto cualquier etapa se pone en rojo — para que nada roto pueda llegar a producción?» > El pipeline es la cadena de montaje automatizada del commit a producción — build, test, deploy — que hace fail fast y se detiene en rojo, para que ningún cambio roto se cuele. ## 5. Contenedores La otra mitad de la historia resuelve «funciona en mi máquina» directamente: empaquetar la app con todo lo que necesita en una sola unidad que funciona igual en todas partes. Esa unidad es un contenedor. ### Container — la app junto con su entorno > El traje de un astronauta, que lleva su propio aire, temperatura y presión — así la persona trabaja igual en la estación o en el espacio abierto, llevando su entorno consigo. Un **container** agrupa tu aplicación con todo lo que necesita para ejecutarse — el código, las librerías, los ajustes, las versiones correctas — en una unidad autónoma. Como lleva su propio entorno, funciona igual dondequiera que lo pongas: tu portátil, un servidor de pruebas, producción. El contenedor no depende de lo que esté instalado en el host, así que las brechas que causan «funciona en mi máquina» simplemente se cierran. _Diagram: Dentro del contenedor: código, librerías, ajustes y el runtime. Por eso funciona igual en un portátil y en producción._ #### Container - **Qué es:** La app más todo su entorno, empaquetados en una unidad autónoma. - **Ejemplo:** Un contenedor con tu API y Node 20 dentro funciona igual en un portátil con macOS y en un servidor Linux. - **Pega:** Un contenedor arregla el entorno, no los bugs de tu código — sigues necesitando tests. - **Relaciones:** Cura **Works on my machine**; se arranca desde una **Image**; se gestiona a escala con **Kubernetes**. ### Docker — el contenedor de carga que le dio nombre > El contenedor de acero para transporte: cualquier puerto, barco o camión lo maneja igual porque la caja es estándar, sea lo que sea lo que lleva dentro. La carga del mundo se mueve con esa sola idea. El nombre es la metáfora. Antes de los contenedores de carga estándar, la mercancía se cargaba pieza a pieza, de forma torpe; la caja estándar permitió que cualquier grúa y cualquier barco manejaran cualquier carga de forma idéntica. Los **contenedores** de software hacen lo mismo con las aplicaciones: una unidad estándar que cualquier sistema compatible puede ejecutar sin importarle lo que hay dentro. **Docker** es la herramienta que lo hizo popular. Estandarizar la caja es lo que hace que toda la cadena logística — tu pipeline — funcione sin fricción. _Diagram: Igual que cualquier grúa, barco y camión maneja la caja estándar, cualquier portátil, runner de CI y nube ejecuta una image de Docker._ #### Docker - **Qué es:** La herramienta que popularizó los contenedores: los construye y los ejecuta. - **Ejemplo:** `docker build` construye una image a partir de un Dockerfile; `docker run` arranca un contenedor a partir de ella. - **Pega:** El estándar es la caja, no el contenido: lo de dentro sigue teniendo que ser una app que funcione. - **Relaciones:** Crea **Container**s e **Image**s; **Kubernetes** los ejecuta. ### Image vs Container — receta y plato > Una receta frente a la comida cocinada con ella: una es el conjunto fijo de instrucciones, la otra es una instancia concreta de la que puedes hacer muchas, todas idénticas. Dos palabras se confunden. Una **image** es el plano empaquetado y congelado — el artifact construido que contiene tu app y su entorno, guardado en un almacén (un **registry**). Un **container** es una instancia en ejecución arrancada desde esa image. Una image puede lanzar muchos contenedores idénticos, igual que una receta hace muchos platos idénticos. Construyes la image una vez en tu pipeline y luego ejecutas tantos contenedores como necesites — y todos son iguales. _Diagram: Dockerfile → build → image (guardada en un registry) → run → tantos contenedores idénticos en ejecución como necesites._ #### Image vs Container (receta y plato) - **Qué es:** Image — el plano congelado (la receta). Container — una instancia en ejecución (el plato). - **Ejemplo:** Una image `api:1.4.2` — cinco contenedores idénticos en ejecución. - **Pega:** Cambiar cosas dentro de un contenedor en ejecución no sirve — cambia la image y reconstruye. - **Relaciones:** La image es el **Artifact** de los contenedores; **Kubernetes** mantiene las copias en marcha. > **La pregunta del contenedor:** «¿Lleva esta app todo su entorno en un contenedor, de modo que funciona igual en mi portátil y en producción — en lugar de depender de lo que casualmente esté instalado?» > Un contenedor empaqueta una app con todo lo que necesita, así que funciona igual en todas partes. Construyes una image una vez (la receta) y ejecutas contenedores idénticos a partir de ella (el plato). ## 6. Orchestration Ejecutar un contenedor es fácil. Ejecutar cientos en muchas máquinas — mantenerlos sanos, escalarlos, actualizarlos sin caídas — necesita un director de orquesta. Eso es la orchestration. ### Orchestration / Kubernetes — el director de orquesta de los contenedores > Un controlador de tráfico aéreo que gestiona un cielo lleno de aviones — decide cuál aterriza dónde, reencamina ante los problemas, mantiene seguras y coordinadas cientos de piezas en movimiento. Cuando tienes muchos contenedores repartidos por una flota de servidores, algo debe decidir dónde se ejecuta cada uno, reiniciar los que mueren y equilibrar la carga. Eso es la **orchestration**, y la herramienta dominante es **Kubernetes**. Le dices el estado deseado — «ejecuta cinco copias de este servicio» — y trabaja sin parar para que la realidad coincida: colocando contenedores, vigilándolos y corrigiendo la deriva. _Diagram: Tú dices «5 copias» — Kubernetes las reparte solo entre los servidores (nodos), las vigila y las reinicia._ #### Kubernetes (K8s, container orchestrator, orquestador de contenedores) - **Problema:** Nadie puede seguir a mano la pista de cientos de contenedores en muchos servidores. - **Idea:** El orquestador decide dónde se ejecuta cada contenedor, reinicia los muertos y equilibra la carga. - **Ejemplo:** Describes un servicio con `replicas: 5` en YAML — Kubernetes mantiene cinco copias en distintos servidores. - **Coste:** Un sistema complejo con su propio lenguaje; a menudo excesivo para un solo servicio pequeño. - **Relaciones:** Ejecuta **Container**s desde una **Image**; mantiene el **Desired state**; realiza el **Rolling update**. ### Desired state — autorreparación y autoescalado > Un termostato que fijas a una temperatura objetivo: percibe la habitación todo el rato y se ajusta solo, sin que lo toques de nuevo. Tú declaras la meta; él la mantiene. La orchestration es **declarativa**: describes la meta, no los pasos. Di «mantén siempre cinco copias sanas en marcha», y si una se cae, el sistema arranca una sustituta automáticamente — **self-healing**. Si el tráfico se dispara, puede añadir más copias y quitarlas cuando baja la demanda — **auto-scaling**. Dejas de cuidar servidores a mano y en su lugar declaras lo que quieres. Ese paso de hacer a declarar es el corazón de todo. _Diagram: Un bucle sin fin: comparar lo deseado con lo real, corregir la deriva. Una copia se cayó — arranca una nueva._ #### Desired state (declarative, self-healing, auto-scaling, declarativo, autorreparación, autoescalado) - **Qué es:** Declaras la meta («5 copias sanas»); el sistema sigue acercando la realidad a ella. - **Ejemplo:** Una copia se cayó por la noche — en segundos hay una nueva en su lugar, y nadie se despertó. - **Pega:** El sistema mantiene exactamente lo que describiste: una meta equivocada se mantiene con la misma terquedad. - **Relaciones:** El corazón de **Kubernetes**; la misma idea de «descríbelo, no lo hagas a mano» que **Infrastructure as Code**. ### Rolling update — envía sin caídas > Cambiar los neumáticos de un camión en marcha de uno en uno, para que nunca tenga que parar — el vehículo sigue rodando mientras se cambia cada pieza por debajo. La orchestration te permite actualizar sin caídas mediante un **rolling update**: sustituye los contenedores viejos por nuevos unos pocos a la vez, comprobando que cada uno está sano (un **health check**) antes de continuar, así que el servicio sigue en pie todo el tiempo. Si una nueva versión se comporta mal, puede detenerse y hacer **rollback** a la anterior automáticamente. Así es como los servicios modernos envían actualizaciones sin ventana de mantenimiento — en vivo, poco a poco y de forma reversible. _Diagram: Las copias pasan de v1 a v2 unas pocas a la vez, cada una comprobada — el servicio sigue en pie todo el camino._ #### Rolling update - **Problema:** Actualizar parando el servicio significa caída para los usuarios. - **Idea:** Sustituir copias unas pocas a la vez, comprobando la salud de cada nueva. - **Ejemplo:** De cuatro copias v1, primero dos pasan a v2, luego las otras dos — el servicio no cayó ni un segundo. - **Coste:** Durante un tiempo corren las dos versiones a la vez — deben poder convivir. - **Relaciones:** Lo hace **Kubernetes**; ante problemas — **Rollback**; parientes — **Canary** y **Blue-green**. > **La pregunta de la orchestration:** «¿Quién mantiene en marcha estos contenedores, los escala según la demanda y los actualiza sin caídas — lo hago a mano, o declaro el estado deseado y dejo que el orquestador lo mantenga?» > La orchestration (Kubernetes) ejecuta muchos contenedores en muchas máquinas: declaras el estado deseado, y se autorrepara, se autoescala y despliega actualizaciones sin caídas. ## 7. Hacer deploy de forma segura Toda esta maquinaria existe para que enviar sea seguro y frecuente. Los últimos hábitos tratan de reducir el radio de impacto de cualquier release — porque el deploy más seguro es el que puedes deshacer. ### Rollback — ten siempre un camino de vuelta > Un documento con deshacer: haces un cambio audaz sabiendo que una tecla restaura la versión anterior, así que experimentas con libertad en lugar de temer cada edición. La propiedad de seguridad más importante es el **rollback** — la capacidad de volver al instante a la última versión buena conocida cuando un release sale mal. Como el pipeline envía artifacts versionados, volver atrás es simplemente desplegar de nuevo el anterior. Saber que puedes deshacer un deploy en segundos es lo que hace seguro hacer releases con frecuencia: una mala versión es un contratiempo menor y reversible, no una crisis. **Nunca envíes algo que no puedas retirar.** _Diagram: v43 se rompió — se vuelve a desplegar el último artifact bueno, v42. Segundos, no una noche apagando fuegos._ #### Rollback - **Problema:** Un mal release ya está en producción y el arreglo llevará horas. - **Idea:** Devolver al instante la última versión buena y arreglar con calma después. - **Ejemplo:** v43 lanza errores — un comando vuelve a poner el artifact v42 en producción. - **Coste:** Necesita artifacts versionados; los cambios en la base de datos son más difíciles de revertir que el código. - **Relaciones:** Funciona gracias al **Artifact**; integrado en **Rolling update**, **Canary** y **Blue-green**. ### Canary release — primero unos pocos usuarios > Probar un plato nuevo con unos pocos invitados dispuestos antes de servirlo a todo el banquete — si está malo, solo unos pocos lo notan, y no has perdido nada. Un deploy **canary** envía la nueva versión primero a una pequeña porción de usuarios. Si sus métricas se mantienen sanas, la despliegas a todos, y si no, la retiras habiendo afectado a casi nadie. Convierte un release de una apuesta de todo o nada en un paso controlado y reversible, y mantiene pequeño el **blast radius** de un error. _Diagram: El router envía el 5% del tráfico a la nueva versión. Métricas bien — se despliega a todos; mal — se retira._ #### Canary release - **Problema:** Un bug en la nueva versión golpea a todos los usuarios a la vez. - **Idea:** Dar primero la nueva versión a una pequeña parte del tráfico y vigilar las métricas. - **Ejemplo:** El 5% de los usuarios recibe v2; los errores no son mayores que en v1 — la parte crece hasta el 100%. - **Coste:** Necesita dividir el tráfico por porcentaje y buenas métricas con las que juzgar. - **Relaciones:** Si va mal — **Rollback**; vecinos — **Blue-green** y **Rolling update**. ### Blue-green deployment — dos entornos y un interruptor > Dos escenarios idénticos en un teatro: la función corre en uno mientras se prepara la nueva en el otro. En el momento justo se gira al público hacia el segundo — y el primero queda listo por si hay que volver. **Blue-green** mantiene dos entornos de producción y cambia el tráfico del viejo (**blue**) al nuevo (**green**) de golpe, con un cambio de vuelta instantáneo si hace falta. La nueva versión se despliega y se comprueba mientras la vieja sigue atendiendo a los usuarios; luego un interruptor — y todos están en la nueva. Como canary, convierte un release en un paso controlado y reversible. _Diagram: El router mueve todo el tráfico de blue (v1) a green (v2) con un solo cambio; blue queda listo para un rollback._ #### Blue-green deployment - **Problema:** Cambiar a una nueva versión en vivo es arriesgado y difícil de deshacer. - **Idea:** Dos entornos completos; el tráfico pasa del viejo al nuevo de golpe. - **Ejemplo:** v2 se levanta en green y se comprueba; el router le envía el 100% del tráfico; si hay problemas — de vuelta a blue. - **Coste:** Mantienes dos entornos completos — el doble de recursos durante un release. - **Relaciones:** **Rollback** instantáneo; a diferencia de **Canary**, cambia a todos de golpe. ### Infrastructure as Code (IaC) — describe tus servidores en archivos > Un plano con el que puedes reconstruir la casa entera exactamente, frente a una casa construida de memoria que nadie puede reproducir si se quema. La misma disciplina se extiende a los propios servidores. **Infrastructure as code (IaC)** significa definir tus servidores, redes y configuración en archivos en lugar de hacer clic a mano en una consola. Ahora todo tu entorno está versionado, es revisable y reproducible — puedes reconstruirlo de forma idéntica, y los cambios pasan por el mismo pipeline que el código. Cierra la última brecha por la que «alguien cambió un ajuste a mano y se olvidó» podría deshacer todo el rigor de los demás pasos. _Diagram: Archivos de infra → revisión en git → el pipeline los aplica a staging y producción. Sin clics a mano en la consola._ #### Infrastructure as Code (IaC) - **Problema:** Alguien cambió un ajuste del servidor a mano y se olvidó — el entorno no se puede reproducir. - **Idea:** Describir servidores, redes y ajustes en archivos y cambiarlos por el mismo pipeline. - **Ejemplo:** Archivos de Terraform describen un servidor y una base de datos; un cambio pasa por revisión y el pipeline lo aplica. - **Coste:** Un lenguaje más y algo de disciplina: nada de «arreglos rápidos» a mano en la consola. - **Relaciones:** Viaja por el **Pipeline**; la misma idea declarativa que **Desired state**. #### Antes de confiar en un proceso de deploy - **¿Está automatizado** de principio a fin — del commit a producción por un pipeline, no a mano? - **¿Construye y prueba CI** cada cambio, manteniendo main siempre funcionando? - **¿Lo que envías es un único artifact** o contenedor, idéntico de test a producción? - **¿Puedes hacer rollback** al instante a la última versión buena? - **¿Los releases arriesgados salen poco a poco** — canary o blue-green, no de golpe? - **¿La propia infraestructura es código** — versionada y reproducible? > Enviar de forma segura es enviar de forma reversible: automatiza el pipeline, envía un único artifact probado, ten un rollback de un clic, publica los cambios arriesgados poco a poco y define la infraestructura como código. ## 8. Cómo se conecta todo Veintiún conceptos son una sola línea. Un cambio pasa CI, se convierte en un artifact, CD lo entrega, el orquestador lo ejecuta y las técnicas de despliegue seguro te atrapan si algo sale mal. Debajo de todo está la infraestructura descrita como código. ### Una imagen: del commit al usuario > La ruta de un paquete: empaquetado una vez, revisado en el almacén, llevado en camión, entregado — y en cada paso se puede devolver al remitente. Lee el diagrama de izquierda a derecha: **Commit** → **CI** (build y test; rojo significa parar) → **Image** (el artifact, construido una vez) → **CD** (el release) → **Kubernetes** (lo ejecuta y mantiene el desired state). Cómo publicar de forma segura lo deciden **Rolling update**, **Canary**, **Blue-green** y **Rollback**. Y **Infrastructure as Code** son las mismas reglas aplicadas a los propios servidores: también pasan por el pipeline. _Diagram: El pipeline arriba, las técnicas de despliegue seguro en medio, la infraestructura como código como cimiento que recorre el mismo camino._ #### Señales de que envías bien - Hacer un release es **aburrido** — pequeño, automatizado y frecuente, no un evento raro y aterrador. - **CI está en verde** antes de que nada se fusione, y **main siempre funciona**. - Envías el **mismo artifact/contenedor** que probaste, hasta producción. - Un mal release es un **rollback** rápido, no una crisis. - Los cambios arriesgados salen por **canary o blue-green**, y tu infra es **código**. ## Chuleta: los 21 conceptos ### El problema del deploy - **Deploy** (release): Poner en marcha una nueva versión. A mano — lento, aterrador y raro. - **Works on my machine** (environment drift): Un bug por entornos distintos: el mismo código, otras versiones y ajustes. - **Boring releases** (small batches): Los releases pequeños y frecuentes son más seguros que los raros y enormes. ### Continuous Integration - **Continuous Integration** (CI): Cada cambio se construye y se prueba automáticamente en minutos. - **Shift left** (catch it early): Cuanto antes encuentras un bug, más barato es arreglarlo. - **Green main branch** (main always works): Solo lo que pasó CI entra en main. ### Continuous Delivery - **Continuous Delivery** (CD): Publicar un buen cambio está automatizado: los pasos del deploy son código. - **Delivery vs Deployment** (con botón o sin botón): Delivery — un humano pulsa el botón; deployment — directo a producción. - **Artifact** (build once, deploy everywhere): Un paquete construido pasa por todos los entornos — pruebas lo que envías. ### Pipeline - **Pipeline** (CI/CD pipeline): La línea automatizada: build → test → deploy. - **Fail fast** (red / green): Una etapa en rojo detiene la línea; solo el verde avanza. ### Contenedores - **Container** (app + entorno): La app junto con su entorno — funciona igual en todas partes. - **Docker** (la herramienta): La herramienta que convirtió los contenedores en la «caja» estándar. - **Image vs Container** (receta y plato): La image es el plano congelado; un container es una instancia en ejecución de ella. ### Orchestration - **Kubernetes** (orquestador): Reparte los contenedores entre servidores, los vigila, los reinicia. - **Desired state** (self-healing, auto-scaling): Declaras la meta — el sistema mantiene la realidad en ella. - **Rolling update** (zero downtime): Sustituye copias unas pocas a la vez — sin caídas. ### Deploys seguros - **Rollback** (deshacer): Devuelve al instante la última versión buena. - **Canary release** (primero unos pocos usuarios): La nueva versión va primero a una pequeña parte de los usuarios. - **Blue-green deployment** (dos entornos): El tráfico pasa de golpe del entorno viejo al nuevo — y de vuelta. - **Infrastructure as Code** (IaC): Servidores y redes descritos en archivos y cambiados por el pipeline. > Enviar debería ser aburrido: automatiza el camino, envía el mismo artifact probado y ten siempre un camino de vuelta. Fin del curso exprés · 8 capítulos · 21 conceptos Ahora toca practicar: toma un proyecto pequeño, escribe un Dockerfile para que funcione en un contenedor y configura un pipeline que lo construya y lo pruebe en cada cambio. Luego haz deploy, rómpelo y haz rollback. Toda la filosofía encaja en el momento en que un release deja de dar miedo porque sabes que la línea lo detectó y que puedes deshacerlo. Pero quédate con una idea por encima de las demás: enviar debería ser aburrido. Automatiza el camino para que cada cambio se construya, se pruebe y se pueda desplegar de la misma manera, y empaqueta la app para que funcione igual en todas partes — y «funciona en mi máquina» por fin se convierte en «funciona en todas partes».