Comment pousser les changements d'un environnement de développement vers un environnement de production
Notre équipe de 10 développeurs aimerait utiliser les environnements Dev, Test, Staging et Production pour notre grand site. Comment pouvons-nous rationaliser le transfert de nos modifications d'un site à un autre , en les gardant aussi identiques que possible?
La différence entre cette question et Comment migrer d'un environnement de test vers un environnement de production? est que nous aimerions pousser les modifications automatiquement/régulièrement afin que les environnements ne soient pas très différents.
Nous utilisons un environnement de développement et de production depuis quelques années, et chaque environnement a son propre dépôt de code SVN. Le module Fonctionnalités a été utilisé à quelques endroits, mais il ne fonctionne pas avec les blocs ou le contenu.
Une proposition était d'utiliser Drush et d'utiliser le vidage d'archive et la restauration d'archive pour pousser les changements entre les environnements, mais la production a du contenu fourni par les visiteurs et les utilisateurs et pousser vers la production effacerait ce contenu.
Quelqu'un a-t-il déjà répondu à cette question?
J'utilise un script personnalisé pour tirer automatiquement la production vers les serveurs de sauvegarde et de mise à jour (un serveur de mise à jour est un clone de production aseptisé avec des mises à jour appliquées via pm-update, en attente et prêt pour les tests). Vous pourriez avoir des idées à ce sujet. Cependant, je dirais que ce serait une mauvaise idée de automatiquement synchroniser soit prod vers dev, soit dev vers prod. Ne publiez en production qu'après qu'un humain a testé et validé la version que vous souhaitez mettre en ligne. En ce qui concerne l'automatisation des mises à jour prod-dev, je pense que les développeurs trouveraient cela très ennuyeux.
Une chose que vous pourriez faire assez facilement est d'automatiser les mises à jour de votre serveur de transfert. Tirez simplement la base de données vers le bas de la production, extrayez le dernier code de la branche dev de votre référentiel et exécutez updatedb et votre suite de tests. Un humain pourrait alors valider les résultats et publier le code en production s'il était prêt.
Utilisez Fonctionnalités , Contexte & Boîtes pour la fonctionnalité Blocs, ainsi que Déployer et UUID pour le contenu.
Dans la mesure du possible, utilisez du code, des exportables CTools et mettez à jour les hooks dans les modules personnalisés.
Je cherchais quelque chose de similaire l'autre jour - sauf que c'était un moyen automatique de retirer périodiquement le code le plus récent du référentiel distant vers votre environnement de développement local. IIRC il a impliqué quelques scripts drush. Donnez-moi une minute et je sais que je peux le retrouver.
Pantheon ( https://www.getpantheon.com/ ) fait un excellent travail pour gérer ce flux de travail. J'avais l'habitude de gérer cela moi-même avec git + fonctionnalités + scripts, mais c'était plus difficile que cela en valait la peine. J'ai commencé à utiliser Pantheon et j'ai tellement simplifié ma vie. Personnellement, je préférerais passer mon temps à créer des sites Web plutôt que de m'inquiéter des flux de travail, des serveurs, etc. Ils ont un niveau gratuit pour que vous puissiez lui donner un tourbillon.