Planète

Par Artusamak
Julien Dubois

Porter son module en D8 - #2 Les tests

Porter son module en D8 - #2 Les tests
mar, 26/05/2015 - 08:00
DuaelFr

Dans un monde où l'on exige toujours plus de contrôle de la qualité des produits que nous utilisons au quotidien, il est normal que l'industrie logicielle ait dû se plier à la conception et la mise en œuvre de tests automatisés. Drupal n'échape pas à cette règle et c'est un gage de stabilité que de proposer des tests au sein de votre module.

Cet article est le deuxième de la série qui suit, étape par étape, la conversion d'un module contribué, Multiple E-mail Addresses, de Drupal 7 vers Drupal 8. Dans le premier article, nous avons évoqué les éléments à prendre en compte pour démarrer le portage et faire en sorte qu'il soit possible d'installer le module.

Contrôle qualité

Pyramide inversée des types de tests (unitaires, d'intégration et fonctionnels)Les tests logiciels sont catégorisés suivant plusieurs systèmes de classification différents. Personnellement, celle que j'utilise le plus est basée sur un concept de couches applicatives. Les tests unitiaires, au plus bas, assurent le bon fonctionnement des composants en testant, de manière isolée, que chaque sous partie du code produit le résultat escompté. Les tests d'intégration, plus rares, permettent de vérifier que les diverses parties de l'application communiquent correctement entre elles. Les tests fonctionnels ou tests de non-régression ont pour objectif de valider l'effectivité fonctionnelle de l'application et sont idéalement rédigés en collaboration avec le responsable fonctionnel (le client, dans le cadre d'une prestation de développement). Enfin, très rares encore aujourd'hui, les tests d'interface qui valident l'aspect et l'interactivité de l'interface graphique.

Drupal 7, de par son architecture, favorise l'utilisation de tests fonctionnels. En effet, le fait que le cœur de Drupal 7 soit encore très majoritairement procédural rend les tests unitaires très complexes car ils nécessitent de pouvoir isoler les composants à tester les uns des autres, ce qui est rendu plus facile par une architecture objet. Un exemple de test fonctionnel serait de vérifier qu'à la soumission d'un formulaire contenant des données erronées, un message d'erreur soit bien affiché.

La refonte complète du cœur de Drupal 8 a donc été pensée pour rendre l'écriture des tests fonctionnels plus simple car ils sont beaucoup plus rapides à exécuter et permettent un contrôle plus fin des composants qui pourraient avoir régressé. Le pincipe de ces tests est très simple. Il s'agit d'isoler au maximum un fragment du code, généralement contenu dans une méthode, et de l'exécuter avec des jeux de données couvrant tous les cas possibles en entrée et en contrôlant que les données en sortie sont conformes aux attentes. Pour réaliser ces tests, la communauté a choisi le moteur de test PHPUnit.

Dans le contexte du portage d'un module de Drupal 7 à Drupal 8 il est souhaitable de commencer par la conversion des tests. Ceci nous permettra au fil du travail de réécriture, d'identifier les points qui posent problème et de nous assurer que le fonctionnement existant ne soit pas altéré. Dans un second temps, si cela s'avère nécessaire, il sera toujours possible d'augmenter la couverture de tests en ajoutant, par exemple, des tests unitaires.

Anatomie d'un test fonctionnel

Dans la version 7 de Drupal, un module souhaitant implémenter des tests doit disposer d'un fichier <modulename>.test, référencé par une clef files[] du fichier <modulename>.info. Ce fichier peut contenir plusieurs classes PHP. Chacune correspond à une série de tests différents et chaque test représenté par une méthode dont le nom commence par "test" (ie. le fichier modules/block/block.test du cœur contient la classe BlockTestCase qui implémente la méthode testCustomBlock).
De plus, de nombreux modules ont besoin d'initialiser un environnement dans un état particulier pour que les tests soient effectifs. Pour y parvenir, ils proposent dans un répertoire "tests" un ou plusieurs modules dont le seul but est de mettre en place le contexte nécessaire aux tests décrits dans le fichier <modulename>.test. Par exemple, le module Field du cœur propose un module field_test définissant quelques permissions, un type d'entité, un type de champ, etc.

Dans la version 8 de Drupal, à l'heure actuelle (bêta 10), les fichiers <modulename>.test ont disparu au profit de fichiers respectant le standard PSR-4. On retrouve donc des classes de tests, une par fichier, dans les répertoires src/Tests, pour les tests fonctionnels, et tests/src/Unit, pour les tests unitaires. Comme pour Drupal 7, certains modules proposent des sous modules destinés à configurer un environnement de tests.

Convertir les tests

Le but de cet article n'est pas de faire en sorte que tous les anciens tests passent au vert car cela voudrait dire, en théorie, avoir terminé le portage. Nous allons nous concentrer sur le fait de rendre les tests exécutables par Drupal 8 et nous nous baserons ensuite sur les résultats pour faire progresser notre travail.

Astuce : un debugger comme xdebug peut être très utile dans cette phase du développement mais il faut savoir que le fait qu'il soit activé sur votre environnement va grandement augmenter le temps d'exécution de vos tests et potentiellement rendre les messages d'erreur plus confus. Il est donc recommandé de désactiver votre débugger à moins que vous en ayez absolument besoin.

Image du répertoire src/Tests

Diviser pour mieux régner

Comme indiqué précédemment, les tests dans D8 sont séparés dans des fichiers chargés automatiquement selon la norme PSR-4. Nous allons donc séparer toutes les classes présentes dans notre fichier <modulename>.test en autant de fichiers dans src/Tests.

Le module Multiple E-mail Addresses contient 4 classes de tests dans le fichier multiple_email.test : MultipleEmailAdminUserTestCase, MultipleEmailBasicUserTestCase, MultipleEmailUserTestCase et MultipleEmailLateInstallTestCase. Nous allons donc créer 4 fichiers contenant chacun une de ces classes que nous renommerons plus simplement.
La convention veut que le nom de la classe termine par "Test" pour différencier les classes de tests des classes fonctionnelles plus facilement dans les IDE proposant l'autocomplétion.

Nous obtenons donc 4 fichiers nommés respectivement AdminUserTest.php, BasicUserTest.php, UserTest.php et LateInstallTest.php. Chacun contient une classe PHP du même nom, déclarée dans le namespace Drupal\multiple_email\Tests.

Exemple :

class MultipleEmailUserTestCase extends DrupalWebTestCase {
  ...
}

devient

namespace Drupal\multiple_email\Tests;

class UserTest extends DrupalWebTestCase {
  ...
}

Une fois la séparation terminée, vous devriez voir apparaître vos tests dans l'interface de Simpletest (admin/config/development/testing) et vous devriez donc être en mesure de les exécuter. C'est d'ailleurs en essayant de les faire tourner que nous allons pouvoir détecter les prochaines corrections à y apporter.

La classe parente

À l'exécution de la classe UserTest nous obtenons immédiatement une erreur fatale PHP "Fatal error: Class 'Drupal\multiple_email\Tests\DrupalWebTestCase' not found in /modules/multiple_email/src/Tests/UserTest.php on line 17".

Comme souvent à partir de maintenant, la réponse se trouvera dans les Change records de Drupal 8 qui, avec une recherche sur le nom de la classe en erreur DrupalWebTestCase, nous donnera plusieurs résultats intéressants dont un qui traite précisément du renommage des classes de test.

On applique donc la recette trouvée dans le Change record et on renomme la classe parente de nos tests en WebTestBase, en important son namespace à l'aide d'une clause "use". 

namespace Drupal\multiple_email\Tests;

use Drupal\simpletest\WebTestBase;

class UserTest extends WebTestBase {
  ...
}

 

Maintenant que les erreurs structurelles ont été corrigées, les tests peuvent s'exécuter et nous allons devoir composer avec des erreurs pas forcément aussi directes. Le prochain article s'attardera sur certaines des erreurs les plus courantes rencontrées lors du portage des tests à Drupal 8 et vous donnera des pistes pour résoudre vos propres erreurs.

Par Artusamak
Julien Dubois

Porter son module en D8 - #1 Rendre le module installable

Porter son module en D8 - #1 Rendre le module installable
lun, 18/05/2015 - 22:00
DuaelFr

Dans la communauté française, nombreux sont les développeurs à avoir créé, au moins une fois, un module contribué. Qu'il dispose d'une version stable ou qu'il soit encore en sandbox, il va être temps de le porter sur Drupal 8 si l'on veut que cette nouvelle version majeure ait un taux de pénétration plus important que Drupal 7 à sa sortie.

Cette série, qui débute par l'article que vous êtes en train de lire, suivra étape par étape la conversion d'un module contribué, Multiple E-mail Addresses, de Drupal 7 vers Drupal 8.

Définition d'un module

Jusqu'à Drupal 7, un module était identifié par le cœur à la condition que l'on trouve, au sein du même répertoire, au moins un fichier <modulename>.info et un fichier <modulename>.module. Le fichier info contient les métadonnées du module : son nom, sa description, sa version, ses dépendances, les fichiers à charger automatiquement (autoload), etc. Le fichier module quant à lui contient les fonctions PHP de base permettant au module de fonctionner et est chargé automatiquement par Drupal si le module est actif.

Depuis le 17 mars 2015, la définition d'un module a légèrement changé dans Drupal 8. Désormais, seul un fichier <modulename>.info.yml est obligatoire. Si un fichier <modulename>.module existe, il sera toujours chargé automatiquement, mais il n'est plus obligatoire pour que le cœur de Drupal reconnaisse l'existence du module. Ce changement est dû au fait que la plupart du code qui se trouvait auparavant obligatoirement dans le fichier <modulename>.module est réparti dans d'autres fichiers source, chargés automatiquement grâce à la spécification PSR-4 de PHP, ou dans des fichiers de configuration séparés.

Initialisation du répertoire

La bonne pratique pour mettre à jour votre module d'une version majeure à une autre consiste à partie des sources de la dernier version disponible et de remplacer les fichiers et le code au fur et à mesure que l'on rencontre des erreurs. Ces erreurs peuvent survenir lors de l'exécution du module ou, dans le meilleure des cas, lors de l'exécution des tests. Nous reviendrons, au fil des articles de cette série, sur les erreurs que vous risquez de rencontrer et nosu tenterons de vous aider à comprendre ce qui se cache derrière et comment les résoudre.

De plus, si la branche principale de votre module évolue avant que vous n'ayez terminé votre portage, vous pourrez profiter de la puissance de git pour récupérer les nouvelles fonctionnalités facilement dans votre nouvelle version.

Nous débutons donc par un :

$ git clone --branch 7.x-1.x <pseudo>@git.drupal.org:project/multiple_email.git
$ git branch -b 8.x-1.x

Le fichier info

Comme dit précédemment, tout ce dont nous avons besoin pour pouvoir installer notre module est un fichier <modulename>.info.yml valide. Ce fichier est l'équivalent de l'ancien fichier <modulename>.info mais dans un format différent, le format YAML. Je passerai rapidement sur ce format étant donné qu'il existe de la documentation un peu partout sur Internet et même en français. En quelques mots il s'agit d'un format de sérialisation de données simple, standard et compréhensible par l'humain.

Le cas de Multiple E-mail Addresses étant trop simple pour servir d'exemple, voyons un cas générique qui recense les principales entrées que l'on trouve habituellement dans un fichier info.

Avant : <modulename>.info

name = "Nom du module"
description = "Description du module"
core = 7.x
package = Other
dependencies[] = entity
dependencies[] = entityreference
files[] = modulename.test
files[] = views/modulename_handler.inc
configure = admin/configure/modulename

Après : <modulename>.info.yml

name: 'Nom du module'
description: 'Description du module'
core: 8.x
type: module
package: Other
dependencies:
 - entity
 - entityreference
configure: modulename.admin.settings

Pour entrer dans le détail vous remarquerez tout d'abord que la plupart des entrées sont identiques ; les symboles "=" ont simplement été remplacés par des symboles ":" à la manière du format JSON.

De plus, vous noterez l'apparition d'une nouvelle entrée obligatoire qui n'existait pas dans les versions précédentes et qui permet de définir le type de projet dont il s'agit : module, theme ou profile. Cette entrée a été créée pour permettre le changement autorisant un module ou un profil d'installation à n'être défini que par son fichier <modulename>.info.yml. Auparavant, c'était la présence d'un fichier <modulename>.module ou <modulename>.profile qui permettait à Drupal de faire la différence.

Ensuite, les dépendances suivent le format des collections YAML en passant sous la forme d'une liste préfixée d'un tiret. Elles auraient également pu être décrites sur une ligne entre crochets et séparées par des virgules comme suit : 

dependencies: [entity, entityreference]

Les entrées files ont quant à elles simplement disparu. En effet, comme dit précédemment, Drupal 8 suit la spécification d'auto-chargement PSR-4 et il n'est donc plus nécessaire de déclarer les fichiers qu'il faudra charger puisqu'ils seront inclus automatiquement lors de l'appel à leur contenu.

Enfin, l'entrée configure, qui permet d'afficher un lien vers l'URL de votre choix directement depuis la liste des modules, est réécrite en utilisant le nouveau système de routes dont nous reparlerons dans le troisième volet de cette série d'articles. Cette entrée est optionnelle donc je vous recommande de l'omettre pour commencer et de vous laisser une note pour la rajouter plus tard.

Si vous voulez voir un autre exemple, Nicolas a déjà rédigé un billet sur ce blog qui se base sur le fichier info du thème Seven présent dans le cœur de Drupal.

Le résultat sur multiple_email.info.yml

name: 'Multiple E-mail Addresses'
type: module
description: 'Allows users to have more than one registered e-mail address.'
core: 8.x
# @TODO add configure route

Le fichier install

La plupart des modules existants incluent un fichier <modulename>.install contenant des implémentations de hooks joués lors de l'installation ou de l'activation du module. Drupal 8 a vu de nombreux changements opérés au sein de ce fichier. Certains concepts et les hooks associés ont disparu comme l'activation et son hook_enable ainsi que la désactivation et son hook_disable. D'autres n'ont pas vraiment changé comme les hook_schema, hook_install et hook_uninstall bien que leur contenu puisse être différent.

Étant donné que nous avons copié la totalité des fichiers de la version 7.x du module, il est probable qu'un fichier <modulename>.install existe dans votre répertoire, ce qui risque de poser des problèmes pour activer le module. Par exemple, lorsque l'on tente d'activer le module multiple_email, nous obtenons l'erreur suivante : 

$ drush en -y multiple_email
The following extensions will be enabled: multiple_email
Do you really want to continue? (y/n): y
exception 'PDOException' with message 'SQLSTATE[42S22]: Column not found: 1054 Unknown column 'mail' in    [error]
'field list'' in /[...]/core/lib/Drupal/Core/Database/Statement.php:61
[... Stack trace ...]

Next exception 'Drupal\Core\Database\DatabaseExceptionWrapper' with message 'SQLSTATE[42S22]: Column not
found: 1054 Unknown column 'mail' in 'field list': 
    INSERT INTO {multiple_email}
      (uid, email, time_registered, confirmed)
    SELECT
      uid,
      mail,
      created,
      1
    FROM {users}
    WHERE uid != 0
    AND mail != ''
    GROUP BY mail
  ; Array
(
)
' in /[...]/core/lib/Drupal/Core/Database/Connection.php:609
[... Stack trace ...]

L'erreur étant survenue lors de l'installation du module, il est probable qu'elle provienne du hook_install. Vérification faîte, c'est bien ce hook qui tente d'exécuter la requête SQL incriminée. En y regardant de plus près, l'erreur dit qu'il n'y a pas de colonne mail dans la table cible. Un coup d'œil dans la base de données nous montera qu'en effet, la table users ne contient plus de colonne mail.

En attendant que nous abordions la migration de ces hooks en détail dans un chapitre prochain, je vous recommande de commenter la totalité du code de ce fichier afin d'éviter les erreurs à l'installation et à la désinstallation du module.

Conclusion

Maintenant que vous avez commenté votre fichier <modulename>.install et converti votre fichier <modulename>.info, vous n'avez plus qu'à activer votre module dans Drupal pour vérifier qu'aucun morceau de code resté dans le fichier <modulename>.module n'entre en conflit avec le cœur de Drupal 8.

La prochaine étape, couverte dans le deuxième article de la série, sera de transformer les tests de votre module pour qu'ils puissent être exécutés dans Drupal 8. Cela vous permettra de simplfiier le travail de mise à jour du module tout en évitant les régressions.

Par Artusamak
Julien Dubois

Drupal et Scrum depuis les tranchées - Le scrum quotidien

Drupal et Scrum depuis les tranchées - Le scrum quotidien
ven, 15/05/2015 - 15:46
Artusamak

Le rituel qui se répétera le plus tout au long de vos projets sera le scrum quotidien. Certains l'appelleront la mêlée, le stand-up, le scrum. Tous ces termes représentent la même chose, un moment particulier durant lequel l'équipe se rassemble devant le tableau d'avancement pour faire le point.

Les règles du scrum

  1. La première règle du scrum est que le scrum commence à l'heure. Pas d'excuse pour les retardataires, leur conscience et l'équipe finiront par les rattraper pour qu'ils arrivent à l'heure. C'est une question de respect - j'ajouterai que cela colle bien avec l'esprit agile où l'on doit livrer comme promis et qu'il faut adapter le contenu.
  2. La seconde règle du scrum est que la durée du scrum est limitée. La durée recommandée est 15 minutes. Si cela dure moins longtemps et bien c'est autant de temps de code en plus. Si cela doit prendre plus de temps, c'est sûrement que vous faites mal quelque chose (des explications plus bas ;-)).
  3. La troisième règle du scrum est qu'une seule personne a le droit de parler à la fois. Pas de conversations croisées, on écoute son interlocuteur puisqu'on doit réagir à ce qu'il se dit. C'est de l'écoute active. Le détenteur de la parole peut se matérialiser par un totem / bâton de parole, si vous ne l'avez pas entre les mains et bien... vous ne pouvez pas parler. Cela permet d'éviter que l'on vous coupe la parole.
  4. La quatrième règle du scrum est que le scrum se fait debout. Cela stimule les interlocuteurs et aide à faire en sorte que le point dure moins longtemps. Évidemment on ne lit pas ses emails ou ne joue pas à Candy Crush pendant le point quotidien.

De quoi parle-t-on pendant le scrum ?

L'équipe se tient devant le tableau d'avancement et chaque équipier répond aux trois questions suivantes : qu'ai-je fait hier, que vais-je fait aujourd'hui et quels sont les problèmes que j'ai rencontré. Chacun répond à ces questions en s'adressant aux autres, pas en s'adressant au scrum master. Le fait de faire le point devant le tableau d'avancement permet aussi de voir les stories qui avancent, c'est très gratifiant !

L'intérêt principal du scrum est que tout le monde soit au courant de ce qu'il se passe et que si une personne travaille sur un sujet potentiellement déjà couvert par une autre personne, elle sache qui aller voir pour se mettre tout de suite dans le bain. C'est un gain de temps significatif pour l'équipe.

Le second intérêt du scrum est la prise de conscience collective, chacun doit être à l'écoute des autres. En soulevant ses problèmes, un équipier lance une invitation à ce que l'on vienne l'aider. À quoi bon perdre du temps à chercher une solution si quelqu'un peut lui donner des pistes pour résoudre son problème ou mieux encore, s'asseoir à ses côtés pour résoudre son problème ensemble.
Si chaque matin une personne indique qu'elle travaille sur le même sujet sans pour autant remonter de problème, il faut se rendre compte qu'il y a un problème. Soit la personne décrit de façon trop macro ses problématiques, soit elle ne se rend pas compte qu'elle n'avance pas et doit demander de l'aide. Il est alors de la responsabilité de l'équipe de s'en rendre compte et de proposer des solutions pour régler cela. De la même façon, si vous ne comprenez pas de quoi vous parle un équipier, prenez 5 minutes avec lui après la réunion pour qu'il vous explique un peu mieux plutôt que de vous désintéresser de son travail.

Gardez à l'esprit que vous devez livrer à la fin du sprint un logiciel fonctionnel avec le maximum de valeur ajoutée. Si des stories n'arrivent pas à être fermées pendant plusieurs jours, rediscutez leur priorité pour savoir s'il ne faudrait pas plutôt se concentrer sur autre chose avec plus de valeur. Il peut être plus sage de sortir les stories du sprint et de les réintégrer plus tard, peut être de façon redécoupée.

Photo d'un paysage de bord de mer.

Et si la conversation doit prendre plus de temps ?

Parfois il vous sera nécessaire d'approfondir les échanges, notamment lorsque vous parlerez des problèmes. Le scrum n'est pas là pour résoudre les problèmes mais pour les faire remonter. Lorsque ce cas de figure se présente : identifiez que vous êtes entrain de débattre d'une piste de résolution ; interrompez la conversation ; donnez vous rendez-vous dans la journée (immédiatement après le scrum par exemple) ; laissez le scrum reprendre son cours. Cela peut s'appliquer à d'autres sujets tels que de l'architecture ou des pistes d'implémentations. Dès qu'un débat se présente, retardez le, ne conviez que les personnes concernées par la discussion (ou volontaires pour apporter leur opinion). Le temps de chacun est précieux, respectez le. Cela évite également que les gens se désintéressent. Mieux encore, si vous vous désintéressez, demandez-vous pourquoi et mettez le sujet sur la table lors de la prochaine rétrospective.

Autres points

Le scrum n'est pas uniquement là pour parler des problèmes, il n'est pas interdit de dire aux autres que l'on a apprécié quelque chose. Au contraire, je vous encourage même à vous forcer à dire régulièrement à vos équipiers ce que vous avez apprécié dans leur travail récent. (NDLR : cela peut aussi s'appliquer à vos amis et votre famille ;-)).

