Control de versiones con ganchos, migration y bash

Estoy tratando de encontrar una buena solución para el control de la migration entre el wamp local y la lámpara del server que incluye git y Drupal.

Ya encontré una buena solución para el control de la migration con CodeIgniter gracias a la class Migration . Entonces puedo utilizar el gancho post-receive y simplemente ejecutar php path/to/codeigniter/index.php migrate/index y simplemente actualiza el layout de la database junto con los files.

Sin embargo, por lo que he visto hasta ahora con Drupal, esto es un poco más complicado. Actualmente estoy considerando de alguna manera almacenar los commands Drush para habilitar nuevos modules y tal. La idea sería tener un sistema similar a Migration, que simplemente ejecuto con post-receive y los nuevos modules se habilitan a través de drush en -y new_module cuyo command se guarda en algún lugar.

El flujo ideal ilustrado aquí:

Flujo ideal

Lo que supongo que necesitaría para completar este flujo es tener el script bash ejecutado por post-receive , search algún file llamado por ejemplo 001.txt dentro de un directory llamado drush_commands , y basado en una variable que he guardado en un file mencionado en .gitignore , ejecuta los files con un número más alto que el valor guardado, luego establece el valor en el número más alto entre los files ejecutados.

Pregunta

Sin embargo, no estoy seguro de cómo hacerlo y si incluso es posible hacerlo con los scripts bash de manera ideal. ¿Es este enfoque el ideal y cómo funcionaría el script bash, o conoces alguna forma mejor de tener los mismos modules habilitados (y otras cosas drush) tanto en mi wamp local como en el server al push ?

Pregunta de bonificación: ¿podría utilizar este enfoque para manejar cambios en los datos de campo, tipo de contenido y demás? Tengo algunos problemas para entender exactamente cómo puedo sincronizar la estructura general entre la versión local y la versión en vivo.

Esto es absolutamente posible tanto en teoría como en la práctica, aunque no intentaría completarlo por completo utilizando un enlace posterior a la recepción.

La solución ideal sería tener un server de CI, por ejemplo, Jenkins ( http://jenkins-ci.org/ ) escuchando saturado con un trabajo configurado para manejar las migraciones y usar el enlace posterior a la recepción para activar este trabajo a través de la interfaz CLI. o una request de cURL. Esto le quita la carga de una compilation fuera de Git (donde no pertenece) y dentro de CI (donde lo hace).

Existen numerosas soluciones de CI decentes, tanto gratuitas como patentadas, que se encargarán de todo esto con cierta configuration básica.

El trabajo configurado cuando se activa, verifica su repository (basado en una twig que usted especifique) en su propio directory del espacio de trabajo y luego puede llamar a un script para comstackrlo como una aplicación.

 # post-receive hook curl http://my.ci-server.local/job/drush_command/buildWithParameters?&GITBRANCH=$GIT_BRANCH&delay=0 
  • my.ci-server.local Su installation de server de CI instalada localmente
  • drush_command sería el nombre de tu trabajo
  • GIT_BRANCH es el nombre de la twig para comstackr (¿desarrollar por defecto?)

Dentro del trabajo de CI, entonces tendría una secuencia de commands que ejecuta pasos similares a los siguientes:

 # GitIgnore file savedValue:0001 # bash script savedValue=$(cat $WORKSPACE/.gitignore | grep 'savedValue' | cut -d: -f2); newValue=$(savedValue); for file in $(ls $WORKSPACE/drush_commands); do currentValue=$(echo $file | cut -d. -f1); if [ $currentValue -gt $savedValue ] ; then drush en -y "${currentValue}.txt}"; if [ $currentValue > $newValue ] ; then newValue=$currentValue; fi fi done sed -i '' "s/savedValue.*/savedValue:$newValue/" $WORKSPACE/.gitignore; 

Podrías ampliar esto para manejar los cambios a los datos haciendo que se llame a un script separado después del bucle que busca otros scripts para ejecutar, que luego recogería los cambios para llevarlos a cabo desde un directory separado.

Un par de puntos:

  • No agregaría el valor guardado al file .gitignore; este no es realmente el lugar adecuado. Utilice un file de configuration separado (por ejemplo, conf/last_enabled ) para este tipo de información.
  • El bucle no funcionará terriblemente bien si tiene files dentro del directory drush_commands que no se llaman '001.txt 002.txt', etc. Deberá filtrarlos para asegurarse de estar obteniendo lo último.

Espero que esto ayude.