Comment gérer l'activation de nouveaux modules avec Drush via makefile

8

Au travail, nous nous dirigeons vers l'installation de nos nouveaux sites dans git et le développement local. Jusqu'à présent, j'ai créé un fichier de création drush avec un profil d'installation, et j'ai ce script via une marionnette afin que lorsqu'un utilisateur fait un nouveau clone d'un référentiel, il télécharge tous les packages et exécute une installation de base du site. Cela fonctionne bien.

Maintenant, ma question est de savoir quand j'ai besoin d'utiliser un nouveau module pour un site. Par exemple, nous construisons un nouveau module pour le site. Je veux que les autres développeurs retirent de git et que le nouveau module soit installé automatiquement. L'ajouter au fichier drush make ne fera que le télécharger, et exécuter 'drush si' entraînera la réinstallation du site, effaçant toutes les données.

Quelle est la meilleure façon d'y parvenir?

Éditer

Je sens que je n'ai pas expliqué cela correctement. Je cherche un moyen d'activer automatiquement les modules basés sur les entrées de makefile dans drush. L'idée est que l'utilisateur vérifie un projet, puis je ferai exécuter par marionnettes «drush make» et «drush si» si aucun fichier settings.php n'existe. Ce que je dois comprendre, c'est quand la prochaine fois que l'utilisateur fera un pull et que nous aurons ajouté un nouveau module, comment l'activer automatiquement via un script. Si j'en ai besoin, j'écrirai quelque chose pour analyser le makefile et exécuter «drush en» manuellement, mais j'aimerais trouver quelque chose qui est pré-construit pour le faire.

installing version-control drush dragonmantank
la source
"drush fr" n'est-ce pas ce que vous voulez peut-être?
Sam152
J'ai besoin d'un moyen de l'automatiser. 'drush en' peut être exécuté à partir de la CLI, mais ce que je veux, c'est un moyen de déterminer quels modules sont nouveaux et de les activer automatiquement.
dragonmantank
1
Le problème va être que le fait d'avoir un module présent comme un ensemble de fichiers ne signifie pas que vous voulez qu'il soit activé. Quelqu'un doit prendre cette décision. Par exemple, si vous téléchargez des vues, vous obtenez également l'interface utilisateur des vues. Voulez-vous que cela soit activé ou non? C'est une décision consciente. Vous avez donc besoin d'une liste des modules et cela pourrait tout aussi bien être dans un script.
Alfred Armstrong
Désolé, oublie ça. Je comprends en quelque sorte ce que vous voulez dire, même si je ne suis pas sûr de l'intérêt de tout cela via make.
Alfred Armstrong
1
@AlfredArmstrong l'idée était que, puisque je dois déjà organiser le fichier make, il suffit de l'utiliser d'une certaine manière. Si je veux que 'devel' soit activé, mais pas 'devel_generate', alors seulement 'devel' serait dans le fichier make. Si je décidais plus tard d'activer 'devel_generate', j'ajouterais cela au fichier make. Je ne veux pas le faire uniquement en fonction des fichiers disponibles spécifiquement pour la raison que vous avez mentionnée, je dois donc contrôler cela d'une manière ou d'une autre.
dragonmantank

Réponses:

4

J'ai travaillé pour une entreprise qui avait un grand flux de développement / étape / prod qui essayait d'automatiser autant que possible. Tout devait être fait en code, scripté à l'aide de fonctionnalités ou de crochets de mise à jour.

Fondamentalement, ce que vous voulez, c'est d'avoir 1 module personnalisé qui existe pour contenir les hooks de mise à jour. De cette façon, lorsqu'un développeur extrait une mise à jour de la base de code, il exécute la mise à jour db, et qui peut effectuer tout ce que le module doit activer / désactiver. Les hooks de mise à jour n'affectent pas une nouvelle installation, car il est supposé que le module est déjà à jour lors de son installation et n'exécutera que des mises à jour plus récentes.

Résumer:

  1. Continuez à utiliser votre profil d'installation pour effectuer les tâches d'installation nécessaires (activation des modules, etc.).
  2. Utilisez un module de «mise à jour» personnalisé qui utilise hook_update_NXXX () pour activer / désactiver les nouveaux modules et autrement synchroniser les tâches administratives de votre site.

Voici un article qui parle d'une approche similaire et donne des exemples de code.

coreyp_1
la source
1

c'est une excellente question. drush makeest pratique pour télécharger des modules. Nous ne voulons pas contribuer au ballonnement du module. Au cours ici le cas est fait de ne pas prolonger makecette façon. Peut-être que les fonctionnalités sont les meilleures pour gérer l'état activé du module du site, ainsi que d'autres aspects de configuration.

Screenack
la source
1

Pensez à modifier votre flux de travail.

On dirait que vous voulez faire du travail distribué et "partager" des modules d'activation et d'autres valeurs de configuration ... en quelque sorte.

Si vous y pensez - même Drupal "core" et Drupal.org ne le font pas. Le code est soumis aux modules de base et de communauté qui s'exécutent dans un processus de construction continu. Drupal.org et de nombreux projets utilisent Jenkins.

