25. Integración, despliegue y entrega de software

25.1 Introducción

Construir una funcionalidad no es suficiente. Para que el software aporte valor, los cambios deben integrarse con el resto del sistema, verificarse, desplegarse en un ambiente adecuado y entregarse a usuarios o clientes de manera controlada.

La integración, el despliegue y la entrega conectan el trabajo de desarrollo con el uso real del producto. Si estas actividades se realizan de forma desordenada, pueden aparecer errores de configuración, versiones incorrectas, interrupciones del servicio y defectos que no se detectaron a tiempo.

En este tema veremos los conceptos principales y las buenas prácticas iniciales para pasar del código construido a una versión utilizable.

25.2 Integración

Integrar significa combinar cambios realizados por distintas personas o partes del sistema para verificar que funcionen juntos. Una funcionalidad puede funcionar de manera aislada y fallar al conectarse con otros módulos, datos o servicios.

La integración permite detectar problemas como:

  • Incompatibilidades entre módulos.
  • Errores en contratos de APIs.
  • Conflictos de datos.
  • Dependencias faltantes.
  • Configuraciones incorrectas.
  • Reglas duplicadas o inconsistentes.
  • Defectos que no aparecen en pruebas aisladas.
Idea clave: integrar temprano permite descubrir problemas cuando todavía son más fáciles de corregir.

25.3 Integración continua

La integración continua es una práctica en la que los cambios se integran con frecuencia y se verifican automáticamente. Normalmente incluye compilación, análisis, pruebas y otras validaciones cada vez que se incorporan cambios al repositorio.

Una integración continua puede ejecutar:

  • Instalación de dependencias.
  • Compilación o construcción del proyecto.
  • Formateo o revisión de estilo.
  • Análisis estático de código.
  • Pruebas unitarias.
  • Pruebas de integración.
  • Escaneo de vulnerabilidades.
  • Generación de artefactos de entrega.

El objetivo es obtener retroalimentación rápida sobre la calidad de los cambios.

25.4 Artefactos de software

Un artefacto es un resultado generado durante el proceso de construcción o entrega. Puede ser un archivo ejecutable, paquete, imagen, biblioteca, archivo comprimido, migración, documentación o configuración necesaria para desplegar.

Ejemplos:

  • Una aplicación compilada.
  • Una imagen de contenedor.
  • Un paquete instalable.
  • Un archivo de migración de base de datos.
  • Una versión empaquetada de una aplicación web.
  • Documentación generada para una API.

Los artefactos deben poder relacionarse con una versión del código para saber exactamente qué se está desplegando.

25.5 Ambientes

Un ambiente es un entorno donde el software se ejecuta. Los proyectos suelen usar varios ambientes para separar desarrollo, pruebas, validación y uso real.

Ambiente Propósito Características
Desarrollo Construir y probar cambios localmente. Puede tener datos simulados y configuración flexible.
Pruebas Validar funcionalidades antes de liberar. Debe parecerse lo suficiente al ambiente real.
Preproducción Ensayar despliegues y validaciones finales. Se acerca mucho a producción.
Producción Uso real por usuarios o clientes. Requiere estabilidad, seguridad, respaldo y monitoreo.

25.6 Configuración por ambiente

El mismo software puede necesitar configuraciones distintas según el ambiente: base de datos, credenciales, direcciones de servicios, modo de registro, claves, límites o integraciones externas.

Buenas prácticas:

  • No dejar credenciales dentro del código fuente.
  • Separar configuración de implementación.
  • Documentar variables y parámetros necesarios.
  • Usar datos de prueba en ambientes no productivos.
  • Evitar que pruebas afecten sistemas reales.
  • Controlar quién puede modificar configuración de producción.

Muchos errores de despliegue no están en el código, sino en configuración incorrecta.

25.7 Despliegue

Desplegar significa instalar, publicar o actualizar una versión del software en un ambiente. Puede ser un proceso manual, semiautomático o completamente automatizado.

