Continuous Delivery (CD): qué es, en qué se diferencia de Continuous Deployment

Qué es Continuous Delivery

Continuous Delivery (CD) es una extensión de Continuous Integration que añade automatización para todas las etapas de preparación del lanzamiento: compilación de la versión de lanzamiento, firma con certificados, ofuscación, verificación de metadatos de la tienda de aplicaciones y despliegue en staging. El término fue introducido por Jez Humble y David Farley en el libro “Continuous Delivery” (2010), donde formalizaron la práctica que permite a los equipos hacer lanzamientos predecibles y de bajo riesgo.

Evolución de la entrega de software

Antes de la adopción de CD, los lanzamientos eran un evento: el equipo se reunía en una sala, seguía una lista de verificación de 20 puntos, ejecutaba scripts manualmente y esperaba que nada se rompiera. Continuous Delivery convierte un lanzamiento de evento en proceso: un pequeño cambio de código puede enviarse a los usuarios en cuestión de minutos, no semanas. Amazon, Netflix y Etsy fueron los primeros en adoptar CD en la década de 2010 — hoy es el estándar para los equipos de producto.

Valor comercial de CD

La entrega rápida de funcionalidades es una ventaja competitiva. Si un competidor lanza nueva funcionalidad en días mientras tú tardas meses, el mercado elige al competidor. Las métricas DORA muestran: los equipos élite (con CD) tienen un tiempo de despliegue inferior a 1 hora, los equipos bajos (sin CD) — de 1 semana a 1 mes. CD también reduce radicalmente el riesgo: los cambios pequeños son más difíciles de romper que un gran lanzamiento trimestral.

CD vs CI vs Continuous Deployment

Los términos CI, CD y Continuous Deployment a menudo se confunden, pero existe un límite claro entre ellos. Comprender las diferencias ayuda a diseñar el pipeline correctamente y elegir el nivel de automatización que coincida con la madurez del equipo y los requisitos comerciales.

Continuous Integration

CI es la base sobre la que se construye CD. CI garantiza que cada commit pase por compilación y pruebas. Sin CI, CD es imposible: si el código no está verificado, no puede lanzarse. CI verifica la corrección, CD verifica la preparación para el uso comercial.

Continuous Delivery

CD añade a CI las etapas de compilación de la versión de lanzamiento, verificación de metadatos, firma y despliegue en staging o en la tienda de aplicaciones para pruebas beta. La diferencia clave — la decisión de lanzar a producción la toma una persona (gerente, propietario del producto). CD hace que el lanzamiento esté “a un clic de distancia” — simple y seguro.

Continuous Deployment

Continuous Deployment es automatización completa: cada cambio que pasa todas las etapas del pipeline CD se envía automáticamente a producción sin aprobación manual. Continuous Deployment es aplicable para productos SaaS y servicios web, pero rara vez se usa en el desarrollo móvil debido a las políticas de las tiendas de aplicaciones (App Store Review, Google Play Review requiere envío manual).

Continuous Delivery para aplicaciones móviles

CD para aplicaciones móviles tiene características que lo distinguen de los pipelines web y backend. Los lanzamientos móviles pasan por tiendas de aplicaciones (App Store Review, Google Play Review), lo que añade una barrera de tiempo y proceso. CD automatiza todo lo que se puede automatizar antes del envío para revisión para maximizar la probabilidad de pasar la verificación en el primer intento.

Preparación para la publicación en Google Play

El pipeline CD de Android incluye: compilación de AAB (Android App Bundle), firma con clave de lanzamiento, ofuscación mediante R8/ProGuard, verificación del tamaño del APK y clases multidex, generación de notas de lanzamiento. El uso de product flavors de Gradle (free/paid, dev/staging/prod) permite gestionar múltiples configuraciones desde un único pipeline.

Preparación para la publicación en App Store

El CD de iOS requiere firma con certificados mediante Fastlane match, verificación del cumplimiento de los iconos (requisito de App Store — 1024×1024 px), validación de metadatos (nombre, descripción, palabras clave), verificación de ausencia de API privadas. La validación técnica se realiza mediante altool --validate-app sin carga en App Store Connect, lo que proporciona retroalimentación rápida.

# Fastfile — pipeline CD completo para iOS y Android
platform :ios do
  desc "CD de iOS — preparación del lanzamiento y carga en TestFlight"
  lane :deliver_to_testflight do
    capture_screenshots
    match(type: "appstore")
    build_app(
      scheme: "MyApp",
      export_method: "app-store",
      workspace: "MyApp.xcworkspace"
    )
    pilot(skip_waiting_for_build: true)
  end
end

platform :android do
  desc "CD de Android — compilación de AAB y carga en Google Play Console"
  lane :deliver_to_internal do
    gradle(
      task: "bundleRelease",
      build_type: "Release",
      print_command: true
    )
    upload_to_play_store(
      track: "internal",
      skip_upload_metadata: true
    )
  end
end

Fastlane deliver_to_testflight recopila capturas de pantalla, obtiene certificados mediante match, compila IPA y lo carga en TestFlight. El lane deliver_to_internal para Android compila Release AAB mediante Gradle y lo carga en la pista interna de Google Play Console. Ambos pipelines se ejecutan desde CI tras pasar las pruebas.

Componentes del pipeline CD

