NexusCMS: Nuevo sistema de actualizaciones integrado

Hay avances que se notan al instante y otros que se notan cuando todo sigue funcionando bien con el paso del tiempo.

El nuevo sistema de actualizaciones de NexusCMS entra en esa segunda categoria: no busca solo "actualizar version", sino hacerlo con controles de seguridad, validaciones previas, trazabilidad y flexibilidad para distintos entornos.

Tras revisar su implementacion completa en el core de NexusCMS, este es el resumen de como esta construido y por que representa una mejora importante para administradores y desarrolladores.

Objetivo del nuevo updater

El sistema fue disenado para cubrir escenarios reales de despliegue:

Instalaciones con repositorio Git disponible.
Instalaciones sin .git, donde solo se puede actualizar por ZIP.
Repositorios publicos y privados.
Entornos con necesidad de mantenimiento controlado y registro detallado.

En lugar de depender de un unico flujo, NexusCMS detecta el metodo adecuado y aplica la actualizacion de forma guiada.

Que incorpora el sistema

1) UpdateService centralizado

El corazon del sistema esta en un servicio dedicado que concentra toda la logica de actualizaciones.

Desde ahi se resuelven tareas como:

Consulta de releases en GitHub API.
Filtrado por canal de versiones (stable, beta o any).
Comparacion de version actual vs version disponible.
Ejecucion del update por Git o por ZIP.
Tareas post-update (migraciones, limpieza de caches, version en .env).
Registro historico del resultado.

Esta separacion evita logica duplicada entre controlador, vistas y comandos, y deja el flujo mucho mas mantenible.

2) Canales de release configurables

El updater permite elegir que tipo de versiones considerar al buscar novedades:

stable: solo releases finales.
beta: incluye pre-releases.
any: acepta cualquier release publicada.

Esto permite trabajar con estrategias distintas segun el entorno:

Produccion conservadora con stable.
QA o staging con beta.
Pruebas internas con any para validar builds tempranas.

3) Deteccion automatica del metodo de actualizacion

NexusCMS no obliga a un solo camino:

Si existe carpeta .git y el binario git esta disponible, usa metodo Git.
Si no, usa metodo ZIP.

Con esto, el mismo sistema funciona tanto en instalaciones de desarrollo como en despliegues donde el codigo llega empaquetado sin historial Git.

4) Pre-flight checks antes de aplicar cambios

Antes de actualizar, el sistema valida condiciones del entorno para reducir errores en caliente.

Entre las comprobaciones clave estan:

Permisos de escritura en base_path y storage.
Disponibilidad de exec() en PHP.
Si el metodo es Git: presencia del binario git.
Si el metodo es ZIP: espacio en disco y extension ZipArchive.

Este bloque de validacion aparece tambien en el panel admin, facilitando detectar problemas antes de pulsar "Apply".

5) Flujo de ejecucion completo y seguro

Cuando se aplica un update, el proceso sigue una secuencia clara:

Activar mantenimiento (si esta habilitado en settings).
Aplicar archivos por Git o por ZIP.
Ejecutar composer install en flujo ZIP cuando corresponde.
Correr migraciones forzadas.
Limpiar caches con optimize:clear.
Actualizar APP_VERSION en .env.
Restaurar el sitio con artisan up.

Ademas, si algo falla, el sistema intenta sacar la aplicacion de mantenimiento igualmente para evitar dejar el sitio bloqueado.

6) Soporte Git y soporte ZIP bien definidos

Via Git

El updater crea un remote temporal, obtiene tags y hace checkout de la version objetivo. Este flujo es ideal para instalaciones con control de versiones activo.

Via ZIP

El updater descarga el zipball oficial de GitHub, extrae en temporal y copia al root del proyecto. Durante esa copia respeta rutas protegidas para no romper configuracion ni datos locales.

Entre los paths excluidos por defecto estan:

.env
vendor
node_modules
storage
public/uploads
public/storage

Este detalle es clave para mantener integridad de entorno durante actualizaciones por paquete.

7) Historial persistente de actualizaciones

Cada ejecucion queda registrada en base de datos mediante update_logs, guardando:

Version origen y version destino.
Metodo usado (git o zip).
Estado final (success o failed).
Log textual completo del proceso.
Usuario que ejecuto la accion.

Esto aporta trazabilidad real: se puede auditar que paso, cuando paso y quien lo lanzo.

8) Panel admin + protecciones del endpoint

La parte de UI en Admin incluye:

Estado de version actual y version mas reciente.
Notas de release.
Resultado de pre-flight checks.
Historial de updates.
Modal de confirmacion con advertencias.

En backend, la accion de aplicar update valida:

Que el updater este habilitado.
Que exista tag.
Que el tag cumpla un patron permitido.
Permisos de acceso via middleware de configuracion.

El flujo de peticion incluye token CSRF, reforzando la seguridad del proceso desde el panel.

Impacto practico

Este sistema no solo agrega una "funcion nueva"; mejora todo el ciclo operativo de mantenimiento:

Menor friccion para mantener NexusCMS al dia.
Menor riesgo de fallos por entornos incompletos.
Mejor control de cambios en equipos.
Base mas solida para automatizar futuras estrategias de despliegue.

En resumen: actualizar deja de ser una tarea manual y opaca, y pasa a ser un flujo controlado, visible y mucho mas seguro para el proyecto.