Gérer des modules personnalisés sur plusieurs installations

19

Nous avons des modules personnalisés qui sont utilisés pour plusieurs sites. Ceux-ci ne peuvent pas être publiés en tant que modules apportés, par exemple parce qu'ils sont spécifiques au client, émettent des hypothèses qui ne fonctionnent pas pour les modules apportés, etc.

Je connais les possibilités suivantes pour y faire face:

copiez et collez-les. Il est évidemment difficile de maintenir le module à jour sur toutes les installations.
Avoir une seule installation multi-sites, mais ce n'est pas toujours possible.
Utilisez des sous-modules git, mais ils peuvent être désagréables, il est facile d'oublier de les mettre à jour et ne sont pas toujours pris en charge (par exemple Pantheon)
Drush crée des scripts à extraire d'un référentiel git commun. Pour cela, vous AFAIK devez utiliser Drush Make pour l'ensemble du site et nous ne l'utilisons pas actuellement.
http://drupal.org/project/fserver . Je ne l'ai pas encore essayé, quelqu'un sait-il s'il est suffisamment stable? La description du projet ne semble pas très prometteuse et il n'y a pas de version 7.x.

Autre chose / mieux? Que préférez-vous et pourquoi?

version-control deployment drush

— Berdir
source

je pense que la nouvelle façon de faire ces choses est avec les applications: drupal.org/project/apps

— mojzis

10

L' approche Drush make, comme vous l'avez déjà mentionné, est la version que mon équipe utilise.

Même si vous n'utilisez pas actuellement Drush Make pour vos sites, il devrait être relativement simple de passer à ce flux de travail si vous le souhaitez, car Drush fournit également Drush Make-Generate qui générera le fichier Make à partir d'un site existant. Ainsi, pas besoin de sentir que cela ne vaut que pour les nouveaux sites. :)

— Létharion
source

Merci, j'ai décidé d'accepter votre réponse. J'ai besoin de m'habituer à drush make, de trouver la meilleure façon de gérer cela dans de grands projets avec de nombreux modules personnalisés et de convaincre mes collègues avant de pouvoir commencer à l'utiliser;) Avez-vous des ressources sur la façon de maintenir un site, par exemple la meilleure façon de mettre à jour la version, de reconstruire un site.

— Berdir

2

Je n'avais aucune ressource, alors j'en ai écrit une :) drupal.stackexchange.com/questions/33403/… Bien sûr, n'hésitez pas à commenter avec des questions plus approfondies si vous le souhaitez. :)

— Letharion

1

Si tous les sites sont sur le même serveur, vous pouvez utiliser symlinkpour charger des modules à partir d'un emplacement central, ou rsyncsi vous avez affaire à plusieurs serveurs.

Cela résoudra le problème de la distribution des fichiers, mais vous devez toujours lancer une mise à niveau. Il peut être automatisé avec drushun script simple qui appelle la mise à niveau sur tous les sites, un par un.

— Máté Gelei
source

0

Semble être que vous regardez presque à peu près toutes les solutions. Quand je l'ai lu, d'abord ce qui m'est venu à l'esprit ses deux autres solutions comme rsyncou symlinkmais encore une fois ce n'est pas confortable à maintenir.

Ensuite, souvenez-vous de ce module Git Deploy qui est en fait un joli combo avec des sous-modules git.

Je n'ai pas encore essayé cette idée, mais cela pourrait fonctionner, ou au moins vous donner un indice sur la façon de le pirater pour faire votre propre système.

— yvan
source

Git deploy expose les informations de version des modules contrib, mais nous n'avons pas de modules contrib donc je ne pense pas que cela aiderait.

— Berdir

0

J'utilise un référentiel git séparé pour tous les modules contribués / personnalisés où chaque module contribué ou personnalisé est dans une branche distincte (pas dans un sous-module).

voici comment fonctionne la fusion git ici:

Maître

      <-- custom
        <-- custom module 1
        <-- custom module 2    

      <-- contrib
        <-- contrib module 1
        <-- contrib module 2

master -> release

et un script bash / drush pour mettre à jour les branches

— Raffiner
source

Ma solution est basée sur cet article nvie.com/posts/a-successful-git-branching-model

— Refino

Hm. Je pouvais donc essentiellement ajouter un autre site en tant que site distant et importer une branche de module personnalisée à partir de là. Cela pourrait fonctionner, mais est relativement complexe.

— Berdir

0

J'utilise SVN à la place de Git pour stocker nos modules développés sur mesure. Après avoir validé la modification de localhost, je lance simplement le script bash qui exécute la commande "svn update" à des emplacements de serveur prédéfinis. Chaque fois que je déploie un module vers un nouvel emplacement, je mets à jour le script bash. C'est vraiment une configuration simple et fonctionne sans tracas.

— Ajinkya Kulkarni
source