Quelle est la meilleure stratégie de déploiement?

82

La configuration d'un magasin Magento ne consiste pas uniquement à développer des extensions auto-installables, elle nécessite également de nombreuses opérations de "saisie manuelle", telles que la création d'attributs d'édition finale, de catégories, de produits, de règles de tarification, de pages CMS, etc. les modifications apportées à la configuration du système.

J'aimerais que votre aide définisse la meilleure stratégie à adopter pour déployer une boutique Magento du développement à l'environnement de stockage et de production.

Une de mes stratégies consiste à écrire un "module de déploiement" qui crée par programme les entités mentionnées ci-dessus, mais c’est une tâche très fastidieuse et qui me semble parfois un peu exagérée.

Récemment, j'ai commencé à utiliser Selenium IDE pour reproduire des tâches d'administration, mais le temps requis pour configurer toutes les suites de tests n'est pas très éloigné de celui mentionné ci-dessus.

Une solution optimale pourrait peut-être être l’utilisation d’un module capable de réaliser une capture instantanée d’un système Magento vous permettant de choisir le type de déploiement à déployer.

Alors:

Quelle est votre stratégie pour déployer?
Existe-t-il un module capable de réaliser une capture instantanée d’un système Magento vous permettant de choisir le type de déploiement à déployer?
si un tel module n'existe pas et si un tel module constitue une solution raisonnable, y a-t-il quelqu'un qui souhaite contribuer à le développer?

Je vous remercie!

deploy admin entities

— Alessandro Ronchi
source

Cela pourrait indiquer la nécessité d'une autre balise ou catégorie de balises. Êtes-vous un magasin unique ou recherchez-vous des suggestions générales en tant que prestataire de services? Dans ce dernier cas, toute réponse devra être assortie de "dépend du degré de contrôle que le client veut sur les données d'entité".

— Benmarks

Mon point de vue est celui d'un développeur appartenant à une équipe de développement. Supposons que je développe une section qui a besoin de certaines données pour fonctionner, disons une structure de catégories. Je crée la structure via Admin, crée le code et pousse mon code. Je me demande si la meilleure stratégie consiste également à écrire et à envoyer du code qui crée la structure de catégories nécessaire. Que se passe-t-il si ma structure ou mes paramètres de catégorie entrent en conflit avec ceux d'autres développeurs qui ont poussé les leurs? Comment gérer les conflits? C'est mon point.

— Alessandro Ronchi

@AlessandroRonchi C'est un point discutable et un conflit qui ne devrait jamais se produire. La structure de votre catégorie ne devrait pas être modifiée de manière frivole. Par conséquent, un développeur ne devrait pas imposer un changement majeur à votre structure, sans que les autres le sachent. Si cela se produit, vous devez adresser votre communication inter-dev. En règle générale, la structure des catégories pour un site doit être épinglée dès le premier jour et ne doit plus jamais être modifiée, mais simplement complétée. Si vous avez besoin de le changer, vous ne l'avez pas correctement défini la première fois.

— ProxiBlue

@dedmeet malheureusement, dans le monde que je connais et dans lequel je travaille, les choses changent chaque jour; les clients changent d'avis, les développeurs changent d'avis, des cygnes noirs se produisent. Je dois être prêt aux changements; Quoi qu'il en soit, même si la structure des catégories n'a pas besoin d'être modifiée dès le premier jour, il ne s'agit que d'une petite partie de la partie entière et la partie entière est un projet "en cours" qui est censé changer afin de faire avancer les choses.

— Alessandro Ronchi

ok, d'accord, nous travaillons dans un environnement en constante évolution, mais je persiste à penser qu'un conflit de structure de catégorie ne devrait pas se produire. Il ne devrait pas exister de multiples branches où chacune change de structure, ce qui entraînera simplement des problèmes et une perte de temps de développement. Pourquoi dev est-il un temps perdu à faire des changements de structure, alors que dev b fait la même chose, à une structure différente, et tous deux poussent leur travail? Si la structure doit changer, tous les développeurs impliqués dans le projet doivent être impliqués dans le processus de définition de la nouvelle structure. Pouvez-vous donner un exemple pour m'aider à comprendre quand cela peut arriver?

— ProxiBlue

39

