Versionado y publicación de cambios
RestaPro es un SaaS en continuous deployment: cada commit en main puede llegar a producción tras revisión. No hay versiones discretas que tengas que descargar e instalar — siempre estás en la última.
Build ID
Cada despliegue genera un identificador único (hash de Git). Está visible en:
- Meta tag del HTML:
<meta name="restapro:build-id" content="abc1234def56"> - Footer del backoffice (en algunos puntos).
- Inspector del navegador (F12 → pestaña Elements).
Si el soporte te pregunta "¿qué versión tienes?", basta con que mires el meta tag.
Por qué no hay versionado semántico
Software tradicional: v1.0 → v1.1 → v2.0, descargas, instalas, esperas a la siguiente release.
SaaS continuo: cambios pequeños y frecuentes que llegan automáticamente. El versionado semántico no aporta valor cuando no decides cuándo actualizar.
Cómo te enteras de los cambios
Novedades públicas
Cada lanzamiento importante se publica en /changelog con:
- Qué cambió
- Por qué
- Si afecta tu flujo
Email a workspaces
Los cambios destacados que afecten tu día a día se anuncian por email a la cuenta. Sin correo basura — solo lo relevante para gestionar tu restaurante.
Cambios rupturistas
Política:
- Notificación con 30 días de antelación si algo cambia y podría afectar tu integración o flujos públicos.
- Mensaje claro: qué cambia, por qué, qué hay que hacer (si algo).
- Período de transición: en cambios críticos, mantenemos la versión antigua en paralelo mientras migras.
La mayoría de cambios son aditivos y transparentes — empiezan a funcionar sin que tengas que hacer nada.
Rollback en Vercel
El frontend se publica en Vercel. Antes de promover un deployment se debe comprobar el SHA, los checks de CI requeridos, version.json, los assets y el comportamiento en navegador.
El smoke HTTP verifica distribución y versión; un HTML 200 no acredita una carta cargada ni un login correcto. El workflow del candidato añade pruebas de navegador con datos sintéticos y sin red externa. Las pruebas de autenticación/MFA, Admin y operación con backend real necesitan staging aislado.
Si un despliegue falla, el responsable puede seleccionar una versión anterior compatible en Vercel y comprobar sus dominios. Esto no revierte migraciones ni datos. No se ha acreditado rollback automático ni recuperación en cinco minutos. Los snapshots de /opt/backups del servidor antiguo no forman parte del flujo vigente.
Incidentes y comunicación
- Errores se capturan en Sentry con contexto (userId, restaurantId, breadcrumb).
- Si hay incidente de servicio, comunicación en
soporte@restapro.esy email proactivo. - Estado del servicio: en futuro habrá una página de status público.
Resumen
| RestaPro | Software tradicional | |
|---|---|---|
| Versiones | Continuous, build ID = git SHA | v1.0, v1.1, v2.0 |
| Actualización | Automática, sin intervención | Descarga, instala |
| Cadencia | Diario / semanal | Trimestral / anual |
| Breaking changes | 30 días de aviso, raros | Nuevas major versions |
| Rollback | Deployment anterior de Vercel, tras evaluar compatibilidad | Reinstalar versión anterior |