version-control – ¿Cuál es la mejor práctica para actualizar el núcleo de Drupal sin romper el repositorio de Git y el sitio web de producción?

Pregunta:

Tengo un repositorio de Git en el que todo mi código está en la rama maestra, y anteriormente solo ignoraba todos los archivos de Drupal, por lo que mantuve una separación estricta entre el código que escribí (o modifiqué o podría modificar) y el código que podría generarse con Drush o lo que sea.

Esto parecía una buena estrategia hasta que tuve que actualizar Drupal. Me di cuenta de que quería poder retroceder si las cosas iban mal, y qué mejor herramienta para usar que Git para hacer eso. Pensé que esta sería la situación perfecta para una rama de características, así que hice una rama drupal-7.14 , le di su propio .gitignore para ignorar todos mis archivos de código y configuración y prestar atención solo a los archivos que son parte de Drupal instalar que no tocaría. Hice una actualización a mano (descargar, descomprimir, descomprimir, copiar), clasificando casos límite como robots.txt y .htaccess, y sobrescribiendo el .gitignore de Drupal con el mío. Arreglé algunas configuraciones que funcionaban con 7.14 pero no con 7.15, para recuperarme de un error 500, y luego todo parecía perfecto. drupal-7.15 el nombre de la rama a drupal-7.15 y estaba a punto de seguir felizmente mi camino.

Hasta que me di cuenta de lo que había hecho sin darme cuenta: los archivos que antes no había sido rastreados por mi rama maestra pero que estaban en el directorio de trabajo ahora se eliminaron del directorio de trabajo cuando revisé el maestro, ¡ya que ya no eran archivos sin seguimiento! ¡Oh!

Si drupal-7.15 rama drupal-7.15 con master, perderé la separación del código.

Probablemente haya alguna forma de convertir una rama en un submódulo. Suponiendo que eso sea posible, esa podría ser la mejor estrategia. Sabía antes de hacer esto que los submódulos eran la solución "correcta", pero como no me di cuenta del efecto secundario de usar ramas para archivos previamente sin seguimiento, decidí tomar atajos e ir por ese camino. (Además, todos los enfoques que he visto para usar submódulos con Drupal asumen que está comenzando un nuevo proyecto y Drupal será la rama maestra. No es deseable para mí hacer que el código de otra persona sea la rama maestra, y ya tenía un repositorio con una rama maestra. Parecía que sería innecesariamente complicado solo hacer una actualización).

Puede haber alguna otra solución en la que no he pensado.

¿Cómo puedo recuperarme mejor de esto con la menor cantidad de inconvenientes posibles?

ACTUALIZACIÓN : Esto está en desarrollo (en una máquina virtual Linux en mi computadora portátil) y aún no ha entrado en producción. Para cuando entremos en producción, planeo tener todo envuelto en módulos de funciones, pero eso aún no está en su lugar.

ACTUALIZACIÓN 2 : Es posible que los submódulos no funcionen. Según Pro Git , "los submódulos te permiten mantener un repositorio Git como un subdirectorio de otro repositorio Git". Drupal no proporciona una separación tan agradable. En lugar de que todo el código de Drupal esté en un subdirectorio, la relación es más o menos invertida, pero aún no hay una separación limpia, ya que es posible que esté editando su .htaccess y robots.txt, por lo que su código y el repositorio de Drupal se mezclan. Estoy buscando una solución a este problema .

Respuesta:

Parece de la discusión anterior que su pregunta no se trata de arreglar su repositorio de git, sino de mantener un sitio Drupal en git y cómo funciona eso con las actualizaciones principales.

Creo que la práctica estándar es, de hecho, mantener todos los archivos en su repositorio, incluido el núcleo de Drupal. La separación del código Drupal del código personalizado parece una buena idea, pero no creo que sea necesario, y no veo qué ventajas le brinda. También parece suponer que nunca querrá parchear el núcleo (o tendrá que hacerlo como parte de su implementación), lo cual, si bien no es la mejor práctica, definitivamente es algo que desea poder hacer si algo se rompe. en producción. Mantener sus confirmaciones agradables y enfocadas también ayuda a obtener este tipo de separación.

La solución que he usado es mantener todo el código en el mismo repositorio, poner tanto como sea posible en Funciones u otros tipos de exportaciones / código / configuración, y mantener una lista de parches que deben aplicarse fuera del -box core y contrib.

Cuando actualice el núcleo, comience en su entorno de desarrollo:

• Asegúrese de que el directorio de trabajo esté limpio
• drush sql-dump última base de datos ( drush sql-dump ). Haga una confirmación con el volcado o guárdelo en un lugar seguro.
• Actualizar núcleo ( drush up drupal )
• Confirme todos los cambios.
• Verifique el archivo de parches. Si es necesario aplicar algún parche, aplíquelo y realice otra confirmación
• Ejecute update.php si es necesario (ya lo hizo si usó drush para la actualización)
• Pruebe su sitio de desarrollo. Si todo está bien, envíe el código a producción. Ejecute drush updb en producción.
• Si hay un problema y necesita revertir, revertir o restablecer su repositorio ( git reset --hard HEAD~2 debería hacerlo), o revertir las dos confirmaciones si desea mantener el historial. Reemplace su base de datos con el volcado.

El volcado de la base de datos es necesario porque, de lo contrario, no puede deshacer los cambios realizados en la base de datos mediante actualizaciones. También puede realizar la actualización en una rama, en cuyo caso revertir solo significa revisar el maestro. Es un poco desaconsejable si está trabajando en un sitio de desarrollo porque realmente no puede volver al maestro y seguir trabajando allí en paralelo debido a la base de datos.

El uso de este flujo de trabajo más simple del lado de git le permitirá usar todo el poder de git cuando lo necesite sin la complicación de los submódulos, etc. Si esto no parece adecuado, ¿podría explicar por qué necesita una mayor separación de código?