Discussion :

[chh2008]

Bonjour,
quel est la meilleur méthode pour développez une application en groupe C.A.D sur un un seul exécutable.
merci.

[ShaiLeTroll]

C.A.D = D.A.O ?
C.A.D = C'est A Dire ?

Que veux tu savoir ?
Le Travail en Equipe, les Outils, comme JEDI CVS ou SubVersion\Toitoise SVN, les outils de Microsoft, Visual SourceSafe pour partager le source

Le Travail en Equipe et les méthodes, tu peux modéliser avec de l'UML tout un projet (Base de Données, Interaction entre les Modules,...), tu peux aussi faire du TDD (Test Driven Development) où les specs sont traduites d'abord en Test, l'implementation de la fonction étant faite en paralèlle (légèrement après) des Tests Unitaires par Itérations Successives

[chh2008]

Désolé pour les CAD (C'est A Dire) je m'explique avec le scénario suivant :
l'application final se compose de trois form , l'utilisateur 01 développe la première
l'utilisateur 02 développe la seconde et moi même la troisième .
la question est comme suite peut 'on fusionné ces trois exécutables pour n'en faire qu'un seul ?
merci.

[Paul TOTH]

Désolé pour les CAD (C'est A Dire) je m'explique avec le scénario suivant :
l'application final se compose de trois form , l'utilisateur 01 développe la première
l'utilisateur 02 développe la seconde et moi même la troisième .
la question est comme suite peut 'on fusionné ces trois exécutables pour n'en faire qu'un seul ?
merci.

en admettant que l'on ai bien trois projets distincts

projet1.dpr, form1, unit1.pas
projet2.dpr, form2, unit2.pas
projet3.dpr, form3, unit3.pas

il "suffit" de créer un projet final (.dpr) qui utilise les 3 unités (.pas)
reste à savoir comment les trois développeurs pourront bosser sans les 2 autres unités du projet

[ShaiLeTroll]

il est possible de travailler dans un seul projet
C'est le boulot d'un chef de projet d'établir un planning (PERT GANT) pour gérer la séquence de développement et les itérations à mener

Sinon, SubVersion permet de fusionner des sources (merge) mais perso, je préfère le lock

le TDD peut aider, cela oblige à écrire les prototypes de fonction à l'avance, cela nécessite donc de spécifier l'architecture du code

Là où je suis, on utilise JEDI VCS, sur un projet de 200 unités + une lib interne de 100 unités, on a eu jusqu'à 4 développeurs qui développait simultanément, chacun s'occupait d'une partie, il ne fallait savoir s'organiser si le travail de l'un dépend de l'autre, ... respecter certains conventions de codage et quelques patterns permet aussi de mieux travailler en équipe

[Paul TOTH]

c'est en effet ce que je fais en général

le projet est sur un SVN

j'ai une copie locale du projet sur laquelle je fais des modifs

quand ça fonctionne localement je commit vers le serveur et j'en profite pour récupérer les modifs des autres développeurs (sur les autres parties du projet)

[Franck SORIANO]

la question est comme suite peut 'on fusionné ces trois exécutables pour n'en faire qu'un seul ?

Comme ShaiLeTroll et Paul TOTH l'ont expliqué, vous pouvez très bien travailler chacun avec une copie locale des sources complètes du projet.

L'important c'est de s'assurer qu'à aucun moment, vous ne vous retrouvier à modifier simultanément le même fichier, et surtout que vous écrasiez mutuellement vos modifications.

Pour celà, il existe deux types d'outils :
- Les outils de contrôle de sources : CVS, SVN, VSS (pitié n'importe quoi, mais pas celui là), JEDI CVS...
- Les outils de gestion de configuration (Starteam, Perforce...).

A chaque fois, le principe est le même : Vous créer un référentiel de sources centralisé sur un serveur. Ce dernier est continuellement mis à jour pour contenir la dernière révision de chaque fichier.
Il existe différente stratégie pour traiter les modifications simultanées sur un même fichier :
- Soit tu poses un verrou exclusif sur un fichier source, pour dire tu es en train de le modifier et aucun autre n'a le droit de le modifier avant que tu n'ais enregistré tes modifications et libéré le verrou.
- Soit tu laisses modifier le fichier simultanément par deux personnes à la fois. Dans ce cas, le premier qui commit a gagné ! et le deuxième devra fusionner ces modifications avec la révision de son collègue. Cependant, c'est une opération que les outils de merge savent assez bien faire automatiquement, et tu n'as besoin d'intervenir qu'en cas de conflits. Mais ça suppose que les fichiers puissent être fusionnés. Autrement dit, il faut que ce soit des fichiers textes. Pour les binaires, il vaut mieux travailler avec des verrous exclusifs.

Là où les outils de gestion de configuration se distinguent des outils simples outils de contrôles de sources, c'est qu'ils vont te permettre d'associer les modifications effectuées dans les sources au changement pour lequel tu les as réalisés :
- Imaginons que vous corrigier un bug. La correction du bug a de grandes chances d'avoir nécessité de modifier plusieurs fichiers. L'outil de gestion de configuration va te permettre de gérer l'ensemble de ces modifications comme un et un seul changement, alors que pour un bête outil de contrôle de source, il s'agit de n modifications indépendantes, que vous valider une par une dans le référentiel.

Associer les sources modifiées à au changement à l'origine de la modification est ensuite très important pour la maintenance de l'application :
Lors du développement de la première version, votre seule préoccupation est de ne pas vous écraser mutuellement vos modifs.
Par contre, lorsque cette première version sera entrée en production, et donc maintenance, on se retrouve dans la situation suivante :
- La version 1.0.0.0 est installée chez les clients.
- Le développement est en train de préparer la prochaine version majeur 2.0.0.0
- Alors que la version 2 n'est pas terminée, les clients sont confrontés à des bugs dans la version 1.0.0.0 qui doivent être corrigés, sans attendre la sortie de la version 2.0.0.0.
- Vous devez donc être capables de reconstruire la version 1.0.0.0 à l'identique, puis d'effectuer la correction du bug dans cette version, et sortir un patch correctif 1.0.1.0. Il faudra ensuite reporter la correction du bug dans la version 2.0.0.0 pour que ce dernier ne réapparaisse pas dans la prochaine version.
- Maintenant la priorité et l'importance des bugs changes en fonction de l'humeur et du temps. Vous risquez de rencontrer un bug jugé peut important, corrigé pour la version 2.0.0.0 et laissé en l'état dans les versions 1. Puis un jour un client important fait un caprice, ou je ne sais quoi, et on te demande de livrer la correction du bug dans une version 1.0.2.0. Il vaut alors mieux pour toi que tu saches identifier précisément toutes les corrections effectuées sur la version 2.0.0.0 pour corriger le bug...
- Et pour couronner le tout, imaginons qu'il survienne une modification dans la législation qui t'oblige à modifier des fonctionnalités importantes dans l'appli. Les modifications ne peuvent toujours pas attendre la V2, mais nécessitent davantage de développement et de tests qu'une simple correction de bug. Tu te retrouve alors à devoir gérer une sortie de version mineure : 1.1.0.0. Son développement va prendre un certain temps, nécessiter des tests et des corrections... et pendant ce temps, tu devras peut-être faire encore des corrections qui ne peuvent pas attendre sur la version 1.0.2.0. Il faudra alors reporter ces corrections dans la version 1.1.0.0 et la version 2.0.0.0.
- ...

Bref, tout ça pour dire que la gestion des versions en maintenance devient rapidement un véritable casse-tête. Plus tes cycles de développement sont courts et plus c'est simple à gérer, mais tu n'as pas toujours le choix.
Au final, tu dois gérer simultanément plusieurs branches dans ton outil de gestion de configuration :

- Une branche pour les développements de la prochaine version majeure.
- Une branche pour la maintenance de la version en production, qui recevra ensuite les différents correctifs et patchs mineurs.
- Selon l'importance des projets, une branche d'intégration pour préparer, tester et stabiliser les versions mineures.
(et je préfère ne pas parler des clients qui demandent des développements spécifiques, ou qui arrivent à t'imposer un rythme de mise à jour différent de ce que tu avais prévus (ou qui t'impose de ne leur livrer QUE la correction des bugs qu'ils ont eux mêmes découvert)).

Un outil de gestion de configuration va te permettre de gérer facilement ces différentes branches, et surtout va te permettre de reporter intégralement un changement d'une branche à l'autre, en étant sûr de ne pas avoir oublier un fichier au passage.
De plus, comme il gère également les changements (au minimum, il intègre un bug tracker), il va te permettre de sortir la liste exhaustives des modifications apportées entre chaque versions, et ce, n° de version par n° de version.

Il est très important de bien choisir son outil au départ, car la migration de l'un vers l'autre est souvent difficile et risque de s'accompagner par la perte de tous les historiques sur les fichiers sources.

En ce qui me concerne, en plus de ces problèmes, on gère trois produits différents à partir des mêmes sources. C'est plus ou moins le même logiciel, mais chacun cible des clients différents, avec un rythme de mise à jour différents. Donc en gros, ça veut dire, une branche de développement, trois branches de production, et on essaie de ne pas faire également trois branches d'intégration.

[chh2008]

Merci a tous.