(dés) avantages de la mise en scène de la production dev-> en utilisant 'drush rsync' vs 'git'?

9

J'ai mis en place un site Drupal sous contrôle git pour les travaux de développement.

Il est parenté dans un référentiel GIT nu, et au fur et à mesure que des modifications sont apportées dans mes divers clones git de travail de projet et repoussées vers le maître, un hook post-mise à jour pousse immédiatement les modifications vers un seul site Web de mise en scène en direct (http: / /staging.loc.). Rien de spécial, fonctionne comme prévu.

J'ai également créé un pseudonyme pour le site "@STAGING". À l'occasion, je souhaite promouvoir mes modifications du site de transfert vers un serveur de production.

Deux méthodes relativement simples me viennent à l'esprit:

(1) À un moment où le site de transfert semble stable, créez le site de production en tant que git checkout à partir du référentiel maître,

(2) utiliser drush rsync+ drush sql-syncdu site de préparation au site de production.

Les deux peuvent fonctionner. Outre le fait que (2) semble plus centré sur Drupal / conscient par nature - le drush est, après tout, un ensemble d'outils spécifiques à Drupal - quels sont les mérites relatifs des deux approches?

Y a-t-il une raison particulière pour laquelle je devrais considérer (1) sur (2)?

Dans les deux cas, "Tout" est sous au moins une instance de contrôle de révision ...

drush version-control staging

— Clive
source

3

J'ai utilisé les deux techniques. Les deux peuvent être utilisés pour garantir que les mêmes fichiers que vous testez sur @stage aboutissent sur @live. L'avantage de rsync est que vous ne vous retrouvez pas avec des fichiers supplémentaires (par exemple ".git" et associés) sur votre serveur de production. J'ai tendance à rsync à un vps, et à utiliser git sur une boîte que je possède (par exemple des sites intranet).

— greg_1_anderson
source

Merci pour le point. Je regardais juste les options d'exclusion. Cela aide à garder les choses propres. Iiuc, je dois spécifier ce qui doit être exclu "rsync' => array ('exclude-paths' => '.git:.DS_Store:.gitignore:.gitmodules:',"dans le fichier .rc, bien que je ne sois pas encore sûr si j'en ai besoin à la fois dans les spécifications des alias source et cible ou simplement dans l'un ou l'autre.

.git doit être ignoré par défaut. Exécutez 'drush --simulate rsync [options] @a @b' pour voir la commande rsync exacte que Drush exécutera. Utilisez --include-vcs si vous souhaitez que drush rsync inclue .git et d'autres fichiers liés à vcs.

— greg_1_anderson

J'ai besoin de lire plus en détail; Je ne savais pas que .git était exclu. Merci aussi pour la simulation. Re: l'OP, je pense que je vais m'en tenir au `` drush rsync '' car il est conçu pour être une méthode de déploiement pour drupal et fonctionne. git peut fonctionner bien sûr, mais j'ai trouvé suffisamment de commentaires pour qu'il ne soit pas conçu pour le déploiement ...

1

Le problème avec l'utilisation de drush rsync est que si plusieurs personnes poussent les modifications sur le serveur.

Votre exemple ne montre qu'une seule personne poussant les changements.

Si vous avez le développeur A poussant ses modifications, puis le développeur B poussant ses modifications, vous voulez que git éponge les conflits, ou que le développeur B éponge les conflits.

— Micheas Herman
source

1

J'utilise en fait les deux. svn / git et rsync ont deux objectifs différents. svn / git sert au contrôle des sources rsyncet sql-syncà la synchronisation efficace de la mise en scène et de la production. drush rsync @staging @prodest très difficile à battre en termes de simplicité et est terriblement facile à intégrer dans la plupart des continuous Integrationenvironnements si vous souhaitez plonger encore plus profondément dans la folie / les méthodologies de qualité du code.

— stefgosselin
source

1

Personnellement, j'utilise Git pour le contrôle de version, le déploiement et la synchronisation de diverses bases de code de serveur, puis rsync pour déplacer / synchroniser les fichiers des utilisateurs (ignoré en ajoutant certains chemins d'accès au fichier .gitignore).

— danbohea
source