Caso de estudio

Plataforma de despliegue y auto‑actualización multi‑OS

Pipeline en Ubuntu que compila, empaqueta y distribuye un launcher y una app de escritorio para Windows, macOS y Linux usando Wine, SSH y manifests JSON.

2025Arquitectura, backend y tooling de despliegue

PythonPyInstallerBashWineUbuntu Servernginx/Apache

01 · Contexto

Contexto y reto

La aplicación de escritorio se instalaba manualmente en varias máquinas y sistemas operativos, lo que generaba versiones desalineadas, pasos repetitivos y mucho soporte cada vez que salía un nuevo release.

El objetivo era unificar el despliegue en un solo pipeline que manejara Windows, macOS y Linux, sin depender de procesos manuales ni asistentes gráficos en cada equipo.

Instalaciones manuales→Versiones mezcladas→Incidentes y soporte

▍

02 · Arquitectura

Arquitectura general

En el centro hay un servidor Ubuntu que aloja el repositorio, los entornos de build con PyInstaller y los scripts en Bash que automatizan el pull, el empaquetado y la publicación de artefactos.

Apache/nginx se encargan de servir las carpetas de builds y manifests JSON, de forma que el launcher y los navegadores acceden siempre a la última versión estable mediante rutas limpias como [translate:/builds/] y [translate:/launcher/].

Repo Git→Servidor Ubuntu→Apache / nginx→Clientes LAN

▍

03 · Pipeline

Pipeline multi‑plataforma

El pipeline automatiza el build para Linux, Windows y macOS en cadena: un script detecta cambios, ejecuta PyInstaller en cada entorno y deja los artefactos listos en carpetas con timestamp y un enlace simbólico a la última versión.

Un script tipo [translate:auto_pull.sh] sincroniza el repositorio y dispara el [translate:build.sh] cuando detecta cambios en la rama principal.
Para Linux, PyInstaller se ejecuta de forma nativa; para Windows, el build corre dentro de Wine, ajustando el [translate:.spec] para incluir DLLs como [translate:python312.dll] en el bundle.
Para macOS, el servidor se conecta por SSH a una Mac disponible, ejecuta el empaquetado con el [translate:.spec] correcto y luego sincroniza los artefactos de vuelta al servidor.
Cada build se guarda en carpetas con timestamp ([translate:dist_YYYYMMDDHHMMSS]) y se actualiza un symlink [translate:dist_latest] que siempre apunta a la versión más reciente.

Commit en main→auto_pull.sh→build.sh (Linux / Win / Mac)→Builds + manifests

▍

04 · Launcher

Launcher auto‑actualizable

El launcher se empaqueta como un único ejecutable [translate:(--onefile)], pensado para que el usuario solo descargue un archivo ligero y no tenga que manipular carpetas internas ni dependencias externas.

Al iniciarse, consulta el manifest JSON publicado en el servidor, compara versiones y hashes con la instalación local y descarga únicamente los binarios que cambiaron antes de lanzar la aplicación principal.

Launcher→GET manifest→Descarga diffs→Ejecuta app

▍

05 · Manifests

Manifests y distribución

Un script dedicado genera los manifests JSON para cada plataforma recorriendo la carpeta [translate:dist_latest], detectando artefactos de Windows, macOS y Linux y registrando nombre, tamaño, hashes y versión.

Gracias a la configuración de Apache/nginx, tanto los ejecutables como los manifests se pueden verificar fácilmente vía navegador o [translate:curl/wget], lo que facilitó mucho el debug de rutas y permisos durante la puesta a punto.

Builds→generate_manifest.sh→Manifests JSON→Servidor web

▍

06 · Resultado

Resultado

El nuevo sistema transformó un proceso manual y frágil en un pipeline automatizado donde un solo launcher sirve como puerta de entrada a builds consistentes para los tres sistemas operativos.

Esto redujo drásticamente el tiempo de soporte, eliminó la fragmentación de versiones entre equipos y acercó la experiencia de actualización a la de plataformas como Steam o Discord, pero hecha a medida para el proyecto.

Pipeline automatizado→Launcher único→Usuarios siempre al día

▍

Arrastra horizontalmente o usa las flechas para recorrer este caso.