Dois-je contrôler à la source les modules contribués dans mon projet?

On m'a dit que pendant le développement, je devrais contrôler tout ce qui se trouve sites/dans mon dépôt de code (par exemple SVN).

En supposant que je ne toucherai jamais aux modules contrib que j'utilise ( ctools, viewsetc.) mais que je ne créerai que mon propre thème, dois-je quand même le faire?

Ou devrais-je simplement contrôler la source sous tout sites/all/themes/?

Merci

— cherouvim
source

Réponses:

Dans mon équipe, nous sommes passés à l'approvisionnement uniquement de ce qui est spécifique à notre projet actuel. Si nous utilisons Vues par exemple, nous ajoutons l'entrée appropriée à notre drush faire -file, et la version qui , mais pas le module lui - même.

Cela nous laisse un très petit référentiel, composé de tous les modules personnalisés spécifiques au site actuel, au thème actuel et aux exportations de fonctionnalités.

À moins que vous ne puissiez absolument pas utiliser drush et drush make, je ne vois pas pourquoi on devrait contrôler le code de version qui est bien versionné ailleurs. Et si vous avez l'intention de pirater l'un des modules, vous devez ajouter cela en tant que sous- module , encore une fois, sans versionner le code dans votre propre référentiel. (Je crois que cela s'appelle une branche de fournisseur dans SVN).

Edit: Pour plus de détails et une configuration plus avancée, vous pouvez jeter un oeil à ce référentiel: git@github.com: letharion / Drupal-build-scripts.git Les scripts sont écrits en bash pour soutenir le workflow de mes équipes qui comprend un bâtiment un profil d'installation de base ( NodeStream ), puis notre profil spécifique au site en plus de cela, un fichier de création pour chaque profil, des crochets pour l'application de correctifs ou d'autres modifications sur des étapes de construction individuelles, etc. J'espère que je trouverai le temps de re -écrivez-le comme une extension drush dans un avenir proche.

— Létharion
source

Merci pour votre explication détaillée. Oui, j'utilise drush et je prévois d'automatiser autant que possible. Et je n'ai pas l'intention de changer de code dans les modules de base ou contrib.

— cherouvim

+1 versionner le fichier make est une excellente idée, pensez que je le ferai à l'avenir;)

— Clive

@Letharion Je ne comprends pas très bien comment cela fonctionne lors du développement du même site avec différents développeurs en même temps? AFAIK drush make télécharge toujours toutes les dépendances et essaie d'écraser les sites / par défaut, même si ces modules ont déjà été D / L'd, ou existe-t-il une option non documentée pour télécharger uniquement les modules mis à jour / nouveaux? En d'autres termes: je comprends l'intérêt d'utiliser Drush make pour une nouvelle installation, mais comment l'utilisez-vous pour garder les dépendances des modules synchronisées dans une équipe distribuée?

— Creynders

J'utilise cette approche depuis plus d'un an maintenant, mais je me demande maintenant si c'est vraiment mieux que d'avoir tout dans un référentiel lorsque je travaille avec d'autres développeurs qui ne reconstruisent pas la plate-forme tous les jours. De plus, cette approche n'est pas vraiment compatible avec la façon dont Acquia structure leurs référentiels pour leur hébergement cloud.

— David Meister

Pour contrer la réponse de @ Letharion, mettre tout dans SVN est logique pour certaines organisations et cela dépend vraiment de la façon dont vous effectuez vos déploiements. Mettre des modules et des thèmes contrib dans SVN peut avoir du sens si vous avez besoin de remonter dans le temps et de regarder une ancienne version d'un site.

Un exemple de ceci est pratique lorsque vous suspectez un bogue dans un module contrib ou que vous voyez un comportement différent. Pouvoir restaurer une version complète du passé peut aider.

J'ai également trouvé pratique d'avoir un instantané complet du site dans SVN lorsque j'ai besoin de comprendre ce qu'un client a fait à un site. Je peux prendre un instantané complet de leur version, et le coller dans SVN en tant que branche et comparer.

— mpdonadio
source

Pour remonter dans le temps, j'avais également besoin de la sauvegarde complète de la base de données correspondante. Parce que certains paramètres et configurations se trouvent dans la base de données. Est-ce correct?

— cherouvim

Oui. Le module Sauvegarde et migration et / ou sauvegarde d'archive drush est votre ami ici.

— mpdonadio

L'utilisation de cette méthode vous permet de cloner une installation entière à partir du contrôle de version et d'une sauvegarde, ce qui peut être très utile pour le développement ou le débogage de sites actifs.

— keithm