Discussion :

[Arnaud B.]

Bonjour,

Nous avons actuellement plusieurs projets WD15 dans une base GDS en client/serveur HF v15.

Nous avons besoin de migrer un projet en WD16, mais les autres doivent rester en version WD15 pour l'instant.

Comment procéder ?
Faut il :
1°) passer la version du serveur HF en version 16, puis migrer le projet concerné en v16 ?
Que va-t-il se passer pour les projets WD15 ?
2°) ou bien laisser la version du serveur HF en version 15, puis migrer le projet concerné en v16 ?

Pour compliquer, certains éléments sont partagés entre les différents projets.

Si vous avez des retours d'expérience, ils seront toujours les bienvenus.

Cdlt, Arnaud Benhamdine.

[lazariel]

Bonjour Arnaud,

nous avons migré dernièrement un projet en WB 16 en laissant quelques dépendances en version 15. Tout fonctionne à merveille, les projets en version 15 restent en version 15, la compatibilité est totale.

Par contre dans un souci de mises à jour, notre serveur HF C/S hébergeant le GDS a quant à lui été passé en version 16.

Nous avons opéré dans cet ordre :
1) Le serveur HF C/S
2) Migration du projet principal de 15 en 16
3) Laissé et déployé les dépendances en 15

Meilleures salutations

[Bowen]

Nous sommes également dans ce cas :
Nous avons des projets 12, 14, 15 et 16 sur notre GDS, et tout ce monde semble cohabiter. (semble, parce que nous n'ouvrons plus les 12, plus rien à y faire)
Les projets 15 et 16 ont des codes partagés.
Et là... c'est le drame.
Les codes partagés sont bien modifiables en version 16, mais ne sont plus récupérables en version 15. Ce sont des collections de procédures globales.

L'ajout d'un module partagé dans un programme en version 15 ne fonctionne pas non plus ("ce code a été créé avec une version plus récente de windev...")

Bref, mon conseil : sépare le code 15 du 16 AVANT de migrer (clic droit => départager, dans le GDS)
Le code peut sûrement être repartagé entre les versions 15 et entre les versions 16 ensuite.

[lazariel]

Bowen : Tiens? J'ai justement une collection de procédure et un composant développés en version 15 qui sont utilisés sans problème en version 16. Par contre, je les maintiens encore en version 15... Peut-être que la différence est là.

Le système de branche du GDS ne permet-il justement pas de pouvoir partager les deux versions différentes ?

[Bowen]

Si tu connais un moyen de partager le code entre les deux versions, je suis preneur. Nous avons migré un projet en version 16, et si nous récupérons les modifs en 15, le code n'est plus utilisable.
Comment gères tu les branches ? (nous en avons une de créée lors de la migration du projet en 16)

Je pense que cette solution devrait intéresser Arnaud B. également.

[lazariel]

Je ne suis pas certain de bien maîtriser les branches, on ne les utilise pratiquement pas. Je préfère ne pas dire d'âneries mais j'ai de vagues souvenirs du cours sur le GDS qui en vantait les mérites. Dans le cas qui nous intéresse, il permettait de faire une branche pour la version 15 (une sauvegarde en gros) avant de migrer le projet/composant/procédure en version 16 (qui créerait une nouvelle branche).

Par contre, en ce qui concerne la mise à disposition de collections de procédures / composants dans le GDS, il faut savoir que j'ai laissé lesdits composants en version 15 et les modifie en version 15 uniquement. Je ne suis donc pas dans le même cas de figure que toi.

À mon sens, la retrocompatibilité des collections de procédures devrait être garantie tant que tu n'utilises pas de fonctionnalités mises en place dans la nouvelle version, non ?

[Bowen]

Perdu.
Tant mieux pour toi si ça marche, mais chez moi ça ne marche pas.
Le code est "passé" en 16, et il n'est plus ouvrable en 15. Il apparait dans la liste des codes modifiés lors de l'ouverture d'un projet 15, et est marqué "récupération déconseillée" (c'est p-e pas le bon terme, mais c'est ce que ça veut dire)

[Arnaud B.]

Merci à vous pour ces retours,

Si je tente une synthèse je dirai que :

1°) la version du serveur HF C/S ne semble pas avoir de lien avec la version des projets hébergés dans le GDS (à partir de la version 14).
C'est ce qu'il ressort du blog du ST de l'éditeur (billet du 10/01/2011) et de vos retours.

Toutefois, je m'interroge encore sur la configuration suivante :
serveur HF en v16 avec certains projets en version 15 dans le GDS, projets qui vont être bien évidemment continuer à être ouverts et modifiés avec WD15

selon certains posts, si on utilise le serveur HF C/S 16 avec une appli WD15, il peut y avoir des erreurs sur les ordres H...

Ceci serait dû à l'ajout d'informations dans les tables dans les analyses WD16, informations attendues par le serveur HF v16.

Certes, ce problème ne serait dès lors pas spécifique au fonctionnement du GDS, mais en l'occurrence, c'est pour le GDS qu'il se pose à nous.

Ma question est donc la suivante (notamment à Lazariel puisque j'ai vu qu'il était dans ce cas de figure) : ouvrir un projet v15 hébergé dans un GDS que fait tourner un serveur HF v16, et travailler sur ce projet avec WD15 ne provoque-t-il aucune anomalie visible ?

Désolé d'insister mais je crois que ce point est important.

2°) concernant les éléments partagés, si je résume la situation : on peut partager des éléments entre v15 et v16, mais dès lors qu'on les a modifiés avec WD16, ils ne pourraient plus être modifiés avec WD15.

Ca me paraitrait assez logique (bien que pas pratique), car c'est le fonctionnement habituel de Windev en dehors du GDS.

Cdlt, Arnaud Benhamdine.

[lazariel]