Un despliegue puede incluir:

  • Seleccionar una versión o artefacto.
  • Preparar configuración.
  • Ejecutar migraciones de base de datos.
  • Publicar archivos o servicios.
  • Reiniciar procesos si corresponde.
  • Verificar que el sistema responde.
  • Revisar logs y monitoreo.
  • Comunicar cambios a usuarios o soporte.

El despliegue debe ser repetible. Si cada despliegue depende de pasos manuales improvisados, aumenta el riesgo de error.

25.8 Entrega

La entrega es el acto de poner una versión del software a disposición de usuarios, clientes, testers o un área de negocio. Puede incluir despliegue técnico, comunicación, capacitación, notas de versión y soporte inicial.

Una entrega puede ser:

  • Interna, para un equipo de pruebas.
  • Beta, para un grupo limitado de usuarios.
  • Productiva, para todos los usuarios.
  • Parcial, habilitada solo para ciertos roles o clientes.
  • Progresiva, aumentando el alcance gradualmente.

Entregar software no es solo copiar archivos. Es hacer que una versión pueda usarse de forma controlada y entendida.

25.9 Diferencia entre integración, despliegue y entrega

Concepto Pregunta principal Ejemplo
Integración ¿Los cambios funcionan con el resto del sistema? Combinar una rama y ejecutar pruebas automáticas.
Despliegue ¿La versión está instalada en un ambiente? Publicar la API en preproducción.
Entrega ¿La versión está disponible para ser usada o validada? Habilitar una nueva funcionalidad a usuarios finales.

25.10 Entrega continua y despliegue continuo

La entrega continua y el despliegue continuo son prácticas relacionadas con la automatización del camino desde el código hasta ambientes de uso.

Práctica Significado
Entrega continua El software se mantiene en estado listo para desplegar, pero la publicación puede requerir una aprobación manual.
Despliegue continuo Cada cambio que pasa las validaciones se despliega automáticamente a producción.

No todos los proyectos necesitan despliegue continuo. Sistemas críticos o regulados pueden requerir aprobaciones, ventanas de despliegue o validaciones adicionales.

25.11 Pipeline

Un pipeline es una secuencia automatizada de pasos para construir, verificar, empaquetar y desplegar software. Ayuda a que el proceso sea repetible y visible.

Un pipeline simple podría incluir:

  • Obtener el código del repositorio.
  • Instalar dependencias.
  • Ejecutar análisis de estilo.
  • Ejecutar pruebas.
  • Construir artefacto.
  • Publicar artefacto en un registro.
  • Desplegar en ambiente de pruebas.
  • Ejecutar verificaciones posteriores al despliegue.

25.12 Migraciones de base de datos

Muchas entregas requieren modificar la estructura o contenido de la base de datos. Esto debe gestionarse cuidadosamente porque los datos suelen ser uno de los activos más importantes del sistema.

Buenas prácticas:

  • Versionar migraciones junto con el código.
  • Probar migraciones en ambientes previos.
  • Considerar volumen real de datos.
  • Preparar respaldos antes de cambios riesgosos.
  • Definir cómo revertir o corregir si algo falla.
  • Evitar cambios incompatibles sin plan de transición.

Un despliegue puede fallar aunque el código sea correcto si la migración de datos no fue planificada.

25.13 Plan de reversión

Un plan de reversión define qué hacer si un despliegue falla. No todos los problemas pueden resolverse simplemente volviendo a la versión anterior, especialmente si hubo cambios en datos o integraciones.

Un plan puede incluir:

  • Volver a la versión anterior de la aplicación.
  • Restaurar respaldo de base de datos si corresponde.
  • Desactivar una funcionalidad mediante configuración.
  • Revertir migraciones compatibles.
  • Comunicar incidente a usuarios o soporte.
  • Registrar causa y acciones tomadas.

Planificar la reversión antes del despliegue reduce improvisación durante incidentes.

25.14 Verificación posterior al despliegue

