ubuntu_webdev-fr AT listes.ubuntu-fr.org
Objet : Liste de discussion autour des sites webs *buntu-fr.org
Archives de la liste
- From: Didier Roche <didrocks AT ubuntu-fr.org>
- To: "Liste de discussion autour des sites webs *buntu-fr.org" <ubuntu_webdev-fr AT lists.ubuntu-eu.org>
- Subject: Re: [U_webdev-fr] Il faut mettre des procédures en place...
- Date: Fri, 16 Jan 2009 10:03:30 +0100
- List-archive: <http://eshu.ubuntu-eu.org/pipermail/ubuntu_webdev-fr>
- List-id: "Liste de discussion autour des sites webs *buntu-fr.org" <ubuntu_webdev-fr.lists.ubuntu-eu.org>
Le 16 janvier 2009 07:52, Ju.
<ju AT jurun.org>
a écrit :
> 2009/1/15 Didier Roche
> <didrocks AT ubuntu-fr.org>:
>> Bonjour,
>>
>> Cela fait 3 fois que je répare la page de téléchargement, et cela
>> commence à m'excéder de perdre 30 minutes à chaque fois pour en
>> retrouver la cause.
>> Une nouvelle fois, quelqu'un a remis le cache de drupal alors que je
>> pense que tous ici êtes au courant qu'il ne faut surtout pas le faire,
>> justement à cause de problèmes comme celui-ci que l'on a rencontré.
>> Perso, c'est la dernière fois que je le corrige :/
>>
>> Donc il faudrait une procédure qui dit "j'ai fait ça, ça et ça sur la
>> prod" car 3, c'est 2 fois de trop :)
>> Bon, je ne vais pas épiloguer, mais il y a trois points à voir en
>> particulier qui trainent depuis plusieurs semaines :
>> - l'erreur sql lors d'une première connexion sans cookie
>> - le module screenshot, qui n'apparaît plus dans les blocs et n'est
>> pas visible sur le site
>> - je n'ai plus de bloc "se déconnecter" une fois, connecté. Est-ce à
>> cause du bandeau supérieur ? Comment cela se passe-t-il avec un
>> utilisateur classique ?
>>
>> Bonne journée :)
>> Didier
>>
>
>
> Je suis assez d'accord, par contre autant eviter le finger pointing,
> c'est toujours penible.
Euh, je n'ai pas fait de finger pointing.
De plus, je ne te visais pas car dans mes souvenirs, j'avais même dit
oui à lestat quand il m'avait demandé si on pouvait réactiver le
cache. Mais sincèrement, je ne m'en rappelle plus si ça remonte aussi
loin...
J'espère que tu ne le prends pas pour/contre toi en cas, c'était plus
une réflexion générale sur il faut améliorer le process (écrit sur le
coup de l'énervement d'avoir perdu 30 minutes à by-passer le même pb
pour la troisième fois consécutive sans s'en souvenir immédiatement)
^^
>
> - comment on teste que le site marche ? ie quelque chose de
> reproductibe (ca veut dire que si c'est manuel chaque etape est
> documentée) et doit etre validé sur dev avant une mise a jour
oui, et documenter (sur le wiki ou ailleurs), comme "le ..., j'ai
modifié cela". Cela nous permettrait de pouvoir retracer les causes
éventuelles des dernières erreurs.
> - Root cause analysis, autant eviter de rentrer en competition avec
> inyoka autant que possible, si l'outil propose un mode cache il faut
> l'utiliser, au moins en mode normal, pas agressif. De fait, certes le
> cache _actuellement_ tue la page de telechargement, mais la bonne
> approche amha, n'est pas de le desactiver, mais de faire en sorte que
> meme activé l'ensemble du site fonctionne comme prevu (ie le probleme
> n'est pas le cache)
Tout à fait, nous sommes d'accord. Il faut fixer cela.
Personnellement, j'avoue mon incompétence dans cette gestion du cache,
vu qu'on renvoie une page et qu'il ne passe plus dans le if
($_GET['source'] != "") {} après rechargement de la page, cache activé
alors que l'on a bien le &source=... dans l'url.
Des infos là-dessus ? Peut-être passer par POST ?
Donc oui, il faut se plonger là-dedans, mais AMHA, il y a des choses
plus importantes en route (comme la disparition du menu de
déconnexion, le module d'images et l'erreur lors de la première
connexion)
>
>
> Ok ca cétait pour les problemes, maintenant les solutions : en fait
> j'en vois qu'une : Selenium http://seleniumhq.org/ (ou un outil de ce
> genre)
>
> En gros ca emule le comportement d'un utilisateur, ci joint le test
> selenium pour le telechargement.
Bien trouvé ! Cela me semble la bonne approche (des tests
d'intégration en quelques sortes), et permettrait de valider tout
changement majeur de configuration avant la mise en prod.
>
> Si on change le open(http://ubuntu-fr.org) par
> http://(www2.ubuntu-fr.org)* , je peux de maniere simple etre sur que
> tout va bien avant de mettre en prod.
> De meme pour le láuth , on peut creer un dummy user, sans droit et
> tester la connexion.
>
Cela implique également que www2 soit une image de la prod
(duplication des bases ?) pour avoir un contenu toujours synchro,
notamment sur les modules qui apparaissent, le contenu en lui même
(rappelez-vous les balises br non fermées ;))
did
> * Je le renommerai en qa pour faire joli.
oui :)
- [U_webdev-fr] Il faut mettre des procédures en place..., Didier Roche, 15/01/2009
- Re: [U_webdev-fr] Il faut mettre des procédures en place..., Ju., 16/01/2009
- Re: [U_webdev-fr] Il faut mettre des procédures en place..., Didier Roche, 16/01/2009
- Re: [U_webdev-fr] Il faut mettre des procédures en place..., Ju., 16/01/2009
Archives gérées par MHonArc 2.6.18.