ou est abandonnée.
Comment ça ?
+0
-0
Zeste de Savoir v1.2 en approche !
Le temps maximum entre la création d'une branche de release et sa mise en production est de deux semaines. Au-delà on considère qu'il y a trop de problèmes et qu'ils risquent de bloquer le développement :
Documentation
Je ne comprends pas. Une release est faite et testée sur la preprod mais quel est le processus pour la "valider" et dire que tout est ok ?
+0
-0
Quand des gens ont testé et ne trouvent plus de problèmes.
+0
-0
Le temps maximum entre la création d'une branche de release et sa mise en production est de deux semaines. Au-delà on considère qu'il y a trop de problèmes et qu'ils risquent de bloquer le développement :
Documentation
Je ne comprends pas. Une release est faite et testée sur la preprod mais quel est le processus pour la "valider" et dire que tout est ok ?
Je plussoie cette question, notamment parce que je me demande si on va mettre en prod la v1.2 avec cette question en suspens.
Est-ce qu'on sait quelles issues sont testées exactement en préprod et combien de personnes ont testées ?
+0
-0
Est-ce que la question soulevée mérite qu'on bloque tout le reste ?
Est-ce qu'on sait quelles issues sont testées exactement en préprod et combien de personnes ont testées ?
Formellement non. Cela dit, à un moment il faut bien avancer…
+0
-0
Est-ce que la question soulevée mérite qu'on bloque tout le reste ?
Pas vraiment, mais je me pose la question (et surtout l’intérêt) du passage en préprod ici si au final on n'a pas de suivi sur ce qui est testé ou pas.
+0
-0
Vu le nombre de coquilles corrigées (Cf delta entre v1.2-RC1 et v1.2-RC2), c'est utile. Parce que les gens qui testent ouvrent des tickets.
Le problème est qu'on a aucune idée de la couverture réelle des tests…
+0
-0
Le problème est qu'on a aucune idée de la couverture réelle des tests…
Il faudra trouver une solution pour avoir un suivi de ce coté quand même un jour
+0
-0
Il faudrait faire une sorte de QA globale sur tout ce qui a été modifié avec une sorte de tableur où chaque testeur reporte ce qu'il a testé si c'est OK et ouvre un ticket sinon.
+1
-0
Et voilà, c'est en prod ! J'ai MAJ la liste des tickets dans le 1er post.
+1
-0
Aïe, y'a eu cassage de la page de profil ? Ou c'est un pb. de cache ?
+0
-0
Vérifie ton cache.
+0
-0
Effectivement. Sinon ça donne ça et ça fait très peur:
+0
-0
Mettez vos caches à jour. 
(Ctrl + Shift + R)
+0
-0
Ca serait pas mal de mettre en place un système de réécriture côté serveur pour qu'on puisse mettre le CSS et le JS sous la forme :
1 2 | style.<version>.css style.v1.2.css |
Ainsi, le fichier est forcément rechargé. Côté serveur il faut "simplement" rajouter un règle de réécriture pour 2 fichiers (c'est pas la mort).
Avec une technique comme celle-ci :
- le cache fonctionne toujours (contrairement à la technique du
style.css?v=1.2 - plus de "faux bugs" à chaque mise à jour.
+0
-0
Yep, on fait cela au boulot pour les MEP (le versionning des ressources front) et ça évite pas mal d'emmerdements.
+0
-0
@DT :
Pour les bugs suivants, on fait ca en hotfix (branche prod donc) ou en fix normale (branche dev) ?
+0
-0
Il faudrait rapidement vérifier le contenu de la variable app.site.url dans le settings_prod.py car il est réglé sur la preprod on dirait…
+4
-0
Hotfix. Rappel pour faire un hotfix : http://nvie.com/posts/a-successful-git-branching-model/#hotfix-branches
On ne merge jamais rien directement sur prod.
+0
-0
Et on remercie gustavi qui vient de mettre le hotfix en prod !
+0
-0
Merci gustavi ! C'est cool qu'on gagne quelqu'un cabable de gérer l'infra !
+4
-0
Connectez-vous pour pouvoir poster un message.
Connexion
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte