Enviado por Antonio el Lun, 11/10/2021

Buenos días.

Tengo el siguiente entorno:

  • pc local con Windows 10, wamp y drupal 8.9.19 con composer. Aquí hago las pruebas necesarias, añado módulos, actualizo módulos y core, siempre con composer.
  • Servidor de desarrollo: servidor Linux idéntico al de producción. Subo los cambios que hago en mi pc local para probar que todo funciona bien y poder subir a producción. Cada vez que subo el proyecto, borro todos los directorios y archivos, y lo subo todo de nuevo, y también elimino la base de datos, la vuelvo a crear y subo el dump que creé en mi pc. Pero hacer esto en producción no es viable, claro. No puedo correr composer en servidor de desarrollo y producción. Sí puedo usar drush para borrar caches, hacer updb y correr el cron.
  • Servidor de producción: el primer despliegue fue en limpio y sin problema, pero ¿Cómo hago ahora para poder volver a subir los cambios que vaya haciendo? Porque está claro que no me puedo hacer como en el servidor de desarrollo, borrando todo y volviendo a subir todo.

El problema es que no sé muy bien como proceder. Es decir, cuando hago un composer update en local, en desarrollo lo subo todo eliminando todo lo de desarrollo, pero no no puedo hacer esto en producción.

Muchas gracias 

Un saludo

 

  1. Si en el servidor no puedes ejecutar composer, te va a tocar subir manualmente todo el codigo, del core, la carpeta vendor, los modulos y los themes contibuidos que utilices.

    Si en el servidor si puedes utilizar composer (por linea de comandos o desde la interfaz, de echo, puedes descargarte tu mismo composer en el servidor desde la web (https://getcomposer.org/download/), que es un archivo llamado composer.phar y ejecutarlo con "php composer.phar install" por ejemplo), tienes que tener tanto el composer.json como el composer.lock subidos al servidor y ejecutar "composer install", ese comando leera del composer.lock los paquetes a instalar y su version, instalandotelos en el servidor.

    Los cambios de configuracion que realices en tu local (tu entorno de desarrollo), los puedes subir con el sistema de configuracion que tiene Drupal, aqui te dejo un video sobre como usarlo: https://www.youtube.com/watch?v=A-hQ3KD8Pl8

    Saludos :)

  2. De nuevo muchas gracias.

    Composer lo tengo capado en el servidor, así que tocará subir a mano.

    Lo que voy a probar es a pasar el portal a estático con Tome. Así, mientras subo los cambios/actualizaciones, la gente puede seguir navegando sin notar aparentemente el cambio. Y mientras actualizo el portal. 

    Muchas gracias por tu ayuda Borja.

    Un saludo

  3. Si el portal es totalmente estático, puedes dejarlo siempre con Tome, generas todo local o en cualquier instancia y luego subir cambios a Netlify (por ejemplo) desde un repositorio automáticamente.

    Algunas personas me han recomendado que en producción nada de Git ni Composer ni nada. La solución creo que va con algo como AWS Codedeploy o similar, que sería como un rsync. Todavía tengo la duda de si tenían razón o no. Argumentaban que era por seguridad y los puertos, cuando Git por ejemplo usa el puerto del SSH, el mismo que usan para entrar a la instancia, nunca entendí.

    No soy experto, pero me parece que sobre el tema CICD hay una laguna de conocimiento en Drupal. Ejecutar composer en cualquier instancia sería lo más básico, pero todavía sigue siendo un poco manual (respaldos, entrar a la instancia, comandos, etc)

  4. Chapa va xD

    El problema con los despliegues y/o el CICD, es que dependes mucho del alojamiento que tengas, de tus requisitos, de tus conocimientos...

    Muchas veces me han pedido un video sobre como subir un Drupal a prod y es algo imposible de explicar, porque hay miles de opciones, y cada alojamiento tiene unas funciones y otras limitaciones; y hace un par de años publiqué un video, sobre como hacerlo con Plesk, Bitbucket y Composer, pero me venia gente, preguntando de como hacerlo sin composer, sin git, con composer pero sin git, con git pero sin composer, queriendo subirlo por ftp, con rsync, con docker, ejecutando test de phpunit, sobre como hacerlo en X alojamiento/panel en concreto ... Terminé por quitar el video, ya que mas que aclarar, liaba a la gente y se llenaba de comentarios cada uno pidiendo una solución especifica.

    Hay empresas que durante el deploy ejecutan test, otros no, otras utilizan phpcs para comprobar el codigo, o sonarqube (no me acuerdo de mas ahora mismo), al fin y al cabo es un mundo.

    Yo no hago los deploys igual para esta web, que para la del curro; por ejemplo, aquí cuando hago el merge a la rama de prod del repositorio, el servidor automaticamente descarga todo, hace un backup de la bbdd, importa configuracion, actualiza la base de datos y limpia cache. En el curro utilizamos docker, y la importacion de la configuracion y actualizacion de la bbdd, se hacen manualmente (hay razones para hacerlo manual) entre otras muchas cosas.

    Por un lado está el desconocimiento como comentas Rafa3l, y por otro lado que es tan amplio y hay tantas variables, que para gente nueva es excesivamente complicado.