Es común que equipos de trabajo que no están acostumbrados a trabajar en simultáneo en el desarrollo de un proyecto Drupal terminen sobreescribiendo su código constantemente al no contar con un flujo de publicación de cambios en un entorno centralizado.
A continuación listamos el proceso que recomendamos de un flujo de publicación:
Introducción
Vamos a asumir que el equipo está trabajando sobre una misma rama porque su labor está en componentes distintos y podrían tener conflictos solo a nivel de configuraciones.
En equipos de trabajo mayores lo más probable es que se trabaje en ramas independientes por funcionalidad pero al final deben converger todos esos desarrollos a una misma rama como la master.
Conocimientos previos requeridos
- Drush.
- Composer.
- Git.
- Gestión de configuraciones en Drupal.
Instrucciones
1. Exportar las configuraciones.
Usamos Drush para esta tarea, los archivos son exportados al directorio que se haya definido en el settings.php, por lo regular en config/sync pero podría ser otro.
drush cex
2. Agregar los archivos a confirmar vía Git.
Con el siguiente comando agregue todos los archivos que han cambiado en el directorio a partir del directorio donde se encuentre, si lo ejecuta en la carpeta raíz del repositorio podrá agregar todos los que han sufrido cambios como las configuraciones o código que haya creado o modificado.
git add.
3. Confirmación de archivos con Git.
En este punto ya ha salvado todos los cambios que ha realizado, tanto las configuraciones como el código creado o modificado.
git commit -m ''
4. Traer a repositorio local los cambios en el repositorio remoto.
Debemos tener en cuenta que mientras trabajamos en nuestras funcionalidades en nuestro entorno local, el equipo también está trabajando en otras tareas y es muy probable que coincidamos en los archivos de código o configuraciones, por eso debemos traerlos a nuestro entorno local, para que podamos evidenciar esos posibles conflictos previamente.
git pull origin
5. Solución de conflictos en caso de haberlos.
Como mencionamos en el paso anterior, es muy probable que al traer cambios encontremos conflictos, este es el paso para encargarnos de esa tarea, quizá ya usted tenga experiencia en esa tarea así que solo tenga en cuenta algunos tips.
- Identifique los archivos en conflicto.
- Analice caso a caso y asegúrese de validar muy bien los cambios que va a aceptar.
- En caso de no saber si aceptar o no algún código que no es suyo, comuníquese con el desarrollador que construyó las líneas con las que tiene conflictos (si es posible).
- Una vez resueltos los conflictos, si le tomó mucho tiempo, quizá puede considerar volver a hacer un pull para asegurarse de que los últimos cambios en remoto no tienen conflictos adicionales.
6. Ejecute los cambios que puede tener Composer.
Salvo casos excepcionales, Composer es el método que usamos para instalar módulos, librerías o parches. Dado que hemos traído cambios hechos por el equipo, es muy probable que lo hayan usado, así que es mejor acostumbrarnos a siempre aplicarlo en nuestro entorno después de un <.
composer install
7. Instalación de las nuevas configuraciones.
Con el Git pull también es muy probable que nos hayamos traído nuevas configuraciones que ha trabajado el equipo, es muy importante que las importemos en nuestro entorno local para que la próxima vez que exportemos configuraciones, estas vayan incluidas, si no lo hacemos, es muy probable que luego terminemos sobreescribiendo las configuraciones de nuestros compañeros con nuestras configuraciones desactualizadas.
Este ejercicio también será muy útil para confirmar que cuando se importen las configuraciones en el entorno remoto no nos vamos a encontrar con sorpresas inesperadas.
drush cim
8. Envío de confirmaciones a repositorio y ambiente remoto.
Ahora estamos listos, podemos enviar nuestros ajustes con confianza al repositorio remoto.
git push origin
9. Limpiar caché en el entorno local.
Drupal es una herramienta que trabaja con la caché activada por defecto, es probable que una vez haya realizado toda esta tarea, sea mejor que limpie la caché por si hay nuevos directorios que deban ser leídos o información en la base de datos que deba ser renovada.
drush cr
Estos pasos que se han descrito resuelven la mayoría de inconvenientes posibles al momento de trabajar en varias funcionalidades al tiempo, sin embargo, podrían presentarse escenarios en donde el error se produce por una mala resolución de conflictos o falta de comunicación del equipo.
Contribución original al equipo de SeeD por William Bautista.