Les clients ne sont en général pas conviés au scrum, il nous est arrivé sur certains projets de les impliquer pour qu'ils soient concernés. Cela permet de suivre leur avancement et de se synchroniser lorsqu'il y a des dépendances sur de la production de contenu par exemple.

Attention à la routine, les scrums ont lieu tous les jours alors soyez originaux de temps à autre. Veillez à ce que les gens ne parlent pas toujours dans le même ordre, changez de pièce à l'occasion, variez l'ordre des questions on ne répondez pas à la première ou seconde à l'occasion. Aléatoirement une personne peut résumer ce que les autres ont fait pour confirmer que tout le monde est attentif.
Bref, gardez le scrum dans un esprit le plus collégial et le plus bon enfant possible, il ne faut pas que ça soit une punition !

Par besky
Richard B.

Drupal : un CMS flexible et puissant

Découvrez le CMS Drupal, la solution la plus puissante et flexible pour la création d'applications web : site internet, intranet, extranet ou encore e-commerce.

Drupal un CMS flexible et puissant

Par ftorregrosa
Adhérent
Florent Torregrosa

Retour sur les Drupal Dev Days 2015

Du 13 au 19 avril 2015 ce sont déroulés les Drupal Developer Days à Montpellier. Ça a été une expérience géniale et très enrichissante que ce soit en tant que co-organisateur ou en tant que participant.

Sprints

J'ai aidé à sortir la première version D8 du module Search API attachements, ainsi qu'à nettoyer l'issue queue des issues pour D7.

Il était aussi intéressant d'entendre la structure de la future facet API D8 se débattre juste à côté.

Tags: 
Par admin

Drupagora 2015 : Appel à communications

Drupagora est un rendez-vous incontournable, francophone sur Drupal dédié aux chefs de projets et DSI, de tout l’écosystème Drupal et attire chaque année plus de 350 professionnels, venus de toute la France.

Pour sa cinquième édition, Drupagora a changé le calendrier et le lieu de rendez-vous pour accueillir plus de participants dans des conditions optimales. C'est pourquoi, Drupagora se tiendra cette année le 19 juin et aura lieu à l'Université Pierre et Marie Curie (Paris 5ème)

Cette année, le fil rouge du programme est : « Drupal dans le contexte de l'Entreprise: plateformes digitales globales, applications eCommerce, applications métier jumelées et intégrées au SI (ERP, CRM, PIM, DAM…). »

Avec pour thématiques principales :

  • Comment Drupal s'intègre t-il avec d'autres applications métier?
  • Exemples réussis et témoignages d'applications Drupal d'envergure et de E-commerce
  • Les perspectives avec l'arrivée prochaine de Drupal 8

