Je travaille avec un autre développeur sur un site Drupal. Nous avons eu du mal à trouver un bon moyen de travailler sur différentes parties du site en même temps sans nous entraver. Nous avons essayé de travailler sur la même instance de développement du site, mais nous marchons souvent les uns sur les autres ou réduisons le site avec un mauvais code, ce qui empêche l'autre de continuer à fonctionner jusqu'à ce qu'il soit résolu. Nous sommes donc passés à des instances de développement distinctes. Mais maintenant, il est très difficile de fusionner notre travail en une seule instance du site. Nous finissons essentiellement par tout refaire sur une copie partagée.
Le plus gros problème que nous avons maintenant est de savoir comment fusionner les modifications de base de données et comment inclure la base de données dans notre système de contrôle de source? Les fichiers sont faciles, il suffit de les suivre tous (nous utilisons git) et de fusionner notre travail, en résolvant les conflits si nécessaire. Mais cela ne fonctionne pas vraiment avec la base de données. Nous pouvons prendre un vidage SQL et l'inclure dans notre référentiel git, mais nous ne pouvons pas vraiment fusionner les bases de données. Le module Fonctionnalités nous aide un peu, nous permettant d'exporter une partie de notre travail de base de données en code qui peut ensuite être versionné et fusionné. Cependant, même pas près de tout prend en charge les fonctionnalités. Donc...
Quelles mesures pouvons-nous prendre pour fusionner facilement nos modifications de base de données?
Comment devrions-nous versionner la base de données (mettre un fichier de vidage dans git une bonne façon de le faire)?
Existe-t-il des modules disponibles qui aident à résoudre certains de ces problèmes?
Ou, sommes-nous coincés à travailler sur la même copie du site? (s'il vous plaît donc non)
Edit: Dans les commentaires, nous avons discuté de ce qui ne peut pas être exporté avec les fonctionnalités et l'un d'eux était les taxonomies. Il y a une autre question à ce sujet .
Réponses:
Il s'agit d'un changement de flux de travail, mais vous devez vous habituer à travailler sur un nouveau vidage de la base de données en direct. Il y a trois façons d'obtenir des modifications dans la base de données.
Si tu peux. Plusieurs fois par jour, obtenez un nouveau vidage et testez votre build, vous devriez avoir moins de problèmes d'intégration.
la source
J'ai répondu à une question similaire et je vais l'ajuster légèrement pour répondre à votre question ici. Ma suggestion de base est que vous ayez un serveur de développement / staging où les changements de code sont vérifiés en utilisant un système d'intégration continue sur une base fréquente (par exemple, toutes les 5 minutes). Ainsi, sur votre machine locale, vous ne travaillez que sur une seule demande de fonctionnalité / rapport de bogue à la fois, en étant sûr de bien délimiter cette tâche des autres sur laquelle les gens pourraient travailler et de communiquer à vos coéquipiers que vous travaillez dessus (redmine ou un autre suivi des bogues est idéal pour cela). Ensuite, vous validez régulièrement les modifications et elles sont transférées vers le serveur de développement / de transfert, tout comme vos coéquipiers. Idéalement, vous avez des tests unitaires intégrés dans votre système d'intégration continue (nous recommandons fortement luntbuild ou QuickBuild pour cela, mais Hudson fonctionne également). Le système CI ou les tests peuvent détecter automatiquement les conflits que vous pourriez avoir introduits dès que vous archivez votre code. Si vous devez apporter des modifications de contenu (non codées), vous le faites sur le serveur de développement / de transfert.
En ce qui concerne la partie de la base de données, j'ai adopté essentiellement deux écoles de pensée ici (une troisième école de pensée, faisant des différences de base de données, je ne discuterai pas parce que la complexité est assez élevée).
1) Déployez en supprimant la base de données de production et en important un mysqldump de la base de données de développement. Facultativement, exécutez au préalable une recherche / remplacement d'expression régulière sur tous les liens absolus codés en dur qui font référence à l'URL de développement dans le vidage SQL. Après avoir importé la base de données dev dans prod, exécutez automatiquement les instructions SQL (généralement via un script) par la suite pour modifier tous les paramètres qui sont différents pour prod que dev (par exemple, vous avez peut-être dans le tableau des variables certains paramètres de connexion pour vous connecter à des systèmes externes dont vous avez besoin pour changer pour pointer vers les systèmes externes prod au lieu de la version dev).
2) Utilisez le module Fonctionnalités, comme mentionné par budda, pour les paramètres d'administration, et utilisez le module Node Export pour l'exportation / importation de contenu en combinaison avec le module Supprimer tout. Le workflow est donc:
utiliser node_export et des fonctionnalités pour exporter des nœuds / fonctionnalités vers des fichiers Optionnellement (et avec un peu de chance) contrôle de version Charger des fichiers sur le système prod Utiliser drush ou une interface d'administration pour charger des fonctionnalités Utiliser drush delete-all ou une interface d'administration pour supprimer tous les nœuds des types que vous souhaitez importer Utilisez drush ne-import ou l'interface d'administration pour importer les nœuds à partir du fichier de nœuds que vous avez exporté. Une note, je suggère fortement d'adopter un flux de travail standard, où le contenu ne va que dans une seule direction. Soit Dev -> Prod ou Prod -> Dev (je préfère celui-ci).
Je l'ai fait et je le fais sur certains gros systèmes, avec des résultats assez bons, mais il y aura toujours de nombreuses façons de trancher cette pomme, choisissez celle qui vous convient le mieux.
la source
Bien qu'il s'agisse d'une vieille question avec une réponse acceptée, je pense qu'il y a encore de la place pour une autre.
Tout d'abord, permettez-moi de dire d'emblée que je ne pense pas que les fonctionnalités soient le bon outil pour cette tâche, et je proposerai un autre ensemble d'outils.
Une condition préalable à la collaboration en équipe est d'avoir un serveur intermédiaire pour tester les versions de développement du projet distinct de votre serveur de production. Tout le code de développement est testé sur le serveur de transfert et n'est envoyé au serveur de production que lorsqu'il est stable et prêt à être déployé. Cependant, les développeurs ne travaillent pas directement sur le serveur de transfert. Chaque développeur travaille sur son propre poste de travail, en utilisant un contrôle de révision et une gestion de code source (SCM) pour coordonner son travail avec le reste de l'équipe.
Le système SCM permet aux membres de l'équipe de travailler en parallèle sur différentes branches du code sans interférer les uns avec les autres. Seul le maître branche est déployé sur le serveur de mise en scène à des fins de test.
Pour mettre en miroir la base de données entre la production, le transfert et les postes de travail, il existe un module nommé Sauvegarde et migration qui peut être utilisé si vous êtes sur un hébergement partagé et ne gérez pas votre propre base de données. Si vous gérez votre propre serveur de base de données, c'est le seul projet sur ce serveur, et vous utilisez mysql , la paire de commandes suivante est pratique:
Jeter:
Restaurer:
Si la vôtre n'est pas la seule base de données sur ce serveur, scriptez une version de
mysqldump(ou l'équivalent si vous n'utilisez pas mysql ) qui sauvegarde vos bases de données uniquement.Définissez une stratégie selon laquelle c'est la base de données du serveur de production qui est maître. Le serveur de transfert et les postes de travail doivent être une copie de la base de données de production, et non l'inverse.
Notez que Drupal 7 conserve tous ses paramètres d'administration dans la base de données. Cela signifie que la mise en miroir de la base de données entre le site de production, le site intermédiaire et les postes de travail fera migrer les paramètres admim sans fonctionnalités .
Maintenant, pour partager le code:
La manière standard de partager du code entre les membres d'une équipe de développement est d'utiliser le système SCM. Drupal se trouve être géré par défaut avec un tel système nommé git .
Git permet l'utilisation de référentiels locaux ou distants. Si les membres de l'équipe se trouvent dans le même espace physique, vous pouvez configurer un référentiel local sur votre serveur de transfert. S'ils sont répartis géographiquement, vous pouvez configurer un référentiel distant. Si cela ne vous dérange pas que d'autres aient un accès en lecture à votre code en cours de développement, vous pouvez utiliser un sandbox sur Drupal.org comme référentiel distant. Vous pouvez également utiliser une zone de projet sur GitHub . GitHub n'est pas seulement un référentiel, mais est livré avec quelques outils de collaboration, et autorise les référentiels publics et privés.
Fondamentalement, un système SCM permet aux membres de l'équipe d'extraire le code source et la documentation du référentiel partagé par les membres de l'équipe, puis de les réinsérer après avoir travaillé dessus. Le SCM garde une trace des changements et s'il y a un conflit (c'est-à-dire que quelqu'un essaie de pousser du code qui ne contient pas les changements qu'un autre membre de l'équipe a commis), il vous le dira et suggérera également un moyen de résoudre ce conflit.
Habituellement, avec une communication cordiale sur la répartition des tâches entre les membres de l'équipe, il n'y aura pas de conflits. Mais avec le système SCM qui garde la trace des choses, les conflits deviennent gérables même si des erreurs sont commises ou une communication échoue.
Il existe de nombreux tutoriels sur la prise en main et l'utilisation de git (GIYF). J'en recommanderai deux: le site Web git-scm et Pro Git par Scott Chacon.
la source