Plusieurs postes sont disponibles chez Nmédia!Amène ton talent, on fournit le plaisir!
Livraison d’applications, comment ça marche?

Livraison d’applications, comment ça marche?

10 février 2014Par Patrick Lavoie
Catégorie :

Il est possible de faire appel à une firme pour le développement d’une application ou de tout un écosystème d’applications pour des besoins très précis. Bien souvent, il y aura plusieurs nouvelles versions de ces applications, soit pour des fins de correction d’anomalies ou bien pour l’ajout de nouvelles fonctionnalités. Il est donc important de bien comprendre comment se déroulent ces mises à jour et d’avoir un bon processus pour diminuer les conséquences sur les usagers.

Migration

Il se peut que la nouvelle série de logiciels créée sur mesure remplace des applications existantes. Assurez-vous que vos usagers ont déjà eu une formation au sujet de l’utilisation de ces nouvelles applications. Très probablement, les anciennes données devront être transférées dans le nouveau système. Les anciens logiciels devront rester fonctionnels temporairement, soit pour référence, soit pour y revenir rapidement en cas de souci avec la nouvelle suite d’applications. Il est primordial de bien planifier la transition de l’ancien système vers le nouveau, tout en conservant une porte de sortie si tout ne se déroule pas comme prévu. Après un certain temps, vous pourrez « couper » le lien avec l’ancien système de façon définitive.

Fréquence des mises à jour

Lorsqu’une suite d’applications est en constante évolution, il est toujours préférable d’avoir des mises à jour fréquentes plutôt qu’espacées. C’est donc une bonne pratique de définir des fonctionnalités développées en petites itérations plutôt que d’en avoir une qui a pris six mois de développement et dont l’impact est beaucoup plus grand sur tout l’écosystème. La mise à jour sera alors moins importante, demandera une série de tests plus réduite et aura beaucoup moins d’impact. Car, dans le monde de la programmation, chaque modification aux codes peut avoir une conséquence sur une application de façon plus ou moins importante. C’est alors qu’on gagne à réduire l’étendue d’une fonctionnalité et que le processus de développement « agile » peut aider à y arriver.

Assurance qualité

Il reste néanmoins un aspect à ne pas négliger dans une mise à jour efficace : la phase de tests. Idéalement, une équipe dite d’assurance qualité, soit dans la firme engagée pour développer les applications, soit dans l’entreprise, doit s’assurer de cette tâche. Cette équipe permet dans un premier temps de veiller à ce que toutes les fonctionnalités attendues pour la nouvelle version y soient, qu’elles soient fonctionnelles et sans anomalie ou qu’elles n’en provoquent pas sur les composantes existantes.

Dans un deuxième temps, l’équipe testera de nouveau toutes les fonctionnalités et les applications dans leur ensemble lors de mise à jour d’envergure, appelée test de régression.

Dans un troisième temps, l’équipe de test peut être une référence dans le fonctionnement des différents logiciels, car elle doit en comprendre le fonctionnement dans ses moindres détails. Si une équipe ne peut être dédiée à l’assurance qualité, au moins un utilisateur dans l’entreprise connaissant le domaine des affaires doit tester les mises à jour. Cette personne peut être différente dépendamment de l’application. Ceci est important, car les programmeurs ne sont pas les meilleurs testeurs. Leur logique et leur vision des applications biaiseront le résultat, surtout s’ils testent une fonctionnalité dont ils sont l’auteur. Ils testeront les nouveautés de la manière dont elles doivent être utilisées et non comme un usager qui est confronté pour la première fois à un nouveau fonctionnement. Il peut y avoir autant de versions tests qu’il le faut pour arriver à une version finale satisfaisante.

Risques lors d’une mise à jour

Par la nature des changements, différents problèmes peuvent survenir lors du déploiement d’une nouvelle version, d’une seule ou de plusieurs applications. Comme mentionné ci-haut, la phase de tests peut grandement diminuer les risques d’anomalie. D’une part, elle reflète la version finale que les utilisateurs utiliseront et d’une autre, on teste la procédure de déploiement qui peut comporter de nombreuses mises à jour telles que la base de données, les rapports, les fichiers divers et, bien sûr, les applications elles-mêmes.