L'appel à communication est disponible jusqu'au 1er mai 2015.

Par ailleurs, à noter que les inscriptions à Drupagora sont ouvertes au tarif early bird, et ce, jusqu'à la clôture de l'appel à communications.

Informations complémentaires

  • Date, lieu et organisation

La conférence Drupagora se tient à l'Université Pierre et Marie Curie, Paris 5ème, le vendredi 19 juin de 9h à 18h.

  • Tarif / Inscription

40 euros jusqu'au 01/05/2015
75 euros jusqu'au 15/06/2015
100 euros en tarif normal

Liens

Tags : 
Par vincent59
Vincent Liefooghe

Installer Drush avec Composer

Depuis quelques temps déjà, Drush (DRUpal SHell) est disponible sur GitHub, et non plus sur http://drupal.org.

L'installation peut se faire via git ou via Composer. C'est cette méthode qui est nécessaire pour l'installation avec Drupal 8.

Installation des pré-requis sur la machine
Ces paquets sont utilisés pour récupérer les données via http et git. unzip est utilisé avec drush make pour dézipper certains fichiers.

apt-get install curl git unzip

Installation de Composer
L'installation de Composer est faite en global (pour tous les utilisateurs).

curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer

Installer Drush pour l'utilisateur courant

composer global require drush/drush:dev-master
ls -a .composer/vendor/bin
.  ..  boris  drush  drush.bat	drush.complete.sh  drush.php

