Deployments Canary en Swift: cómo implementar funciones sin miedo

Introducción: ¿Por qué Canary no es sobre pajaritos?

Imagine: lanza una nueva función en su aplicación. Todo está probado, el CI/CD está en verde, la revisión de código está hecha. Una hora después: una avalancha de reseñas negativas, errores, caídas. ¿Le suena familiar?

En el mundo del desarrollo iOS hay una solución elegante: Canary deployments (despliegues canarios). Es una técnica donde solo un pequeño porcentaje de usuarios (normalmente del 1 al 5%) recibe la nueva versión de la función. Si todo va bien, se despliega para todos. Si no, se revierte con un daño mínimo.

En este artículo, analizaremos cómo implementar Canary deployments en Swift usando feature flags y Firebase Remote Config. Sin magia, solo código funcional y prácticas reales.

¿Qué es un Canary deployment y por qué es necesario en Swift?

El término proviene de la industria minera: los mineros llevaban canarios para que su estado alertara sobre fugas de gas. En TI es lo mismo: un pequeño grupo de usuarios actúa como "canario", mostrando si la nueva versión funciona.

¿Por qué es importante para los desarrolladores de Swift?

\n
• Seguridad: No arriesga a todos los usuarios a la vez
\n
• Pruebas A/B: Puede comparar métricas de la función antigua y la nueva
\n
• Flexibilidad: La reversión toma segundos, no días
\n
• Control: Puede activar la función selectivamente para testers o usuarios beta
\n

En Swift usamos feature flags (banderas de funcionalidad) — son variables booleanas que activan/desactivan funcionalidades sin una nueva compilación. Las combinamos con configuración remota (Firebase, LaunchDarkly) y obtenemos un Canary deployment completo.

Arquitectura de Canary deployment en Swift

Construyamos un sistema simple pero robusto. Necesitaremos:

\n
1. Feature Flag Provider — servicio que proporciona el estado de la función
\n
2. Remote Config — almacenamiento remoto de banderas (usamos Firebase)
\n
3. Lógica de distribución — quién entra en el grupo canario
\n
4. Monitoreo — recopilamos métricas e informes de fallos
\n

Paso 1: Configuración de Firebase Remote Config

Primero, agregamos Firebase al proyecto. Si aún no lo ha hecho, siga la documentación oficial. Luego, creamos los parámetros de Remote Config:

\n
• new_checkout_enabled — activa el nuevo proceso de pago
\n
• new_checkout_percentage — porcentaje de usuarios que lo verán (0.0–1.0)
\n
• new_checkout_deadline — fecha de activación completa (opcional)
\n

En la consola de Firebase, establecemos los valores por defecto: false, 0.0, nil.

Paso 2: Feature Flag Provider en Swift

Creamos un protocolo y su implementación. Esto permitirá cambiar fácilmente entre Firebase, banderas locales o mocks para pruebas.

import Foundation\nimport FirebaseRemoteConfig\n\n// MARK: - Protocol\nprotocol FeatureFlagProvider {\n    func isFeatureEnabled(_ feature: FeatureFlag) -> Bool\n    func percentage(for feature: FeatureFlag) -> Double\n    func fetchRemoteConfig(completion: @escaping (Bool) -> Void)\n}\n\n// MARK: - Feature Flags\nenum FeatureFlag: String, CaseIterable {\n    case newCheckout = "new_checkout_enabled"\n    case newCheckoutPercentage = "new_checkout_percentage"\n    case newCheckoutDeadline = "new_checkout_deadline"\n    \n    var defaultValue: Any {\n        switch self {\n        case .newCheckout: return false\n        case .newCheckoutPercentage: return 0.0\n        case .newCheckoutDeadline: return "" // ISO8601 string\n        }\n    }\n}\n\n// MARK: - Firebase Implementation\nfinal class FirebaseFeatureFlagProvider: FeatureFlagProvider {\n    private let remoteConfig = RemoteConf