Changement de version Solution, les précautions à prendre (01/03/2012)

Vous souhaitez profiter de la nouvelle version de Solution Laboratoire annoncée plus tôt cette semaine ? Nous vous rappelons qu’une migration est toujours une opération délicate.

Chantier de migration

Pour chaque migration, nous conseillons à chacun de nos clients, paramétreurs débutants et expérimentés, laborantins et informaticiens, de :

 

1- Tester toutes les fonctions de Solution Laboratoire (paramétrage classique) et TOUS les scripts WinDFL sur la base de tests, AVANT de migrer la base de production. La durée de ces tests est directement liée à la diversité des paramétrages et des modèles d’édition, ainsi qu’au nombre des scripts WinDFL (internes et externes) en place

 

2- Se faire assister d’un chef de projet Altik pour réaliser cette opération. Cette assistance peut prendre diverses formes :

  • Préparation d’une base de tests
  • Passage des scripts de migration (base test et base prod)
  • Recensement des paramétrages, des modèles d’édition et des scripts WinDFL (internes et externes) à tester
  • Elaboration d’un plan de tests personnalisé
  • Réalisation des tests d’après le plan de tests et émission d’un rapport de tests, avec préconisation des modifications à effectuer avant de migrer la base de production

 

Oublier un de ces fondamentaux représente un risque élevé et amène à des situations critiques puisque sous pression de la production des résultats.

 

Macros WinDFL (internes et externes)

 

Lors d’une migration d’une version de Solution Laboratoire antérieure à la version 2007, utilisant l’interface OCI d’Oracle, vers une version 2012, utilisant l’interface OleDB d’Oracle, nous conseillons vivement d’effectuer une relecture du code après avoir migré les scripts à l’aide du script de migration fourni dans le kit.

Le WinDFL s’appuie sur des composants (interface OleDB d’Oracle, composant du système Windows). Il est donc fortement dépendant du comportement de ces composants. Surtout en ce qui concerne la gestion des erreurs.

Les deux seuls points délicats qui ont été mis en évidence à ce jour, concernent le traitement des erreurs après un appel à OdbFetch() ou après un appel à DirOpen(). Dans les deux cas, nous avons apporté une évolution significative des composants utilisés par ces fonctions.

 

Le maitre mot pour réussir une migration, c’est « TESTER », avec la couverture la plus complète possible. Cela prend du temps, mais cela limite les risques lors de la mise en production.

 

 

09:28 Écrit par David BOURGEOIS | Lien permanent | Commentaires (0) | |  Facebook | |  Imprimer |