Cómo desplegar una aplicación desde GitHub

Un proceso de publicación confiable debe permitir versionar, revisar, publicar, verificar el resultado y revertir la versión cuando sea necesario. Sin estas etapas, cada actualización depende de tareas manuales en el servidor.

El problema

Las aplicaciones creadas con ayuda de IA suelen comenzar en el equipo de quien las desarrolló. El siguiente paso no es elegir la apariencia del panel, sino contar con un repositorio, un entorno y una forma segura de actualizar sin interrumpir la versión que ya está en producción.

Cómo funciona el camino hasta producción

• El código se mantiene en GitHub, con su historial, ramas y la versión que realmente llegó a producción.
• El entorno de producción mantiene la base de datos, el dominio, el certificado SSL y los secretos fuera del repositorio.
• El proceso de despliegue lee el repositorio, compila la aplicación y la publica en el servidor.
• Después del despliegue, se verifica que el servicio responda correctamente, no solo que el comando haya terminado.

Qué resuelve el panel SISNAWEB

En la operación gestionada, el panel permite desplegar desde GitHub con un proceso directo: el repositorio se convierte en una versión de producción sin que la empresa tenga que crear un pipeline desde cero ni abrir un ticket para volver a publicar. Esto no elimina la necesidad de mantener el repositorio en orden; elimina la dependencia de tareas manuales en el servidor.

Principales desafíos

• Secretos incluidos en el código, como claves de API o contraseñas de bases de datos, que nunca deben publicarse en GitHub.
• Una compilación que funciona en el equipo de desarrollo y falla en el servidor por una dependencia no declarada.
• Una migración de base de datos durante el despliegue sin plan de reversión.
• Dos entornos similares sin una forma clara de identificar qué commit está en producción.

Errores comunes

Entre los errores comunes están publicar directamente desde una carpeta local, usar FTP como proceso, incluir el archivo .env en el repositorio, confundir etiquetas con ramas y almacenar prompts junto con claves del proveedor.

Experiencia práctica

En los proyectos que operamos, el principal beneficio no es contar con una integración continua sofisticada, sino permitir que la empresa actualice producción desde el repositorio que ya utiliza, sin depender de una sola persona con acceso root. Cuando el despliegue es repetible, se puede investigar qué commit se publicó, a qué hora y qué cambió. Cuando no lo es, también se pierde esa trazabilidad.

Cuándo utilizar

Siempre que exista una aplicación que necesita vivir más allá de la computadora de quien desarrolló — sistema interno, API, agente, panel, tienda, SaaS. Si el código aún no está en GitHub, el primer paso es versionar. Si ya está, el paso es conectar el repositorio a un entorno de verdad.