Deployments Canary en C#: lanzamiento seguro sin tiempo de inactividad

¿Qué son los Canary Deployments y por qué salvarán tu producción?

¿Alguna vez has lanzado una actualización a medianoche, rezando para que nada se cayera? ¿Te suena familiar? ¿Y si te dijera que puedes probar código nuevo en usuarios reales, pero de forma que nadie salga perjudicado? Hablamos de los canary deployments — una estrategia de despliegue en la que la nueva versión de la aplicación recibe inicialmente solo una pequeña parte del tráfico. Si todo va bien, el tráfico aumenta. Si no, la reversión es cuestión de segundos.

En el mundo de .NET y C# esto es especialmente relevante: microservicios, altas cargas, requisitos de estabilidad. Escribiremos código, configuraremos un canary deployment y analizaremos ejemplos reales. ¡Allá vamos!

¿Por qué Canary no es solo una palabra de moda?

El blue-green deployment tradicional cambia todo el tráfico de una vez. La actualización continua (rolling update) lo hace gradualmente, pero sin control fino. Canary te da un superpoder: lanzas la nueva versión, pero diriges hacia ella, digamos, el 5% de los usuarios. El 95% restante sigue funcionando con la versión estable anterior. Monitoreas métricas, errores, latencias. Si todo está bien, aumentas gradualmente el porcentaje hasta el 100. Si no, simplemente desconectas el canary.

Para el desarrollador de C#, esto es especialmente cómodo: podemos usar las herramientas integradas de ASP.NET Core, Kubernetes, Feature Flags o incluso un balanceador de carga simple. Lo principal es una arquitectura correcta.

Arquitectura de Canary Deployment para una aplicación .NET

Imaginemos que tenemos una API web en ASP.NET Core que procesa pedidos. Queremos lanzar una nueva lógica de cálculo de descuentos. En lugar de actualizar todos los pods a la vez, hacemos lo siguiente:

\n
• Ejecutamos dos versiones del servicio: stable (v1) y canary (v2).
\n
• Configuramos el balanceador (por ejemplo, Nginx o Kubernetes Service) para que el 95% del tráfico vaya a v1 y el 5% a v2.
\n
• Añadimos la cabecera HTTP X-Canary: true en las respuestas de la versión canary para identificarla.
\n
• Recopilamos métricas (código 200/500, latencia, número de pedidos).
\n
• Si en 30 minutos no hay más errores que en v1, aumentamos el peso del canary al 50%, luego al 100%.
\n

Implementación en C#: de lo simple a lo complejo

Método 1: Canary mediante cabeceras HTTP y balanceador

La forma más sencilla es usar una capa de middleware en ASP.NET Core que marque las solicitudes. Pero primero, veamos cómo se ve el código que distingue la versión canary.

// Startup.cs o Program.cs\npublic class CanaryMiddleware\n{\n    private readonly RequestDelegate _next;\n    private readonly string _version;\n\n    public CanaryMiddleware(RequestDelegate next, string version)\n    {\n        _next = next;\n        _version = version;\n    }\n\n    public async Task InvokeAsync(HttpContext context)\n    {\n        // Añadimos la cabecera para identificar la versión\n        context.Response.Headers.Add("X-App-Version", _version);\n        await _next(context);\n    }\n}\n\n// Registro\napp.UseMiddleware<CanaryMiddleware>("v2-canary");\n

Ahora, a nivel del balanceador (por ejemplo, Nginx), decidimos qué porcentaje de tráfico enviar al pod canary:

upstream backend {\n    server app-stable:5000 weight=95;\n    server app-canary:5000 weight=5;\n}\n

Ventajas: simplicidad. Desventajas: no hay control programático, es difícil hacer pruebas A/B por usuario.

Método 2: Feature Flags en C#

Un enfoque más flexible es usar feature flags (banderas de funcionalidad). Activas la nueva lógica solo para un grupo específico de usuarios. ASP.NET Core tiene soporte integrado:

// Instale el paquete Microsoft.FeatureManagement.AspNetCore\n// Añada en Program.cs\nbuilder.Services.AddFeatureManagement();\n\n// Defina la bandera en appsettings.json\n{\n  "FeatureManagement": {\n    "NewDiscountLogic": false\n  }\n}\n\n// Úselo en el controlador\n[ApiController]\n[Route