Drush est installé dans le répertoire .composer/vendor/bin de l'utilisateur. Il faut ensuite ajouter ces lignes dans le .bashrc :

export PATH=$HOME/.composer/vendor/bin:$PATH

Installer Drush pour tous les utilisateurs
Si plusieurs utilisateurs ont accès à la machine, il est préférable d'avoir une installation globale :

git clone https://github.com/drush-ops/drush.git /usr/local/src/drush
cd /usr/local/src/drush
git checkout 
ln -s /usr/local/src/drush/drush /usr/bin/drush
composer install
drush --version
which drush

Voilà, on peut maintenant utiliser toute la richesse de drush pour installer / activer des modules, installer un site complet, etc.

  Références :http://www.drush.org/en/master/install/ 

Catégorie: 


Tag: 

Par admin

Drupal Developer Days c'est maintenant

Après de nombreux mois de préparations, l'événement Drupal Developer Days commence aujourd'hui, le 13 avril 2015 à Montpellier, en France.

Nous sommes très impatients de retrouver toutes les personnes inscrites car la semaine est très prometteuse et de qualité.

Même si vous ne pouvez pas être présent, vous pouvez consulter le site officiel de l'événement : Drupal Developer Days 2015

Par anavarre

Présentation meetup Drupal Lyon - L&#039;intégration continue pour tous

Au pied levé, j'ai préparé une présentation sur l'intégration continue pour Drupal Lyon. Plutôt que de parler CI d'entreprise et de rentrer dans les détails de Jenkins et du workflow typique d'un équipe de dév, pourquoi ne pas déjà aborder toutes les bonnes pratiques et méthodologies à employer pour soi-même créer un produit testé et fiable ? Bienvenue dans l'intégration continue pour tous !

Pages