J’utilise le logiciel Digsby comme je vous l’avais déjà mentionné. J’ai eu un pépin avec l’application lorsque je me suis mis à l’utiliser avec deux moniteurs sur mon ordinateur. J’ai soumis un bug directement dans l’application.

Croyez-le ou non, mais le développeur, Steve Shapiro, m’a répondu dans l’heure pour m’indiquer qu’il avait déployé la correction sur internet. Il m’a tout simplement demandé de redémarrer l’application pour qu’elle se télécharge et s’installe sur mon poste. Affaire classée.

Ceci m’amène à dire, lorsque vous êtes en phase d’essais ou de tests, déployez vos corrections rapidement. J’ai souvent vu des projets où les déploiements une fois par semaine ou même une fois par mois. Toutefois, la perception chez l’utilisateur peut s’avérer très négative puisque le bug va être dans leur face pendant toute l’attente. La confiance envers le système risque de perdre des plumes.

Ceci s’applique aussi aux systèmes en production. Les bugs irritent vos usagers et le plus longtemps qu’ils ne seront pas corrigés et déployés, les usagers vont devenir de plus en plus cyniques envers l’application.

J’entends les antagonistes! Vous vous dites que déployer fréquemment risquent de déstabiliser votre application? C’est possible, mais c’est peut-être de votre faute. Avez-vous réfléchit au mode de déploiement de votre application? On est à l’époque du web et de l’instantané. Si pour déployer on doit fermer la salle de serveur pendant 4 heures, vous êtes “out”. Les gens s’attentent que vos systèmes soient disponibles. Vous ragez lorsqu’il y a des travaux routiers? C’est la même chose.

Billet précédent: Les avantages du cloud computing

Billet suivant: Les languages de programmations comparés aux religions

Mots clés: corrections, déploiement, digsby

Ce billet a été publié le 18 décembre 2008 à 7:00. Il est classé sous Développement informatique, Qualité. Vous pouvez suivre les commentaires à ce billet à l'aide de son fils fils RSS. Les commentaires sont présentement désactivés