Bonsoir,

Je ne peux pas te dire concernant les anomalies visibles car les projets codés en 15 ayant des pages (et donc des résultats visibles directement) n'ont pas été mis à jour et ne sont plus supportés.

Ce que nous modifions aujourd'hui sont des modules utilisés pour d'autres projets migrés en 16 (histoire de faire du neuf avec du vieux). Etant grand "fan" des Hxxx, je peux te dire que je n'ai rien vu d'inhabituel concernant ces modules.

Je peux peut-être ajouter ma pierre à l'edifice en te signalant que nos serveurs HF C/S en prod sont en 16 et que les modules codés + compilés en 15 accèdent dessus sans perte de données apparentes !

Cordialement

[Bowen]

2°) concernant les éléments partagés, si je résume la situation : on peut partager des éléments entre v15 et v16, mais dès lors qu'on les a modifiés avec WD16, ils ne pourraient plus être modifiés avec WD15.

C'est pire que ça. Situation :

• Deux projets V15, des éléments communs aux deux projets (jusque là, tout est modifiable dans un projet, et récupérable dans l'autre)
• Migration du Projet A en 16, le projet B restant en 15
• Ouverture du projet B.

On y voit apparaitre la liste des éléments en commun, décochés, et ça nous propose de les récupérer par le GDS. (par défaut, on ne peut d'ailleurs pas les cocher, sauf que là encore il y a un bug sur la touche "tous/aucun")
Tant que c'est comme ça, le projet B fonctionne.
Maintenant, si on veut modifier le code d'une procédure partagée :
On peut le modifier dans le projet A, en sachant qu'il ne sera pas récupérable en B.
On ne doit pas le modifier en B, car l'extraction nécessaire pour la modification importe du code en version 16, et celui ci n'est pas interprété par windev 15. A la compilation, il nous dit que les procédures de ce module sont absentes du projet.

Conclusion. Deux possibilités pour migrer des projets ayant du code partagé :

1. Migrer les projet en version 16 au fur et à mesure des besoins. (dès qu'on doit modifier un code partagé, migrer les projets où ce code apparait)
2. Départager les codes des projets devant rester en version 15.

[Arnaud B.]

Bonjour,

Bon, au vu des tests menés ce matin, ca ne parait pas si simple.

Déroulement :
1°) Maj du serveur HF C/S en v16 56f (la dernière disponible) : OK

2°) ouverture d'un projet (sans éléments partagés) v15 avec WD16 : WD propose la conversion en v16 :
- extraction de tous les éléments OK
- réintégration de tous les éléments OK
- le projet fonctionne OK

3°) Ouverture des Centres de Contrôle Suivi de projets / Qualité avec WD16 : OK
(nous utilisons ces Centres de Contrôles, dont la base est hébergée dans le même serveur HF que la base GDS)

4°) dans le Centre de Contrôle Suivi de projets, menu Maintenance -> Maintenance de la base des Centres de Contrôles : Migrer la base dans le format le plus récent
--> KO : il est demandé un mot de passe pour modifier les fichiers de la base des Centres de Contrôles (fichiers ReproIncid.fic et Tache.fic).
Mot de passe que bien évidemment je ne connais pas.
L'opération échoue donc.

5°) Lancement de WD15 pour vérifier qu'on puisse continuer à travailler sur les projets v15 :
- au lancement de WD, saisie du login et du mdp comme d'habitude : l'éditeur s'ouvre : OK
- à l'ouverture d'un projet dans le GDS : --> KO : un message d'erreur apparait, indiquant qu'on ne peut accéder au GDS sans être identifié, et demandant de relancer Windev en saisissant un login.
Donc impossible d'ouvrir un projet dans le GDS depuis WD15

Pourtant :
- le login/mdp habituel a bien été saisi !
- le Centre de Controle Suivi des Projets est bien toujours paramétré comme étant en C/S (comme auparavant)
- les login/mdp des intervenants apparaissent bien toujours dans le Centre de Contrôle Suivi des Projets -> Gestion des intervenants.

Je ne sais pas si cela est dû à l'étape 4° qui a échoué (d'ailleurs était elle nécessaire ?)

Si vous avez des pistes, n'hésitez pas.

A ce stade, j'envisage 2 solutions :
- repasser le serveur HF C/S en v15
- et/ou restaurer la base des Centres de Contrôles Suivi des Projets

Arnaud Benhamdine.

[Arnaud B.]

Bon, suite des tests :

- effectivement, la version du serveur HF C/S n'était pas en cause : un retour en v15 n'a rien réglé
- le pb a été réglé en restaurant une version précédente des fichiers Intervenants.fic, Intervenants_Complements.fic et Intervenants_Projet.fic de la base des Centres de Contrôle.

Ils devaient probablement être endommagés, ou bien avoir été modifiés par le CC Suivi de Projets v16 et dès lors plus utilisables par WD15.

Moralité : En v16, ne pas faire CC Suivi de Projets -> Maintenance -> Maintenance de la base des centres de contrôles -> Migrer vers la dernière version, sous peine de problèmes.

[Arnaud B.]

Conclusion. Deux possibilités pour migrer des projets ayant du code partagé :

1. Migrer les projet en version 16 au fur et à mesure des besoins. (dès qu'on doit modifier un code partagé, migrer les projets où ce code apparait)
2. Départager les codes des projets devant rester en version 15.

C'est effectivement le mode opératoire que j'en avais déduit.

Merci pour ce précieux retour d'expérience.

Arnaud.

[lazariel]

Merci à toi pour ces tests, je saurai dans quel menu ne pas aller

[Bowen]

Encore une info : au cas où tu récupères un code 16 dans une appli 15, penses qu'il y a une version 15 du code qui reste disponible dans la branche de sauvegarde du GDS.