Description du problème
Lors d’une mise en prod d’une nouvelle version du back, certains utilisateurs peuvent être sur une ancienne version du front qui n’est pas adapté à cette nouvelle version du back.
Il se peut que des erreurs 500 apparaissent, ou bien que des données ne soient plus enregistrées par exemple.
La situation est rétablie lorsque l’utilisateur rafraichit sa page et utilise donc la dernière version du front, adaptée à la version du back en prod.
Noter que c’est aussi valable sur d’autres environnements, comme sur l’environnement de test (staging) par exemple.
User story
- En tant qu’auditeur, je veux continuer à pouvoir utiliser Ara sans problème lors d’une mise à jour.
Pistes de solutions
- on pourrait fixer un numéro de version unique, le même côté back et côté front, et vérifier lors de chaque requête du front vers le back que le numéro de version est identique. S’il ne l’est pas, le back (qui devrait être plus récent) le signale au front (qui doit être à une version précédente). On peut alors réagir en proposant à l’utilisateur de rafraichir la page par exemple.
🔮 Pensez à lancer et/ou mettre à jour les tests end-to-end si nécessaire avant passage en prod.
Description du problème
Lors d’une mise en prod d’une nouvelle version du back, certains utilisateurs peuvent être sur une ancienne version du front qui n’est pas adapté à cette nouvelle version du back.
Il se peut que des erreurs 500 apparaissent, ou bien que des données ne soient plus enregistrées par exemple.
La situation est rétablie lorsque l’utilisateur rafraichit sa page et utilise donc la dernière version du front, adaptée à la version du back en prod.
Noter que c’est aussi valable sur d’autres environnements, comme sur l’environnement de test (staging) par exemple.
User story
Pistes de solutions
🔮 Pensez à lancer et/ou mettre à jour les tests end-to-end si nécessaire avant passage en prod.