La implementación azul-verde promete lanzamientos sin tiempo de inactividad: se configura una copia nueva de su servicio, se le envía algo de tráfico y se cambia una vez que parece saludable. El problema es la palabra "saludable". Un chequeo de salud del balanceador de carga generalmente hace ping a un punto final y espera un 200. Eso le indica que el proceso está activo. No le dice nada sobre si su nueva compilación devuelve el JSON correcto, respeta el mismo contrato o si todavía autentica un token de la misma manera que lo hacía la versión anterior. Así que usted acciona el interruptor, y el primer usuario real encuentra el error que su chequeo de salud no pudo ver.
Esta guía le mostrará cómo probar el entorno verde como lo haría un usuario antes de que cualquier tráfico de producción lo alcance. Ejecutará un conjunto completo de pruebas de API contra la pila inactiva, condicionará el cambio a esos resultados y conectará todo a su pipeline para que ocurra en cada despliegue. Usaremos Apidog y la CLI de Apidog como la capa de pruebas, porque los mismos escenarios de prueba que construye en la aplicación de escritorio pueden ejecutarse sin supervisión en CI contra el entorno al que los apunte.
Si ya practica el despliegue azul-verde pero trata el paso de verificación como "hacer clic durante un minuto", esta es la parte que lo convierte en algo en lo que puede confiar. El objetivo de ejecutar dos entornos idénticos es validar uno de ellos bajo condiciones realistas. Un chequeo de salud es el mínimo, no el máximo.
En resumen (TL;DR)
La implementación azul-verde ejecuta dos entornos de producción idénticos y cambia un enrutador entre ellos. Antes de cambiar el tráfico de azul (en vivo) a verde (nuevo), ejecute su suite completa de pruebas de API directamente contra el verde. Condicione el cambio a una compilación verde de la suite. Con la CLI de Apidog, apunte los mismos escenarios de prueba a la URL base verde en su pipeline, falle el despliegue si alguna aserción falla, y solo entonces cambie el enrutador. Los chequeos de salud confirman que un proceso está activo; las pruebas de API confirman que el contrato sigue vigente.
Qué es realmente la implementación azul-verde
La implementación azul-verde es un patrón de lanzamiento que mantiene dos entornos de grado de producción lado a lado. Uno sirve tráfico en vivo (llámelo azul). El otro permanece inactivo, listo para recibir la próxima versión (verde). Usted despliega la nueva compilación en el entorno verde, la verifica y luego cambia un único interruptor (un objetivo de balanceador de carga, un registro DNS, un selector de servicio de Kubernetes) para que todo el tráfico fluya ahora hacia el entorno verde. El entorno azul se convierte en el modo de espera inactivo para el próximo lanzamiento. Si algo falla, puede volver al azul en segundos.
El atractivo es obvio. No hay ventana de mantenimiento. El cambio es casi instantáneo. Y la reversión es lo más económica posible, porque la versión anterior sigue funcionando y está activa. Compare eso con un despliegue rodante, donde se reemplazan las instancias en el lugar y una compilación defectuosa ya está sirviendo a una parte de los usuarios cuando usted se da cuenta.
Pero el patrón solo da sus frutos si el entorno verde está realmente listo cuando se realiza el cambio. Esa verificación de la preparación es donde la mayoría de los equipos invierten poco. Confirman que el verde arranca y pasa un ping superficial a /health, luego cambian y esperan. La forma de la implementación azul-verde facilita una verificación exhaustiva. El verde está completamente desplegado y accesible, simplemente no está recibiendo tráfico público, por lo que no hay excusa para omitirlo. Usted tiene una copia completa y aislada de la producción esperando ser probada.
Si desea primero el vocabulario más amplio de la estrategia de lanzamiento, nuestro desglose de entrega continua vs. despliegue continuo vs. integración continua establece el contexto de dónde encaja el azul-verde.
Por qué una verificación de salud no es una prueba
Aquí está la brecha que afecta a los equipos. Una verificación de salud típica se ve así:
# Sondeo de salud del balanceador de carga
GET /health -> 200 OK -> marcar objetivo como saludable
Ese punto final generalmente devuelve un {"status":"ok"} codificado. No toca su base de datos. No ejercita la autenticación. No serializa un recurso real. Una compilación puede pasar esta sonda mientras cada punto final de negocio devuelve un 500, una carga útil mal formada o el esquema de ayer.
Considere los modos de fallo que un ping a /health pasará sin problemas:
- Una migración que no se ejecutó, por lo que
GET /orders/{id}falla por una columna faltante. - Un campo JSON renombrado (
user_idse convirtió enuserId) que rompe a todos los consumidores descendentes. - Un cambio de autenticación que ahora rechaza tokens que la aplicación móvil sigue emitiendo.
- Un aumento de versión de dependencia que cambia el formato de fecha de ISO 8601 a una marca de tiempo Unix.
- Un nuevo encabezado requerido que devuelve
400para cualquier cliente que no lo envíe.
Ninguno de estos impide que el proceso arranque. Todos ellos rompen a los usuarios reales en el instante en que usted cambia el tráfico. La solución no es un chequeo de salud más inteligente; es una suite de pruebas real que llama a sus puntos finales como lo hacen los clientes, afirma sobre códigos de estado, cuerpos de respuesta, esquemas y latencia, luego informa si pasa o falla. Esta es la misma disciplina detrás de las pruebas de contrato de API; usted está verificando que el servicio en ejecución aún coincide con el acuerdo del que dependen los consumidores.
El flujo de trabajo de pruebas azul-verde, de principio a fin
Aquí está la secuencia que estamos construyendo. El nuevo paso es "probar el verde", y se sitúa entre el despliegue y el cambio.
- Desplegar en el verde. Empuje la nueva compilación al entorno inactivo. Se vuelve accesible en una dirección interna, por ejemplo,
https://green.internal.example.com, pero aún no recibe tráfico público. - Prueba de humo en el verde. Ejecute un subconjunto rápido de solicitudes de ruta crítica contra el verde. Iniciar sesión, obtener un recurso principal, crear uno. Si alguno falla, deténgase aquí. El azul sigue sirviendo a los usuarios y nunca se dio cuenta.
- Ejecute la suite completa contra el verde. Ejecute sus escenarios completos de pruebas de API (rutas felices, casos de error, flujos de autenticación, aserciones de esquema) apuntando a la URL base verde.
- Condicionar el cambio. Si la suite pasa, continúe. Si algo falla, el pipeline se detiene y el verde se desmantela o se deja para inspección. La producción permanece intacta.
- Accionar el interruptor. Reoriente el enrutador (balanceador de carga, DNS o selector de servicio) del azul al verde.
- Verificar en producción. Ejecute la misma prueba de humo contra la URL en vivo después del cambio para confirmar que el cambio se realizó limpiamente.
- Mantener el azul activo. Mantenga el entorno antiguo durante una ventana de reversión. Si la monitorización posterior al cambio se desvía, vuelva al azul instantáneamente.
El truco es que los pasos 2, 3 y 6 utilizan las mismas definiciones de prueba. Usted construye los escenarios una vez y solo cambia la URL base a la que apunta el ejecutor. Esa es la capacidad que configuraremos a continuación.
Creación de escenarios de prueba en Apidog
Antes de automatizar cualquier cosa, necesita una suite de pruebas que valga la pena ejecutar. Apidog le permite construirla visualmente y luego ejecutarla desde la línea de comandos sin reescribir nada. Descargue Apidog y cree un proyecto para el servicio que está desplegando.
Dentro de un proyecto, usted ensambla escenarios de prueba a partir de sus puntos finales de API existentes. Un escenario es un conjunto ordenado de solicitudes con aserciones y paso de variables entre pasos. Para una suite de preparación azul-verde, usted quiere escenarios que reflejen lo que hacen los clientes reales, no solo pings únicos.
Un conjunto práctico de inicio para un servicio de pedidos:
- Flujo de autenticación:
POST /auth/logincon credenciales válidas, afirmar200, extraer el token de portador en una variable, luego usarlo en cada solicitud posterior. - Ruta de lectura:
GET /orderscon el token, afirmar200, afirmar que la respuesta es un arreglo, afirmar que cada elemento tieneid,statusytotal. - Recurso único:
GET /orders/{id}, afirmar que el esquema coincide con su definición OpenAPI, afirmar quetotales un número mayor que cero. - Ruta de escritura:
POST /orderscon un cuerpo válido, afirmar201, afirmar que eliddevuelto no está vacío, luegoGETese nuevo id para confirmar que persistió. - Casos negativos:
GET /orders/{id}con un token inválido, afirmar401.POST /orderscon un campo requerido faltante, afirmar400.
Dos características son las más importantes para detectar los fallos que un chequeo de salud pasa por alto. Primero, las aseraciones de esquema: Apidog puede validar una respuesta contra el esquema JSON o la definición OpenAPI para ese punto final, de modo que un campo renombrado o con tipo cambiado falla la prueba en lugar de pasar a producción. Segundo, las aseraciones de respuesta sobre valores específicos, encabezados y tiempo de respuesta, para que detecte la deriva sutil: un cambio de formato de fecha, un null donde esperaba un número, una regresión de latencia.
La decisión de diseño clave es el manejo del entorno. No codifique https://blue.example.com en sus solicitudes. Defina una variable de entorno para la URL base y referénciala en todas partes como {{baseUrl}}. En Apidog, usted configura entornos (Producción, Verde, Local) y cambia el activo, o anula la URL base en tiempo de ejecución desde la CLI. Esta es la misma disciplina de entorno y secretos cubierta en nuestra guía sobre un cliente de API con gestión de entorno y secretos; sus pruebas permanecen idénticas entre azul y verde, solo el objetivo se mueve.
Si desea agrupar estos escenarios en una única unidad ejecutable, las suites de prueba de Apidog agrupan múltiples escenarios para que un solo comando ejecute toda la verificación de preparación.
Ejecución de la suite desde la línea de comandos
La aplicación de escritorio es donde usted construye y depura escenarios. La CLI es lo que los ejecuta en su pipeline contra el entorno verde. Instálela con npm; necesita Node.js v16 o posterior:
npm install -g apidog-cli
El ejecutor ejecuta un escenario de prueba desde una configuración de CI. En Apidog, usted genera una configuración de CI para un escenario de prueba, lo que le proporciona un comando de ejecución vinculado a un token de acceso. La forma básica:
apidog run "https://api.apidog.com/api/v1/api-test/ci-config/<config-id>/detail?token=<token>" \
-r html,cli \
--out-file green-readiness
La bandera -r selecciona los reportadores. cli imprime los resultados en la terminal para que el registro de su pipeline muestre exactamente qué aserción falló. html escribe un informe autocontenido que puede archivar como un artefacto de compilación para quien revise el despliegue. También hay un reportador JSON cuando desea alimentar los resultados a otra herramienta. La bandera --out-file nombra la salida para que cada ejecución sea rastreable a una compilación.
Para apuntar la suite específicamente al entorno verde, el ejecutor acepta un indicador de entorno para que el mismo escenario se ejecute en diferentes objetivos:
# Probar el entorno verde (inactivo) antes del cambio
apidog run "<ci-config-url>" \
--environment <greenEnvironmentId> \
-r cli,html \
--out-file green-pre-switch
También puede dirigir las ejecuciones completamente desde archivos de escenario exportados cuando prefiera mantener todo en el repositorio y evitar una llamada de red para obtener la configuración:
apidog run --exported-data ./tests/orders-readiness.json \
--variables ./tests/green.variables.json \
-r cli
Para un recorrido más profundo del ejecutor y sus opciones en un contexto de pipeline, consulte cómo automatizar pruebas de API en CI/CD. El comportamiento que importa para el azul-verde es el código de salida: cuando una aserción falla, la CLI sale con un código distinto de cero. Ese único hecho es lo que le permite controlar el cambio. Una salida no nula detiene el pipeline antes de que se ejecute el paso de cambio.
Conectándolo a un pipeline de GitHub Actions
Aquí está el paso de verificación dentro de un flujo de trabajo de despliegue. Esto asume que un trabajo anterior ya desplegó la compilación en verde y que el verde es accesible desde el ejecutor. El trabajo prueba el verde, y solo una ejecución exitosa permite que el siguiente trabajo realice el cambio.
name: deploy-blue-green
on:
push:
branches: [main]
jobs:
deploy-green:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Deploy build to green environment
run: ./scripts/deploy-green.sh
# green is now reachable at https://green.internal.example.com
test-green:
needs: deploy-green
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install Apidog CLI
run: npm install -g apidog-cli
- name: Run readiness suite against green
run: |
apidog run "${{ secrets.APIDOG_CI_CONFIG_URL }}" \
--environment "${{ vars.GREEN_ENV_ID }}" \
-r cli,html \
--out-file green-readiness
- name: Archive HTML report
if: always()
uses: actions/upload-artifact@v4
with:
name: green-readiness-report
path: ./green-readiness.html
switch-traffic:
needs: test-green # only runs if test-green passed
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Flip router from blue to green
run: ./scripts/switch-to-green.sh
- name: Smoke test production URL post-switch
run: |
npm install -g apidog-cli
apidog run "${{ secrets.APIDOG_SMOKE_CONFIG_URL }}" \
--environment "${{ vars.PROD_ENV_ID }}" \
-r cli
La cadena de dependencia hace el control por usted. switch-traffic lista needs: test-green, así que si la suite de preparación falla, el trabajo de cambio nunca comienza. El verde permanece inactivo, el azul sigue sirviendo, y nadie más abajo se ve afectado. El if: always() en la carga del artefacto significa que usted obtiene el informe HTML incluso en caso de fallo, que es exactamente cuando quiere leerlo.
Almacene la URL de configuración de CI y el token como secretos del repositorio, nunca en línea. Los IDs de entorno pueden vivir como variables del repositorio ya que no son sensibles. Si su equipo trabaja con GitLab, Jenkins, CircleCI o Azure Pipelines, la estructura es idéntica: una etapa de prueba que sale con un código distinto de cero bloquea la etapa de cambio. Nuestro tutorial sobre cómo automatizar pruebas de API en GitHub Actions cubre la configuración del ejecutor con más detalle, y el mismo patrón se transfiere a cualquiera de estas plataformas.
Prueba de humo primero, suite completa después
Ejecutar la suite completa contra el entorno verde es el control correcto, pero no querrá descubrir una compilación totalmente rota a los ocho minutos de una ejecución de doce minutos. Divida la verificación en dos pases.
La prueba de humo es un pequeño escenario de tres a cinco solicitudes que cubren la ruta crítica. Inicie sesión, lea un recurso, cree uno, léalo de nuevo. Ejecútela primero. Si el entorno verde no puede hacer esto, la suite completa es una pérdida de tiempo y debe fallar rápidamente. Manténgala por debajo de los treinta segundos.
La suite completa se ejecuta solo después de que la prueba de humo pasa. Aquí es donde reside la amplitud: cada punto final, casos de error, casos límite, validación de esquema en cada respuesta, permutaciones de autenticación, paginación, encabezados de límite de tasa. Es más lenta y eso está bien, porque es la última barrera antes de los usuarios reales.
Este enfoque de dos niveles es la misma lógica detrás del pensamiento de escenario de prueba vs. caso de prueba: el escenario de humo es una señal rápida de confianza, la suite completa es una cobertura exhaustiva. Ambos apuntan a la misma URL base verde; solo difieren en cuánto cubren y cuándo se ejecutan.
Una nota sobre los datos de prueba. El entorno verde es un entorno de producción, así que sea deliberado sobre lo que crean sus pruebas de ruta de escritura. O apunte las pruebas de escritura a una cuenta de prueba dedicada cuyos registros usted limpia, o ejecútelas contra una instancia verde respaldada por una base de datos de staging antes de que la capa de datos sea promovida. Verificar el comportamiento sin contaminar los datos de producción es la línea que debe seguir, y vale la pena comprender la diferencia entre un sandbox vs. un entorno de prueba al diseñar esto.
Errores comunes que anulan todo el propósito
Los equipos adoptan el azul-verde y aún así envían roturas. Generalmente es una de estas:
- Probar el azul en lugar del verde. Si su suite apunta a la URL en vivo, está probando la versión que ya está en producción, no la que está a punto de lanzar. Siempre apunte explícitamente a la URL base verde antes del cambio.
- Solo verificar códigos de estado. Un
200con un cuerpo incorrecto sigue siendo una respuesta rota. Afirme sobre la forma de la carga útil y los valores clave, no solo el estado HTTP. Las aserciones de esquema son las que detectan los cambios de nombre de campo y de tipo. - Omitir los casos negativos. Una compilación que devuelve
200para un token inválido es una regresión de seguridad que una prueba de ruta feliz nunca detectará. Incluya los casos401,403y400en la puerta. - Sin disciplina de reversión. El superpoder del azul-verde es la reversión instantánea, pero solo si mantiene el azul activo. No lo desactive en el segundo en que el verde entra en funcionamiento. Manténgalo durante su ventana de monitoreo.
- URLs codificadas en las solicitudes de prueba. En el momento en que una URL base se integra en una solicitud, ha perdido la capacidad de ejecutar la misma suite contra el verde y el azul. Use una variable de entorno para el host, siempre.
- Tratar la verificación de salud como la puerta. El artículo completo, en una sola línea. La sonda le dice al balanceador de carga que un proceso existe. Sus pruebas de API le dicen que el contrato se mantiene.
Azul-verde versus canario: dónde encajan las pruebas
La implementación azul-verde no es la única estrategia sin tiempo de inactividad, y el enfoque de las pruebas cambia con cada una.
| Estrategia | Cómo se mueve el tráfico | Dónde encajan las pruebas de API |
|---|---|---|
| Azul-verde | Todo a la vez, de azul a verde | Suite completa contra el verde antes del cambio; el control es antes del corte |
| Canario | Gradualmente, un pequeño % a la nueva versión | Aserciones continuas en el segmento canario; promover según métricas limpias |
| Rodante | Instancia por instancia, en su lugar | Comprobaciones rápidas por instancia; más difícil de controlar porque el despliegue ya está en curso |
| Recrear | Detener lo antiguo, iniciar lo nuevo (con tiempo de inactividad) | La suite se ejecuta durante la ventana; el tiempo de inactividad es la contrapartida |
El azul-verde le ofrece el control más limpio de los cuatro porque el entorno verde está completamente desplegado y completamente aislado cuando usted lo prueba. Obtiene una réplica de producción completa para verificar, sin exposición del usuario y con un único interruptor atómico. El canario intercambia ese control limpio por una exposición gradual y se apoya más en la monitorización en vivo. Para la mayoría de los servicios respaldados por API, el azul-verde más una suite previa al cambio es la forma más sencilla de obtener alta confianza sin una ventana de mantenimiento.
Forma real de esto
Un equipo de tecnología financiera que ejecuta una API de pagos utiliza el azul-verde para cada lanzamiento porque un despliegue defectuoso no es un error cosmético, es una transacción fallida. Su control es una suite de cuarenta escenarios contra el verde que cubre la autenticación, claves de idempotencia, redondeo de moneda y firmas de webhook. La ejecución completa tarda unos seis minutos. Nada llega a producción hasta que está verde en todos los aspectos, y el informe HTML se adjunta a cada despliegue para el seguimiento de auditoría.
Un equipo de SaaS con una API pública ejecuta una versión más ligera: una verificación de humo de doce escenarios contra el verde, luego el cambio, luego una prueba de humo posterior al cambio contra la URL en vivo. Su prioridad es detectar la deriva del esquema, ya que las integraciones de terceros fallan ruidosamente cuando un campo cambia de forma. Las aserciones de esquema en cada respuesta son el corazón de su control.
Ambos equipos construyen los escenarios una vez en Apidog y los ejecutan sin supervisión desde la CLI en cada push. La aplicación de escritorio sigue siendo el lugar donde los ingenieros depuran y amplían los escenarios; el pipeline es donde esos mismos escenarios se convierten en el control de lanzamiento.
Conclusión
La implementación azul-verde le ofrece una copia gratuita y completamente desplegada de producción que permanece inactiva antes de cada lanzamiento. Desperdiciar eso verificando solo una sonda de salud superficial es la forma más común en que los equipos envían errores con una estrategia de cero tiempo de inactividad. La solución es probar el entorno verde como un usuario antes de accionar el interruptor.
Las piezas:
- Construya escenarios de prueba reales (autenticación, lectura, escritura, casos negativos, aserciones de esquema) una sola vez, en Apidog.
- Use una variable de entorno para la URL base para que la misma suite se ejecute contra el verde y el azul sin cambios.
- Ejecute una prueba de humo rápida primero, luego la suite completa, ambas apuntando al entorno verde.
- Condicione el cambio al código de salida de la suite en su pipeline para que un fallo bloquee el cambio.
- Mantenga el azul activo para una reversión instantánea durante su ventana de monitoreo.
Configure esto una vez y cada despliegue obtendrá el mismo control automáticamente. Descargue Apidog para construir su suite de preparación, genere una configuración de CI e inserte el paso apidog run en su pipeline antes de la etapa de cambio. Su primer usuario real nunca debería ser su primera prueba real.
botón
Preguntas frecuentes
¿Qué es la implementación azul-verde en términos sencillos? Es ejecutar dos entornos de producción idénticos y cambiar todo el tráfico entre ellos. Uno (azul) atiende a los usuarios en vivo mientras que el otro (verde) recibe la nueva versión. Usted prueba el verde, luego acciona un solo interruptor para que el verde se active. El azul permanece como un objetivo de reversión instantánea.
¿Cómo pruebo el entorno verde antes de cambiar el tráfico? Apunte su suite de pruebas de API a la URL base del entorno verde y ejecútela en su pipeline antes del paso de cambio. Con la CLI de Apidog, ejecute sus escenarios con apidog run contra el entorno verde, falle el despliegue ante cualquier aserción rota, y solo cambie el tráfico si la suite pasa.
¿Por qué una verificación de salud del balanceador de carga no es suficiente para el azul-verde? Una verificación de salud generalmente hace ping a un punto final y confirma un 200, lo que solo prueba que el proceso está en funcionamiento. No detectará un campo JSON renombrado, una migración fallida, un flujo de autenticación roto o un cambio de esquema. Una suite de pruebas de API real afirma sobre los cuerpos de respuesta, esquemas y casos de error, por lo que detecta los fallos que una sonda de salud pasa por alto.
¿Puedo ejecutar las mismas pruebas de API en CI que construí en la aplicación de escritorio? Sí. Los escenarios que construye visualmente en Apidog se ejecutan sin cambios desde la CLI de Apidog. Usted genera una configuración de CI para un escenario y luego llama a apidog run con esa configuración en GitHub Actions, GitLab CI, Jenkins o cualquier pipeline. La CLI sale con un código distinto de cero en caso de fallo, lo que le permite controlar el despliegue.
¿Cuál es la diferencia entre la implementación azul-verde y la canario para las pruebas? El azul-verde cambia todo el tráfico a la vez después de probar el entorno verde completamente desplegado, por lo que el control es antes del corte. El canario desplaza el tráfico gradualmente a un pequeño segmento y se basa en la monitorización en vivo de ese segmento. El azul-verde ofrece un control de prueba previo al lanzamiento más limpio; el canario ofrece una exposición gradual en el mundo real.
¿Debería ejecutar pruebas de ruta de escritura contra el entorno de producción verde? Tenga cuidado con los datos. Utilice una cuenta de prueba dedicada cuyos registros usted limpie, o ejecute pruebas de escritura contra una instancia verde respaldada por una base de datos de staging antes de promover la capa de datos. El objetivo es verificar el comportamiento sin contaminar los datos de producción, que es la línea entre un sandbox y una verdadera prueba de producción.
¿Qué tan rápido debe ser el control de prueba previo al cambio? Divídalo. Ejecute una prueba de humo de tres a cinco solicitudes de ruta crítica en menos de treinta segundos para fallar rápidamente, luego ejecute la suite completa (cada punto final, casos de error, comprobaciones de esquema) solo si la prueba de humo pasa. Un control completo de unas pocas docenas de escenarios generalmente termina en unos pocos minutos, lo cual es aceptable para un control de lanzamiento.