Schéma de migration depuis le dev vers la prod

[namichel]

Bonjour à tous

Parmi la liste de bonnes pratiques, il me semble que l'une d'elle consiste à avoir 3 sites :
dev, test et prod.

Pour migrer de prod à dev et de dev à test, pas de soucis il suffit de tout écraser. Cette étape est largement documentée.

Mais comment fait-on pour migrer de dev à test puis (après validation) pour répéter cela vers la prod ?

Durant le temps de dev, des ventes se font, il y a de nouveaux clients, de nouvelles factures, de nouveaux produits, de nouvelles variantes, de nouvelles images. Côté fichiers il suffit de tout écraser, ça n'a pas bougé mais côté DB on se retrouve avec des modif des deux côtés.

Il est bien entendu inutile de me dire qu'il faut mettre le site de dev en maintenance ou qu'il faut vider le cache.
Ce que je cherche c'est la liste des tables à ne pas restaurer pour ne pas toucher aux données utiles et n'écraser que les tables de modules ou de config. Ou mieux encore, si vous connaissez un module qui fait ça ce serait parfait mais j'ai pas trouvé.

Mille merci d'avance !

 

[Ariane Web et Plus]

Tout dépend ce que vous faites.

Mais en général on developpe un module ou une fonctionnalité et c'est seulement elle qu'on va mettre en prod.

Si vous refaite tous le site, soit vous faites une migration des données soit vous passez la prod en maintenance.

 

 

[namichel]

On 7/1/2023 at 2:59 PM, Ariane Web et Plus said:

Tout dépend ce que vous faites.

Mais en général on developpe un module ou une fonctionnalité et c'est seulement elle qu'on va mettre en prod.

Si vous refaite tous le site, soit vous faites une migration des données soit vous passez la prod en maintenance.

 

 

Bonjour

Merci pour votre réponse, mais je ne vois aucune info utile dans votre commentaire.
Je parle bien de la gestion d'un site et non du développement d'un module puisque je parle de ventes qui se font sur le site durant la phase de dev.
C'est à dire qu'on a un site en prod et qu'on continue à l'améliorer alors qu'il est déjà en service. Pour améliorer ses fonctionnalités, réparer de petits bugs, le mettre à jour, ajouter des fonctionnalités, etc ...

Quelles que soient les modifications apportées, le principe de base me semble être d'avoir un schéma documenté et applicable de façon globale et qui inclue l'ensemble des éléments (fichiers, images, db, config, ...), avec le moins d'exceptions possibles.
Ceci de manière à avoir une structure de travail prévisible et non de la bricole au cas par cas.
C'est ce qu'on fait avec git pour les fichiers, c'est assez carré on fait un "pull" et ça s'applique quel que soient les changements.
Sauf que le git n'inclut que les fichiers, c'est donc une solution partielle à une question plus globale.

Passer la prod en mode maintenance est bien entendu une des étape.
Cette étape doit être la plus courte possible pour perdre le moins de vente possible.
On parle donc d'une étape qui dure 1h max et où on applique les changements effectués et testés à l'avance sur un site de dev, puis approuvé sur le site de test.
Rien que la validation du site de test peut durer 1 semaine ou deux le temps que toutes les personnes concernées fassent des tests, c'est beaucoup trop long pour rester en mode maintenance. On ne peut pas simplement écraser la prod pour la remplacer par le site de test puisque des ventes ont été faites entre temps sur la prod.

Je ne sais pas si je suis clair ...

Une option serait de séparer les tables SQL en deux catégories :

 

• Certaines tables qui sont modifiées par l'activité de prod (typiquement ps_product par exemple, mais plein d'autres aussi )
• Certaines tables "de configuration" qui ne bougent pas lorsqu'on ajoute des produits, des attributs, des clients ou qu'on réalise des ventes. Mais qui peuvent être modifiées par de nouvelles fonctionnalités / configuration.
  (typiquement ps_timezone  par exemple, qui ne devrait pas être modifié par une vente)

Sauf que je n'ai pas trouvé cette liste et que la créer sois-même requiert non seulement un gros travail pour un truc que d'autres ont certainement déjà fait, mais en plus ça nous expose à de possible erreurs pas toujours facile à détecter, genre une table attributs oubliée ou que sais-je.

 

Merci d'avance !

[namichel]

Bonjour

 

Comment se fait-il que personne ne réponde ?

Est-ce que ma question est mal formulée ou est-ce que je ne prends pas les choses dans le bon sens ?