Un pipeline CD consta de etapas secuenciales, cada una añadiendo confianza de que el lanzamiento está listo para los usuarios. Las etapas se dividen en técnicas (compilación, firma) y de producto (metadatos, capturas de pantalla, verificación de descripciones). Saltarse cualquier etapa aumenta el riesgo de que el lanzamiento sea rechazado por la tienda de aplicaciones.

Gestión de versiones

Un componente crítico de CD es la gestión automática de versiones. El incremento de versión (versionCode y versionName para Android, CFBundleVersion y CFBundleShortVersionString para iOS) se realiza en base a etiquetas Git o la versión anterior en la tienda. Fastlane increment_version_number y los comandos de Gradle (versionCode auto-increment) automatizan este paso.

Metadatos de la tienda

Google Play Console y App Store Connect requieren: descripción de la aplicación, palabras clave, categoría, clasificación, enlaces a la política de privacidad. CD incluye la verificación de la presencia y corrección de los metadatos. Fastlane deliver y supply automatizan la carga de descripciones, capturas de pantalla e iconos junto con la compilación.

Verificaciones de puerta

Antes de enviar para revisión, el pipeline realiza verificaciones de puerta: verificación del tamaño de la compilación (APK > 200 MB es rechazado por Google Play), presencia de todas las localizaciones, ausencia de símbolos de depuración en la compilación de lanzamiento, verificación del archivo de mapeo ProGuard para decodificar registros de fallos. Si alguna verificación falla — el pipeline bloquea el lanzamiento.

Pruebas automatizadas para CD

El nivel de confianza en CD es directamente proporcional a la calidad de las pruebas automatizadas. Si las pruebas no detectan regresiones — el lanzamiento puede romper la producción y el equipo pierde confianza en CD. El CD móvil requiere una pirámide de pruebas de tres niveles adaptada a las especificidades de la plataforma.

Pruebas unitarias

Las pruebas unitarias verifican la lógica de negocio de forma aislada. La cobertura de código debe ser al menos del 70% para los módulos críticos (autenticación, pagos, redes). CI ejecuta pruebas unitarias en cada push, y si fallan — el pipeline CD se bloquea hasta que se solucionen.

Pruebas de integración

Verifican la interacción de componentes: capa de red con API real (o servidor mock), base de datos, sistema de archivos. Las pruebas DAO de Room para Android, las pruebas de Core Data para iOS son ejemplos de pruebas de integración. Son más lentas que las pruebas unitarias (1–5 minutos) y se ejecutan en la etapa de CD, no en CI en cada commit.

Pruebas de UI y capturas de pantalla

Las pruebas de capturas de pantalla (snapshot testing) comparan las pantallas de la aplicación con imágenes de referencia. Si un cambio de código alteró la UI — la prueba falla y el desarrollador comprueba si el cambio es esperado. Android soporta Roborazzi y Paparazzi, iOS — SnapshotTesting de Point-Free. Las pruebas de capturas de pantalla se ejecutan antes del lanzamiento como parte del pipeline CD.

Mejores prácticas de Continuous Delivery

La implementación de Continuous Delivery requiere no solo herramientas sino también un cambio en la cultura del equipo. Las prácticas a continuación se basan en años de experiencia de equipos móviles de Google, Spotify y Uber y están adaptadas para proyectos de cualquier tamaño.

Feature Flags

El código de una nueva funcionalidad se envía a producción pero se oculta tras un flag. Los Feature flags permiten desplegar código antes de que la funcionalidad esté lista para los usuarios y desactivarla instantáneamente en caso de problemas. Bibliotecas: LaunchDarkly, Firebase Remote Config, Unleash. Los Feature flags son un requisito obligatorio para CD en proyectos móviles.

Entorno de staging

Antes de enviar a producción, la compilación se despliega en staging — un entorno idéntico a producción pero con datos de prueba. Los ingenieros de QA verifican la funcionalidad en una compilación de staging instalada mediante TestFlight o la pista de Internal Testing. Si staging pasa — la compilación recibe aprobación para su envío a revisión en la tienda.

Notas de lanzamiento y changelog

CD genera automáticamente notas de lanzamiento basadas en los mensajes de commit. Los Conventional Commits (feat:, fix:, chore:) y las etiquetas Git en formato de versionado semántico permiten analizar el historial de cambios. Fastlane changelog_from_git_commits recopila los cambios entre las dos últimas etiquetas y los formatea para la tienda de aplicaciones.

Monitorización post-lanzamiento

CD no termina con la publicación — tras el lanzamiento, comienza la monitorización: tasa de fallos, tasa ANR para Android, tiempo de inicio, tasa de fallos en pagos. Si las métricas superan los límites normales — el pipeline CD debe revertir automáticamente el lanzamiento o notificar al equipo. Herramientas: Firebase Crashlytics, Sentry, New Relic.

// Ejemplo de Feature Flag con Firebase Remote Config para CD
class FeatureManager(
    private val remoteConfig: FirebaseRemoteConfig
) {
    fun isNewCheckoutEnabled(): Boolean {
        return remoteConfig.getBoolean("new_checkout_enabled")
    }

    fun getRecommendedVersion(): String {
        return remoteConfig.getString("minimum_app_version")
    }
}

// Uso en el código
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}