Les risques peuvent être de l’ordre de : absence de nouvelles données, perte de données, fonctionnalités manquantes ou non fonctionnelles. Ces risques peuvent entraîner une perte de productivité chez les usagers, des retards dans leur travail ou même des problèmes plus graves en cas de perte de données légales. Vaut mieux prendre plus de temps lors de la phase de tests pour avoir un déploiement sans tracas.

Au moins deux versions nécessaires

Vous l’aurez peut-être deviné, il doit y avoir deux versions de la suite logicielle : une version dite de test et une version de production, celle-là même que les usagers utiliseront. Il faudra donc maintenir deux environnements dédoublés, qui incluront applications, bases de données, rapports et tout ce qui touche à la suite logiciel. Ça demande un peu d’effort et de coordination, mais il sera sans danger de tester et de pouvoir faire toutes les manipulations que l’on veut dans une application de test avec des données de test.

Numéro de version

On parle de version test, version de production et de nouvelle version. C’est donc important de les distinguer d’une manière ou d’une autre. Première des choses, vous l’avez surement remarqué dans les programmes que vous utilisez déjà, il y a toujours un numéro de version bien souvent situé dans une fenêtre « À propos ». Ce numéro représente la mise à jour du logiciel. La structure du numéro peut être personnalisée en fonction de ses besoins.  Elle peut représenter une date, 2014.02.06, ou un nombre complètement arbitraire tel que 1.2.8.13.

[img]skype.png|450||true|Skype|[/img]

Ensuite, il faut trouver un moyen de différencier la version test de la version finale, par exemple, le dernier chiffre pair pour la version de production et impair pour la version test. La distinction peut être obtenue par n’importe quel autre moyen mis en place.

Heure de déploiement

Un point important à prendre en considération est le moment de déploiement d’une mise à jour pour la version finale dite de production. Au vu des problèmes potentiels, il faut éviter à tout prix d’impacter les usagers lors des heures d’opération. Pour des heures de bureau standard, on peut faire le déploiement après 17 h. Comme ça, il est possible de prendre le temps de tout déployer, de vérifier que tout est fonctionnel et, en cas de problème, de prendre le temps de les corriger. Bien sûr, si les heures d’opérations sont 24/7, il faut trouver le moment où les impacts seront moindres si un problème survient.

Porte de sortie

Cependant, il peut arriver que la mise à jour ne se passe pas comme prévu, même après une ou plusieurs versions tests. Les problèmes peuvent être tel que l’application ne fonctionne pas pour une raison inexpliquée allant jusqu’à un problème de mise à jour des données. C’est pourquoi il est primordial de faire une copie de sécurité de la base de données de production avant la mise à jour de celle-ci. S’il y a le moindre pépin, il sera alors possible de restaurer les données à leur valeur d’origine, c’est-à-dire avant le processus de mise à jour. Donc, retenez qu’il faut toujours avoir une porte de sortie si les choses ne se passent pas comme prévu. Ceci permettra aux utilisateurs de revenir à une version antérieure et de continuer à travailler.

Mise à jour automatique

Il est possible d’avoir un processus de mise à jour léger et transparent pour les usagers, ce qui aide grandement lorsqu’il y a souvent de nouvelles versions. On parle de mise à jour automatique sans que l’utilisateur ait d’opération particulière à accomplir. Cela permet donc de s’assurer que tout le monde utilise la dernière version ainsi que les nouvelles fonctionnalités. Conséquemment, la programmation des applications sera simplifiée, puisqu’il ne sera pas nécessaire de supporter plusieurs versions d’une application pour les mêmes données.

En conclusion

Finalement, tout est une question de stratégie et de planification que vous pouvez personnaliser selon vos besoins, en structurant la migration de systèmes existants et la maintenance du nouveau système.

Source image

Application Skype @ Microsoft

Autres articles pertinents

Voir tous les articles