Después de desplegar, conviene verificar que la versión funciona correctamente en el ambiente destino. Esto se conoce como validación posterior al despliegue o smoke test.

Puede incluir:

  • Confirmar que la aplicación responde.
  • Probar inicio de sesión.
  • Verificar funcionalidades críticas.
  • Revisar conexión a base de datos.
  • Confirmar integraciones principales.
  • Revisar logs de errores.
  • Monitorear rendimiento básico.

Esta verificación debe ser rápida, enfocada y repetible.

25.15 Notas de versión

Las notas de versión comunican qué cambia en una entrega. Pueden estar dirigidas a usuarios, soporte, equipo técnico o responsables del negocio.

Pueden incluir:

  • Nuevas funcionalidades.
  • Correcciones de defectos.
  • Cambios conocidos en comportamiento.
  • Impacto sobre usuarios.
  • Instrucciones de actualización.
  • Limitaciones conocidas.
  • Acciones necesarias después de desplegar.

Una buena comunicación evita sorpresas y ayuda a soporte a responder consultas.

25.16 Ejemplo: entrega de una nueva funcionalidad

Supongamos que se entrega la cancelación de reservas en un sistema de turnos.

  • El código se integra a la rama principal.
  • El pipeline ejecuta pruebas unitarias e integración.
  • Se construye un artefacto de versión.
  • Se despliega en ambiente de pruebas.
  • El equipo valida cancelación permitida, fuera de plazo y reserva inexistente.
  • Se prepara una nota de versión para soporte.
  • Se despliega en producción durante una ventana acordada.
  • Se ejecuta verificación posterior al despliegue.
  • Se monitorean errores y consultas de usuarios.

Este flujo muestra que una entrega controlada combina técnica, validación y comunicación.

25.17 Errores comunes

En integración, despliegue y entrega suelen aparecer errores como:

  • Integrar cambios grandes demasiado tarde.
  • Desplegar manualmente sin pasos documentados.
  • No probar en un ambiente similar a producción.
  • No versionar migraciones de base de datos.
  • Guardar configuraciones sensibles en el código.
  • No tener plan de reversión.
  • No verificar el sistema después de desplegar.
  • Entregar sin comunicar cambios a usuarios o soporte.
  • No relacionar una versión con el código exacto que fue desplegado.

25.18 Buenas prácticas

Algunas buenas prácticas son:

  • Integrar cambios con frecuencia.
  • Automatizar construcción y pruebas cuando sea posible.
  • Usar ambientes separados para desarrollo, pruebas y producción.
  • Separar configuración del código.
  • Versionar artefactos y migraciones.
  • Preparar despliegues repetibles.
  • Definir verificaciones posteriores al despliegue.
  • Tener plan de reversión para cambios riesgosos.
  • Comunicar entregas con claridad.
  • Monitorear el sistema después de publicar.

25.19 Qué debes recordar de este tema

  • Integrar significa comprobar que los cambios funcionan con el resto del sistema.
  • Desplegar significa instalar o publicar una versión en un ambiente.
  • Entregar significa poner una versión disponible para uso o validación.
  • Los ambientes separan desarrollo, pruebas, preproducción y producción.
  • La automatización reduce errores y hace el proceso más repetible.
  • Las migraciones y configuraciones son parte crítica del despliegue.
  • Una entrega responsable incluye verificación, comunicación y monitoreo.

25.20 Conclusión

Integración, despliegue y entrega son actividades esenciales para convertir código construido en software utilizable. Permiten pasar de cambios individuales a versiones verificadas, instaladas y disponibles para usuarios o clientes.

Para quien comienza, la idea principal es esta: entregar software profesionalmente no es solo publicar archivos, sino integrar, verificar, desplegar, comunicar y monitorear una versión de manera controlada.

En el próximo tema veremos una introducción a las pruebas de software, una práctica fundamental para obtener evidencia sobre el comportamiento y la calidad del sistema.