Discussion :

[labrosse_15]

Bonjour, mon collègue et moi tentons d'établir nos processus de développement. Windev est tout nouveau pour nous deux, et nous nous demandions de quelle façons les équipes de développement procédaient pour ce qui est de la revue du code par les pairs (code review) avec le GDS. Nous somme tous deux habitué à utilisé github ou gitlab et la revue du code se faisait à partir du pull request en comparant le code de la branche avec le master. Nous n'avons pas réussi à nous bâtir un processus qui nous convenait pour le moment. Les habitués de Windev, comment vous y prenez-vous?

[frenchsting]

Bonjour,

Je ne pourrai pas trop t'aider là-dessus car je n'ai jamais eu de revue de code dans ma vie de développeur. Et ça fait quelques années....

Le GDS te permet de faire des comparaisons de modification d'éléments (fenêtres, états, collections de procédures, classes,...). C'est plutôt fait pour regarder élément par élément. C'est lorsque l'on récupère les éléments qui ont été modifiés (à l'ouverture du projet par exemple) que l'on sait lesquels l'ont été.

Je sais que la version 25 est "compatible" Github. Mais je serais incapable de te dire dans quelle mesure...

[kunnskap]

J'en fait parfois avec mon collègue.
Windev permettrait de faire de la vérif sur la branche par rapport à la branche master, mais ce serait assez fastidieux. Pas aussi intégré que je l'imagine avec git.
La compatibilité de Windev avec git, je ne l'ai jamais vérifiée.

Ce que je fais lors de revues c'est qu'on communique mutuellement sur ce qu'on a modifié. Après dans l'éditeur du GDS je peux trier les derniers éléments modifiés qui ont été commités par mon collègue et afficher les diff par rapport à ma version tant que je ne l'ai pas récupérée. Je les note dans un coin, je récupère les modifs, et j'ouvre les éléments, par rapport à la date et au nom affiché sur chaque ligne, je sais ce qui a été modifié et on parvient comme ça à faire des revues mutuelles de code.

[labrosse_15]

Merci pour vos réponses !

Nous avons regardé rapidement l'option git mais certains fichiers restent binaire et il faut quand même revenir régler les conflits dans Windev. C'est pourquoi nous avons opté pour le GDS qui semble vraiment plus adapté à l'IDE.

Je crois que notre processus sera similaire à celui de kunnskap, c'est-à-dire que nous allons regarder les dernières modifications en fonction des dates. Nous allons mettre de côté les branches, à moins d'être plusieurs à travailler sur un même projet. Dans le pire des cas, nous mettrons de côté la revue par les pairs. Ce n'est pas l'idéal, du moins, l'idéal auquel nous sommes habitué, mais je crois que Windev bouleverse plusieurs de nos habitudes à plusieurs niveaux de toute façon, nous allons nous y adapter.

Merci encore, ce forum est d'une grande aide !

[frenchsting]

Une info concernant les branches : Nous les utilisons pour faire du versioning. Lorsque tous les dév d'une version sont terminés, nous tirons une nouvelle branche. Nous avons alors la version que nous déployons chez le client.
Vu la taille des projets (environ 2Go pièce), nous faisons le ménage de temps en temps :
- les versions trop anciennes sont obsolètes (nous en aurions plus de 150 aujourd'hui et dans versions de WD inférieures à la 14...),
- la taille du disque pour la base du GDS n'est pas énorme,
- Et plus la base du GDS est grosse et plus le GDS est lent...

[kunnskap]

+1 frenchsting, ici aussi on branche dès que la version est testée et mis en production
Par contre une fois que la version devient trop ancienne, on sort le projet de la base du GDS et on l'archive en zip sur un stockage longue durée. Ainsi il n'occupe plus de place sur le GDS sans qu'on le perde.
Pour les branches après, plus on joue avec, plus le GDS risque d'en rater....puis les branches + les composants (internes ou externes), alors là, z'avez intérêt à faire attention où vous mettez les pieds. Prudence.

[labrosse_15]

Un gros merci pour les conseils !

[kunnskap]

Ah mais de rien, reviens partager ton retour d'expérience d'ici quelques temps !