Mon opinion est de tout scripter. J'ai généralement un module de configuration de base pour tout ce qui n'est pas directement lié à un module spécifique du point de vue fonctionnel. (exemple, création de réécritures d'URL personnalisées pour les URL de site précédentes dans les nouvelles URL de site) et ajout de tout élément lié à un module dans ses propres scripts d'installation.

L’état d’esprit derrière cela est que si le site doit être réinstallé, en utilisant une nouvelle base de données, tout revient comme vous l’aviez précédemment. Cela aide également dans le fait que je mets à jour périodiquement le site uat avec une copie de la base de données en direct. Les modules dans uat continuent alors de fonctionner alors qu’ils reprennent leur configuration.

Les modifications apportées aux tarifs d'affranchissement, aux règles de panier, etc. Cela inclut les données du produit. Le client a le choix et est encouragé à tester d’abord les nouvelles importations sur le site uat.

Les clients ne doivent pas créer d'attributs, mais les faire créer via une demande de ticket. Cela me permet également de collecter des informations sur l’intention du client pour l’attribut. Parfois, j’ai une meilleure suggestion à faire, ou je peux créer un meilleur code, car j’ai un descripteur des attributs existants, ainsi que des attributs sélectionnables, afin d’assurer la confidentialité des données. nettoyer.

Oui, les scripts prennent plus de temps, mais il faudra beaucoup plus de temps pour recréer manuellement plus tard les paramètres de configuration de sites entiers. Cela peut également être embarrassant si vous oubliez quelque chose et si vous faites en sorte que le site ne fonctionne pas correctement, ou si vous avez un nouveau développeur qui travaille sur un site local et qui manque d’une configuration cruciale de configuration.

— ProxiBlue
source

1

Je suis d'accord avec dedmeet. Lorsque vous apprendrez à écrire toutes les mises à jour pour la première fois, le travail sera peut-être plus initial, mais si vous devez appliquer manuellement les mises à jour de configuration pour 3 ou 4 développeurs, la mise en place, la vie réelle et active, la coordination et le travail réel prendront beaucoup plus de temps. Notre flux de travail est assez similaire: si la configuration est nécessaire pour une extension (réutilisable), mettez-la ici. Si la configuration est spécifique au client, placez-la dans une extension spécifique au projet. Une des rares exceptions concerne les règles de panier qu'il n'est pas amusant de mettre à jour / créer du tout.

— Matthias Zeis

1

Je viens de publier un module qui aide à créer le script de configuration requis, éliminant ainsi le travail banal de la création manuelle des scripts d'installation. Le module utilise un affichage en grille de la table core_config_data pour autoriser les sélections des valeurs de configuration à exporter. Simplifiez-moi un peu la vie et j'espère que cela fonctionnera pour les autres. proxiblue.com.au/blog/magento-config-data-generator

— ProxiBlue

27

J'avais fait des recherches plusieurs mois auparavant. Voici les sites que vous pouvez consulter.

~~URL de base Magento et installations de~~
développement ~~/ staging~~ Magento Développement et déploiement de
Magento Guide Git de Magento et
déroulement des opérations Dumping plus rapide d'une base de données Magento MySQL pour le branchement

— Oğuz Çelikdemir
source

1

Merci, je vais tous les lire et revenir avec quelques considérations.

— Alessandro Ronchi

J'ai lu tous donner des ressources; J'en connaissais déjà certaines, d'autres que je ne connaissais pas sont très intéressantes. En tout cas, aucune d’entre elles n’est la solution à mon problème et j’ai décidé de dessiner une extension qui tentera de répondre à mes besoins. Merci à vous tous qui m'avez donné de précieux conseils. J'espère revenir ici avec quelques résultats.

— Alessandro Ronchi

Cher Alessandro, je voudrais voir votre chemin pour lequel je cherche aussi une technique plus confortable!

— Oğuz Çelikdemir

18

Je voudrais tous vous remercier car vos considérations m'ont inspiré et poussé à développer une extension appelée "Mageploy" dans le but de résoudre le problème de la synchronisation des différents environnements.

http://www.mageploy.com

Mageploy doit encore être étendu, bien documenté et entièrement testé, même si je l’utilise déjà dans quelques projets présentant certains avantages.

C'est open source et toute aide ou suggestion sera appréciée.

Cordialement

— Alessandro Ronchi
source

7

En ce qui concerne l'installation de scripts et la création d'entités, mon sentiment général est que, s'il est requis ou attendu par un module, il devrait être créé dans le cadre d'un script d'installation.

Récemment, en termes de développement / stade / production, nous utilisons le site de transfert en tant que copie maîtresse de la base de données pour le contenu, car cela signifie que le client peut collaborer. Dans le passé, le problème le plus important que nous ayons rencontré est probablement la coordination de la saisie du contenu avec le client, en particulier en ce qui concerne le téléchargement de produits.

Comment pensiez-vous que l'instantané fonctionnerait? Je pense que dans un monde idéal, vous auriez un outil qui montrerait la différence entre deux bases de données sur des types particuliers (produits, catégories, CMS, etc.) et vous permettrait de fusionner les modifications mais je ne suis au courant de rien de tel que cette.

— Paul
source

1

"En ce qui concerne l'installation de scripts et la création d'entités, mon sentiment général est que, s'il est requis ou attendu par un module, il devrait être créé dans le cadre d'un script d'installation." C'est le point le plus important à prendre en compte et s'applique aux paramètres de configuration. Mon test rapide: quand j'ai besoin d'un nouveau dev pour cloner le référentiel et installer l'environnement, que faut-il pour que le système fonctionne?

— Benmarks

Le partage d'un site de stockage intermédiaire avec des clients pour collaborer à la configuration est génial en théorie. En pratique, les clients ne vous disent pas tout ce qu'ils ont changé 99% du temps, ce qui facilite les choses. Nous pouvons permettre aux clients de travailler sur des éléments tels que des règles de panier, des catégories, des produits ou similaires, mais nous ne les laissons pas interférer avec la configuration.

— Matthias Zeis

6

À mon avis, créer et éditer des attributs, des catégories, des produits, des règles de prix n’ont rien à voir avec une "stratégie de déploiement". Tous ces articles sont assez spécifiques à un magasin et exigent dans la plupart des cas une analyse et une recherche appropriées des produits que vous vont vendre.

Si vous créez des magasins "one size fits all" avec une configuration similaire de tous les éléments que vous avez mentionnés, vous pouvez simplement exporter votre "base de données" après avoir effectué toute la configuration requise pour chaque magasin.

— Rutger
source

Non, "la taille unique" n'est pas le problème; En tant que développeurs, nous rencontrons la même situation lorsqu'il est temps de fusionner notre code source avec celui d'un autre membre de l'équipe de développement: dans ce cas, nous avons des systèmes de contrôle de code source qui fonctionnent comme par magie. Ma question concernait davantage l'opportunité de fusionner des éléments "non dev" tels que les paramètres de configuration, les paramètres et entrées d'administration typiques.

— Alessandro Ronchi

Ah ok, ça rend les choses plus claires

— Rutger

Supposons que nous créons un nouveau site Web complet, ce qui évite les problèmes de données anciennes, etc. Tous nos développeurs utilisent presque toujours la même base de données pour se développer. Cela résout beaucoup de problèmes. Dans d'autres cas, je n'ai pas (encore) de meilleure solution que d'écrire toutes les étapes nécessaires dans une sorte de feuille de route / script et de les répéter toutes après la fusion. Si une seule personne est responsable des paramètres d’administration "magento core", ceux-ci ne devraient pas se faire en plusieurs étapes. Une fois, j'ai trouvé ça, mais je ne l'ai jamais essayé tinybrick.com/magento-modules/admin-tools/…

— Rutger le

2

J'aimerais ajouter deux excellents outils permettant de gagner du temps:

Pour le développement: IDE PhpStorm avec le plugin Magicento
Pour le déploiement: Magentify , une recette de Capistrano pour Magento

— Osondoar
source

Merci de nous avoir parlé de Magentify, je ne le savais pas et je vais l'essayer. Cependant, mon objectif était davantage de synchroniser différents environnements de développement que de déployer dans le sens de la publication d'une base de code. Mageploy pourrait être intégré à Magentify, mais il s'agit d'un outil différent, utilisé pour maintenir automatiquement une partie des modifications de la base de données alignée indépendamment des ID spécifiques qui diffèrent d'un environnement à l'autre. Cordialement, Alessandro

— Alessandro Ronchi