Pour une installation de Jenkins orientée vers le développement Drupal, il utilise également Phing, voir ce dépôt git: http://reload.github.io/jenkins-drupal-template/

À l'aide de Jenkins, vous pouvez envoyer du code à votre référentiel Git principal et faire construire le site pour un site de démonstration à partir de votre profil d'installation et de votre (vos) Makefile (s) Drush. Cela ne résout pas votre problème exactement mais fournit 1 emplacement où vous appuyez tous sur le (s) changement (s) pour ajouter / activer / supprimer des modules et, espérons-le, vous ne "rompez pas la construction".

En supposant que la version n'est pas interrompue - il est sûr de faire entrer ses modifications dans votre système de développement local.

Jenkins + un serveur de développement ou de développement n'est qu'un élément de développement.

Votre flux de travail local peut utiliser des profils d'installation + des makefiles. Envisagez de partager du contenu à l'aide de modules personnalisés avec Migrate si vous pouvez vous permettre le temps de génération de contenu. Des exemples de partage de contenu avec des développeurs utilisant Migrate et l'utilisation de Phing peuvent être lus ici:

http://marzeelabs.org/blog/2014/03/17/coding-as-a-team-content-fixtures/ http://marzeelabs.org/blog/2014/03/03/coding-as-a- automatisation d'équipe en utilisant le phing /

Enfin, consultez ce PDF sur une session du Drupal Camp Ohio 2014 sur l'intégration continue et le travail avec votre équipe:

tenken
la source
1

Dans le même but, nous utilisons Master . Il utilise le fichier settings.php pour fournir des informations sur les modules maîtres. Avec une simple commande, drush master-executetous les modules (et leurs dépendances) manquants sont activés et les modules qui ne sont plus utilisés sont désactivés.

Actuellement, le module ne lit pas les informations du makefile, mais cela pourrait être une option pour une nouvelle version.

derhasi
la source
0

Vous pouvez activer les modules manuellement en passant par l' option Modules ou par terminal en utilisant la commande drush

drush en -y modulename1 modulename2

etc.

Nitesh Sethia
la source
Je cherche un moyen d'automatiser cela basé sur des makefiles, pas seulement comment activer un module manuellement.
dragonmantank
0

Les modules peuvent être activés de 2 manières:

  1. soit depuis le terminal utilisant la commande drush par:
    A. drush dl modulename- pour télécharger le module en premier
    B. drush en -y modulename- pour activer le module

  2. En utilisant l' option de menu Module puis en activant le module à partir du nombre de modules affichés.

neetu morwani
la source
Je cherche un moyen d'automatiser cela basé sur des makefiles, pas seulement comment activer un module manuellement.
dragonmantank
Il y a encore d'autres façons. module_enable()par exemple. Ou en important une base de données préparée.
leymannx
0

Je veux en être certain. La fonction make permet de télécharger les différentes parties du site: module, thèmes et projet via git. Lorsque vous notez votre profil d'installation, vous écrivez dans le fichier info les modules dépendants. Le problème est lorsque vous devez ajouter un nouveau module pour votre profil d'installation pour le profil existant - ai-je raison?

Pour cela, vous devez utiliser le hook_update_N lorsque le N représente la mise à jour du numéro. Le hook est utilisé pour les modules qui doivent effectuer des actions telles que: mettre à jour des schémas, ajouter des variables et utilisé pour les sites et la distribution, tels que OpenScholar, pour activer les nouveaux modules téléchargés sur le site en direct.

Vous devrez probablement l'ajouter dans le module le plus générique et la fonction ressemblera à ceci https://github.com/openscholar/openscholar/blob/SCHOLAR-3.x/openscholar/modules/os/os.install#L16

Le crochet doit être situé dans le fichier module.install. Si vous utilisez l'interface utilisateur, vous devez vous rendre sur www.site.com/update.php et si vous utilisez drush, utilisez simplement la commande drush updb.

Roy Segall
la source
0

Si je comprends bien, le fichier Drush .make télécharge uniquement les projets de drupal.org, si vous souhaitez activer certains modules, vous pouvez le faire avec un profil d'installation ** (.install) **. Un profil d'installation vous donne des options, quels modules vous souhaitez activer au moment de l'installation.

Récemment, j'ai également contribué à une distribution à l'aide du fichier .make. Même moi, j'ai partagé toute l'expérience de .make ici . Je sais que cela n'est pas lié à ce que vous demandez exactement, mais cela peut vous aider à comprendre ce que fait exactement le fichier .make.

Donc, à partir de cette tâche, ce que je comprends, en utilisant un fichier .make , vous ne pouvez pas automatiser l'activation du module. Pour ce faire, vous devez suivre une autre approche.

J'espère que cette URL de forum peut vous aider. Automatisation Drupal avec script Bash et Drush .

Vous devez écrire un script bash où vous utiliserez exactement les commandes Drush.

drush en -y modulename
Pushpinder Rana
la source