Comment gérer efficacement un site avec Drush make?

Quelles sont les choses importantes à considérer lors de la gestion d'un site à l'aide de Drush make ?

drush

— Létharion
source

"Créer des fichiers", dans le contexte Drush et Drupal, définit un ensemble de modules, thèmes et bibliothèques qui composent un site. Bien que l'on puisse coller l'intégralité du répertoire sites / all / modules dans git, le fichier make est beaucoup plus rapide à gérer, à la fois pour git et pour les développeurs. Vous trouverez ci-dessous un fichier de création d'un projet réel. J'ai beaucoup coupé car le fichier entier est composé de centaines de lignes, mais j'en ai conservé suffisamment pour montrer toutes les fonctionnalités que j'ai utilisées.

; API
api = 2

; Core
core = 7.x
projects[drupal][version] = 7.14

; Contrib modules
projects[date][version] = 2.0-alpha4
projects[email][version] = 1.0

; Media and file_entity go hand in hand - please make sure they work together.
projects[media][version] = 2.0-unstable5
projects[file_entity][version] = 2.0-unstable5

; Cron modules
projects[ultimate_cron][version] = 1.6
projects[background_process][version] = 1.12

; Performance modules
projects[expire][version] = 1.0-alpha2
projects[cache_actions][version] = 2.0-alpha3

; Unstable modules
projects[menu_node_views][type] = module
projects[menu_node_views][download][type] = git
projects[menu_node_views][download][url] = http://git.drupal.org/project/menu_node_views.git
projects[menu_node_views][download][revision] = f46dd41eb8c4e693a6642a6c461afa57d99a6f1b

projects[filefield_sources_plupload][type] = module
projects[filefield_sources_plupload][download][type] = git
projects[filefield_sources_plupload][download][url] = http://git.drupal.org/project/filefield_sources_plupload.git
projects[filefield_sources_plupload][download][revision] = da374770b80fcbc0dab17158d38c8436ef29caca

projects[menu_token][type] = module
projects[menu_token][download][type] = git
projects[menu_token][download][url] = http://git.drupal.org/project/menu_token.git
projects[menu_token][download][revision] = 8c18fbb

; Libraries
libraries[mediaelement][download][type] = "file"
libraries[mediaelement][download][url] = "https://github.com/johndyer/mediaelement/zipball/2.7.0"

; Patches

; #1491150: node_load in menu_node_menu_link_insert is not safe - http://drupal.org/node/1491150
projects[menu_node][patch][] = http://drupal.org/files/menu_node-node_load-in-menu_node_menu_link_insert-1491150-1.patch

; Fix rendering of relation endpoints
projects[relation][patch][] = http://drupal.org/files/relation_table_endpoints_break.patch
projects[relation][patch][] = http://drupal.org/files/relation_bundle_permissions.patch

libraries[jquery-json-min][download][type] = "file"
libraries[jquery-json-min][download][url] = "http://jquery-json.googlecode.com/files/jquery.json-2.3.min.js"
libraries[jquery-json-min][download][sha1] = "2a4615b93c65dd50f92117c570121035a0327fee"
libraries[jquery-json-min][destination] = "libraries/jquery-json"

La ligne api définit l'API Drush make à utiliser pour le reste du fichier. Une chose importante à noter à propos du fichier est que tous les modules ont une version spécifique ou pointent vers une commit git spécifique. Nous n'avons jamais de versions -dev dans nos fichiers. Lorsque nous nous présentons à une réunion client ou que nous remettons le fichier make au serveur Jenkins , il ne doit jamais y avoir de surprise. La version exacte incluse dans le fichier doit être testée et doit passer avec succès tous les types de tests. Ceci est important pour pouvoir livrer quelque chose de haute qualité.

Dans mon entreprise, l'accord général est que chaque équipe fournit un script shell appelé "build", à la racine du référentiel, qui est responsable de la configuration du site, afin que les tests automatisés puissent être exécutés par la même équipe. Configuration CI.

Les mises à jour du module peuvent être effectuées rapidement directement sur les sites pour les tests, mais officiellement en mettant à jour le fichier make et en reconstruisant le site.

Mon équipe utilise actuellement cet ensemble de scripts de build . Je travaille à déplacer une grande partie de la fonctionnalité dans une extension drush qui utilisera massivement la fourniture. Une version CLI d'Aegir si vous voulez.

— Létharion
source

Génie. Merci d'avoir pris le temps d'écrire ceci, c'est très utile

— Clive

Oui, je suis d'accord avec Clive, le vote positif étant un article très utile. Cela m'intéresse de ne pas avoir à répéter l'installation du même ensemble de modules et de correctifs. @Letharion Je vous souhaite chaleureusement la bienvenue si vous pouviez nous expliquer un jour comment procéder. L'installez-vous localement ou sur un serveur distant?

— Artur

Jouer avec drush make. Je comprends parfaitement la raison de la mise en place de numéros de version fixes. Cependant, comment les mettez-vous à jour? Existe-t-il une équivalence drush pour drush up? À un moment donné, vous devez mettre à jour vos versions vers la version la plus récente (en particulier les mises à jour de sécurité).

— Devoir le

Moar questions: avez-vous un fichier .gitignore ou comment éviter de valider des fichiers "créés"? Si oui, à quoi cela ressemble-t-il? J'ai essayé de faire quelque chose d'extraordinaire avec des caractères génériques et! mais cela ne fonctionne pas pour les répertoires.

— Berdir

Je ne suis pas vraiment d'accord. Le manque de -dev est ce qui assure la cohérence, et non l'inverse. Il est de la responsabilité de chaque développeur de s'assurer que le correctif s'applique, ce qui peut signifier faire référence à une révision git au lieu d'une version stable, mais jamais à un -dev imprévisible qui peut changer d'une génération à l'autre.

— Letharion