Quelle est la meilleure pratique pour mettre à niveau Drupal core sans casser le dépôt Git et le site de production
J'ai un référentiel Git dans lequel tout mon code est dans la branche master, et j'ignorais auparavant tous les fichiers Drupal, afin de garder une séparation stricte entre le code que j'ai écrit (ou modifié ou pourrait modifier) et le code qui pourrait être généré avec Drush ou autre.
Cela semblait être une bonne stratégie jusqu'à ce que je doive mettre à jour Drupal. J'ai réalisé que je voulais pouvoir revenir en arrière si les choses allaient mal, et quel meilleur outil à utiliser que Git pour le faire. Je me suis dit que ce serait la situation parfaite pour une branche de fonctionnalité, alors j'ai fait un drupal-7.14 branche, lui a donné son propre .gitignore pour ignorer tous mes fichiers de code et de paramètres et faire attention aux seuls fichiers qui font partie de l'installation Drupal que je ne toucherais pas. J'ai fait une mise à niveau à la main (télécharger, décompresser , untar, copy), triant les cas limites comme robots.txt et .htaccess, et écrasant le .gitignore de Drupal avec le mien. J'ai corrigé certains paramètres qui fonctionnaient avec 7.14 mais pas avec 7.15, pour récupérer à partir d'une erreur 500, puis tout semblait parfait. J'ai renommé la branche en drupal-7.15 et était sur le point de poursuivre mon chemin avec bonheur.
Jusqu'à ce que je réalise ce que j'avais fait par inadvertance: les fichiers qui n'étaient pas suivis auparavant par ma branche principale mais laissés dans le répertoire de travail ont maintenant été supprimés du répertoire de travail lorsque j'ai extrait master, car ils n'étaient plus des fichiers non suivis! D'oh !
Si je fusionne le drupal-7.15 branche avec master je perdrai la séparation du code.
Il existe probablement un moyen de convertir une branche en sous-module. En supposant que c'est possible, cela pourrait être la meilleure stratégie. Je savais avant de faire cela que les sous-modules étaient la "bonne" solution, mais comme je ne me rendais pas compte de l'effet secondaire de l'utilisation de branches pour des fichiers non suivis auparavant, j'ai décidé de couper les angles et de suivre cette voie. (De plus, toutes les approches que j'ai vues pour utiliser des sous-modules avec Drupal supposent que vous démarrez un nouveau projet et Drupal sera la branche principale). Il n'est pas souhaitable pour moi de faire du code de quelqu'un d'autre la branche master, et j'avais déjà un repo avec une branche master. Il semblait que ce serait inutilement compliqué juste pour faire une mise à jour.)
Il y a peut-être une autre solution à laquelle je n'ai pas pensé.
Comment puis-je mieux m'en remettre avec le moins d'inconvénients possibles?
[~ # ~] mise à jour [~ # ~]: Ceci est en développement (sous Linux VM sur mon ordinateur portable), et n'a pas encore été mis en production. Au moment où nous irons en production, je prévois de tout emballer dans des modules de fonctionnalités, mais ce n'est pas encore en place.
MISE À JOUR 2: les sous-modules mai ne fonctionnent pas. Selon Pro Git , "Les sous-modules vous permettent de conserver un référentiel Git comme sous-répertoire d'un autre référentiel Git". Drupal ne fournit pas une telle séparation Nice. Au lieu que tout le code Drupal soit dans un sous-répertoire, la relation est plus ou moins inversée, mais il y a toujours pas de séparation nette, car vous pouvez éditer votre .htaccess et robots.txt, donc votre code et le repo Drupal sont mélangés. Je suis à la recherche d'une solution à ce problème) problème .
Il semble de la discussion ci-dessus que votre question ne concerne pas la correction de votre dépôt git, mais le maintien d'un site Drupal dans git, et comment cela fonctionne avec les mises à jour principales.
Je pense que la pratique standard consiste en fait à garder tous les fichiers dans votre référentiel, y compris Drupal core. La séparation de Drupal code du code personnalisé semble être une bonne idée) , mais je ne pense pas que ce soit nécessaire, et je ne vois pas quels avantages cela vous offre. Il semble également supposer que vous ne voudrez jamais patcher le core (ou le faire dans le cadre de votre déploiement), ce qui , même si ce n'est pas la meilleure pratique, c'est certainement quelque chose que vous voulez pouvoir faire si quelque chose casse dans la production.
La solution que j'ai utilisée est de garder tout le code dans le même référentiel, de le mettre autant que possible dans les fonctionnalités ou d'autres types d'export/code/configuration, et de maintenir une liste des correctifs qui doivent être appliqués à l'extérieur du -box core et contrib.
Lorsque vous mettez à jour le core, démarrez dans votre environnement de développement:
- Assurez-vous que le répertoire de travail est propre
- Vider la dernière base de données (
drush sql-dump). Faites un commit avec le vidage ou enregistrez-le dans un endroit sûr. - Mettre à jour le noyau (
drush up drupal) - Validez toutes les modifications.
- Vérifiez le fichier des correctifs. Si des correctifs doivent être appliqués, appliquez-les et effectuez un autre commit
- Exécutez update.php si nécessaire (déjà fait si vous avez utilisé drush pour la mise à jour)
- Testez votre site de développement. Si tout va bien, envoyez le code à la production. Courir
drush updben production. - S'il y a un problème et que vous devez revenir en arrière, annulez ou réinitialisez votre référentiel (
git reset --hard HEAD~2devrait le faire), ou annulez les deux validations si vous souhaitez conserver l'historique. Remplacez votre base de données par le vidage.
Le vidage de la base de données est nécessaire car vous ne pouvez pas annuler les modifications apportées à la base de données par des mises à jour. Vous pouvez également effectuer la mise à jour dans une branche, auquel cas le retour signifie simplement extraire le maître. Il est légèrement déconseillé si vous travaillez sur un site de développement, car vous ne pouvez pas vraiment revenir au maître et continuer à y travailler en parallèle à cause de la base de données.
L'utilisation de ce flux de travail plus simple côté git vous permettra d'utiliser toute la puissance de git lorsque vous en avez besoin sans la complication des sous-modules, etc. Si cela ne semble pas suffisant, pourriez-vous expliquer pourquoi vous avez besoin d'une séparation supplémentaire du code?
J'exécute la configuration avec deux branches, tout comme l'OP: une branche avec mon code personnalisé uniquement, et une branche qui contient à la fois mes fichiers personnalisés et principaux. J'ai rencontré la même situation: les fichiers de base ignorés sont supprimés lors du basculement entre les branches.
J'ai fini par avoir deux répertoires git identiques: - un pour travailler sur mon code personnalisé, avec les fichiers core présents mais ignorés, et je ne basculerais jamais vers la branche "full" dans ce répertoire - un pour effectuer des fusions, de sorte que je effectuer le changement de branche et la fusion dans ce répertoire uniquement.
La raison pour laquelle j'ai choisi cette configuration à deux branches est parce que je veux suivre facilement toutes les validations locales dans les fichiers de base, il est plus facile d'examiner et de réappliquer les mods de base lors de la mise à niveau des fichiers de base.
D'après mes commentaires ci-dessus, cette question concerne le maintien d'un Drupal site fichiers avec git, et comment cela fonctionne avec les mises à jour de base. Vous n'avez rien mentionné sur la sauvegarde et la mise à niveau de la base de données. Je vais essayer de ne rien copier de goron answer.
J'ai créé un article de blog sur ce problème Mise à niveau Drupal core sur votre site Web avec Git
Méthodes alternatives
- Exécutez la commande Drush
drush up drupal- Appliquez un patch des différences entre les versions. Voir http://drupal.org/node/359234 & http://fuerstnet.de/en/drupal-upgrade-easier
Vous ne l'avez pas indiqué, mais si vous souhaitez suivre les changements entre les versions Drupal, je le ferais en utilisant tags au lieu de branches. Une fois que vous avez terminé votre validation de mise à niveau vers master, marquez votre code comme 7.x.