Curso exprés · No. 20
Dos ideas cambiaron cómo el software llega desde el portátil de un desarrollador hasta los usuarios reales. Primero, automatizar todo el camino desde el código hasta producción para que hacer un release sea aburrido en lugar de aterrador — eso es CI/CD. Segundo, empaquetar la app con todo lo que necesita para que funcione igual en todas partes — eso son los contenedores. Juntos convierten «funciona en mi máquina» de una excusa en el plan.
21 conceptos · un diagrama para cada uno · chuleta al final
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).
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.
- 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.
- 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.
- 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.
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.
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.
- 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».
- 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.
- 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.
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.
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.
- 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.
- 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».
- 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.
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).
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».
- 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.
- 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
deployni 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.
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.
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.
- 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.
- Qué es
La herramienta que popularizó los contenedores: los construye y los ejecuta.
- Ejemplo
docker buildconstruye una image a partir de un Dockerfile;docker runarranca 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 Containers e Images; 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.
- 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.
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).
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.
- 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: 5en 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 Containers 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.
- 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.
- 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 orchestration (Kubernetes) ejecuta muchos contenedores en muchas máquinas: declaras el estado deseado, y se autorrepara, se autoescala y despliega actualizaciones sin caídas.
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.
- 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.
- 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.
- 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.
- 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.
- ¿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.
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.
- 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
- Deployrelease
Poner en marcha una nueva versión. A mano — lento, aterrador y raro.
- Works on my machineenvironment drift
Un bug por entornos distintos: el mismo código, otras versiones y ajustes.
- Boring releasessmall batches
Los releases pequeños y frecuentes son más seguros que los raros y enormes.
Continuous Integration
- Continuous IntegrationCI
Cada cambio se construye y se prueba automáticamente en minutos.
- Shift leftcatch it early
Cuanto antes encuentras un bug, más barato es arreglarlo.
- Green main branchmain always works
Solo lo que pasó CI entra en main.
Continuous Delivery
- Continuous DeliveryCD
Publicar un buen cambio está automatizado: los pasos del deploy son código.
- Delivery vs Deploymentcon botón o sin botón
Delivery — un humano pulsa el botón; deployment — directo a producción.
- Artifactbuild once, deploy everywhere
Un paquete construido pasa por todos los entornos — pruebas lo que envías.
Pipeline
- PipelineCI/CD pipeline
La línea automatizada: build → test → deploy.
- Fail fastred / green
Una etapa en rojo detiene la línea; solo el verde avanza.
Contenedores
- Containerapp + entorno
La app junto con su entorno — funciona igual en todas partes.
- Dockerla herramienta
La herramienta que convirtió los contenedores en la «caja» estándar.
- Image vs Containerreceta y plato
La image es el plano congelado; un container es una instancia en ejecución de ella.
Orchestration
- Kubernetesorquestador
Reparte los contenedores entre servidores, los vigila, los reinicia.
- Desired stateself-healing, auto-scaling
Declaras la meta — el sistema mantiene la realidad en ella.
- Rolling updatezero downtime
Sustituye copias unas pocas a la vez — sin caídas.
Deploys seguros
- Rollbackdeshacer
Devuelve al instante la última versión buena.
- Canary releaseprimero unos pocos usuarios
La nueva versión va primero a una pequeña parte de los usuarios.
- Blue-green deploymentdos entornos
El tráfico pasa de golpe del entorno viejo al nuevo — y de vuelta.
- Infrastructure as CodeIaC
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.