Desarrollo y bases de datos

Automatización de tareas de deploy en Git con el fichero .cpanel.yml

Revisado el 3 min de lectura git despliegues

El archivo .cpanel.yml define las tareas que ejecuta el despliegue Git de cPanel. Debe estar versionado en la raíz del repositorio, con ese nombre exacto.

Si prefieres configurar scripts, releases y automatización desde el área de clientes, consulta Deploy+.

Ejemplo para dos archivos estáticos

Este ejemplo copia dos archivos del repositorio a una carpeta de pruebas que ya debe existir. Sustituye la ruta por la tuya y comprueba antes que no contiene archivos que quieras conservar con esos nombres:

---
deployment:
  tasks:
    - /bin/cp -- index.html style.css /home/usuario_cpanel/public_html/pruebas/

La copia puede sobrescribir los dos archivos de destino. No sincroniza una web completa, no elimina archivos antiguos y no cambia ambos archivos de forma atómica. Para varias operaciones dependientes, llama a un script con comprobación de errores, como en el ejemplo de Laravel.

Push y pull: cuándo se ejecuta

Push hacia el repositorio de cPanel: cPanel puede ejecutar las tareas mediante su hook si el repositorio cumple los requisitos de despliegue. Confirma el repositorio y la rama a la que estás enviando código.

Pull desde GitHub u otro remoto: en Git Version Control > Manage > Pull or Deploy, Update from Remote actualiza el clon. Después debes utilizar Deploy HEAD Commit para ejecutar .cpanel.yml. Un push a GitHub no inicia automáticamente este proceso en cPanel.

Solicitarlo desde la API o cron

Para un repositorio ya gestionado por cPanel:

/usr/local/cpanel/bin/uapi --output=jsonpretty VersionControlDeployment create \
  repository_root='/home/usuario_cpanel/repositories/proyecto'

La llamada solicita un despliegue del código que está en el repositorio; no sustituye el paso de actualizar desde el remoto. Comprueba result.status y sigue el registro o la tarea hasta conocer su resultado final.

No añadas la llamada a cron sin un control que evite solapamientos durante toda la ejecución. Un bloqueo que se libera cuando la API devuelve la tarea en cola puede terminar antes que el despliegue.

Comprobar y deshacer

Después del despliegue, revisa los logs, el commit y el contenido servido. Una tarea puede haber modificado datos antes de fallar; no asumas que todo se ha deshecho.

Prepara la recuperación del contenido sobrescrito y conserva aparte los archivos persistentes. Para cambios de base de datos, define una reversión específica: volver a un commit no recupera los datos que una tarea haya eliminado.

También te puede ayudar

¿Algo no cuadra o ha cambiado? Cuéntanoslo y lo revisamos.