Pré production et data stagging

Sur un site un peu pro, on a deux versions (au moins) :

Une version en production (le site en ligne) et une version en préparation, appelée pré-production.

La version de pré production permet de tester les évolutions qu’on fait sur le site.

Vous demandez une nouvelle fonction, l’équipe technique réalise l’évolution, et envoie ça sur la pré production.

Cela permet de voir ce que ça donne et de valider que ça fonctionne bien.

Pour bien faire ça, il faut que la pré production tourne sur une configuration pratiquement équivalente à celle de production.

L’une des grande difficulté est d’avoir un environnement et des données équivalentes entre les deux environnements. Sans entrer dans les détails, cela coute cher et c’est compliqué à faire…

Bon, ça, c’est pour la partie logicielle, applicative.

Maintenant, on a besoin d’autre chose pour bien travailler, c’est le data stagging.

Le data stagging, c’est un peu la même idée que la pré-production : pouvoir tester en condition quasi réelles des modifications, mais ici, il ne s’agit pas de modifications faites sur les programmes mais sur les données.

Exemples : vous préparez le catalogue de la rentrée, vous mettez à jour les éléments marketing du site, vous préparez des éléments de merchandising (promotions, bannières, …).
Le data staging permet de tester tout ça dans un environnement équivalent à celui de la production, mais sans prendre le risque d’impacter le site en ligne.

Il y a plusieurs façon de faire du data stagging. On peut faire du data stagging logique : tout se fait sur le site en ligne, mais les données sont « dupliquées » entre les deux environnements : la production et le data stagging.
L’autre approche est physique : on crée physiquement deux versions du site, avec des mécanismes de synchronisation entre les sites.

Sans data staging, on est en « direct live » : on fait des modifications, et on regarde sur le site ce que ça donne.

Enfin, une autre solution est de faire ce que fait Apple : fermer le rideau.

apple-store-down

C’est une alternative intéressante, car elle évite la mis en place du data stagging, et permet de tester une mise en ligne avant de la proposer aux internautes.

Finalement, les meilleures solutions sont rarement les plus compliquées 😉

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

10 commentaires

  1. Une version pré-production c’est toujours « chiant » à mettre en oeuvre, il ne faut pas se le cacher. Pour faire vraiment bien les choses, il faudrait à chaque fois cloner le site de production pour tester dans l’état actuel des choses, car bien souvent le site évolue très vite et la version test est échue.

    Mais comme tu le dis, ça prend du temps… et ensuite il faut encore balancer ça sur le site de prod. retester une 2ème fois… J’aime bien la méthode Apple… pas forcément des plus évoluée mais sans prise de tête (ou presque).

  2. travaillant chez un FAI avec des process relativement lourds et très impactants pour le client, si on devait faire ca, on serait down entre 3 et 6 mois par an…
    d’autres bonnes idées de ce type ?

    1. ça c’est autre chose. c’est également une fonction intéressante, que de pouvoir historiser les modifications. Mais le data staging, c’est différent, puisque ça permet de voir le site dans plusieurs configurations.

  3. En ce qui me concerne, je fais le distinguo entre plus de plateformes que cela. Commençons par le début, il faut un environnement de dev, ce qui pour moi, veut dire: Des postes de dev, 1 serveur central de réconciliation et un outil de gestion de version. Vient ensuite l’environnement dit d’intégration, avec les dev en OffShore, il est rare que les services externes soient testables depuis l’Inde (par exemple), c’est encore parfois plus délicat sur l’intégration d’applications internes (la législation voire les règles de sécurité, n’autorisent pas forcément une connexion via l’inde même via VPN), donc une pltf d’intégration pour tester … l’intégration et pour faire de la recette applicative. Ensuite un plateforme de pré-prod, mais attention à ce que l’on entend par pré-prod, car soit c’est, sur un plan applicatif, la copie de la prod (n+1 avant déploiement) soit c’est une plateforme de recette, mais de mon point de vue la pré-prod sert surtout à valider les performances de l’application passée par une recette fonctionnelle sur la pltf d’intégration. Ensuite et enfin, le data-stagging, mais un serveur de stagging, pour moi, encore une fois, c’est un serveur de prè-publication, c’est à dire que cela sert à valider les données qui vont être mise en ligne, et dans ce sens c’est ce serveur qui permet les fonctionnalités de « Visualisation à date » (qu’est ce que donnera mon site à Pâques … ) avec si le système est un peu poussé, la possibilité de simuler le temps qui passe (histoire de pouvoir voir, comment sera publiée, la super promo qui ne démarre qu’à minuit le 29 Février … 🙂 ).
    Évidemment, ca fait pas mal d’env à gérer, la pré-prod, l’intégration sont – trop souvent fusionnées – ce qui conduit à des goulets/pressions/impasses quand il y a à la fois une montée de version majeure en terme de fonctionnalités et qu’il faut faire aussi les tests de perf … Le pb du stagging, est beaucoup plus lié à la nature des données et notamment le contenu statique (issu d’un CMS) qui souvent apporte un complément d’info aux données produits (catalogue) le stagging est associé aux data catalogue, donc il faut penser à la synchro avec le CMS (et donc les templates de publication) et la franchement c’est le BRIN, comme on dit par chez moi 🙂

    Conclusion, oui ça fait beaucoup de plateformes, oui beaucoup ne veulent pas payer pour tous ces environnements, mais non ce n’est pas superflu, c’est au contraire, pour un site dynamique (1 mise à jour majeure par trimestre), une garantie d’un processus de publication maitrisé.

    1. Hello Jean Michel

      Tu as raison, mais tu me connais, je voulais faire un billet court, donc je me suis concentré sur la pré prod et la prod.

      Et toi tu es le seul à faire des commentaires plus long et plus riche que les billets d’origine 😉

  4. Argh, dois-je y voir une critique genre « Ta G%$#!E » ? … bouh sniff,
    J’voulais juste apporter un peu plus de précision, je dirai plu rin !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *