La principale caractéristique que tous les VCS utilisent pour les diverses tâches que vous mentionnez est la suivante ramification la possibilité d'isoler un effort de développement de manière collaborative. Comme il s'agit d'un VCS central, plusieurs développeurs peuvent collaborer sur une même branche, avec des verrous pessimistes ou optimistes sur les fichiers, afin de développer une histoire parallèle.
Mais le fait d'être un VCS a deux impacts majeurs sur la ramification :
- Cela tend à décourager les commits, car une fois qu'un fichier est commité, il influence immédiatement l'espace de travail des autres vues avec la même configuration (c'est-à-dire "travailler sur la même branche").
~ Le processus de "publication" est un processus actif, avec des conséquences immédiates,
~ alors que la partie "consommation" (mise à jour de votre espace de travail) est passive (vous êtes obligé de traiter les changements publiés par d'autres personnes dès la mise à jour de votre espace de travail).
- Il fonctionne bien pour linéaire flux de fusion (c'est-à-dire "fusionner uniquement de la branche A vers la branche B, ne pas mélanger les fusions dans les deux sens" -- A vers B vers A vers B...). Les fusions sont triviales, toutes les modifications de A sont simplement reportées vers B.
Maintenant :
Mise en œuvre d'une fonctionnalité
N'importe quel VCS le fera en créant une branche, mais ce qui m'a beaucoup surpris, c'est qu'il n'est pas facile de créer une branche de "fonctionnalité" :
* la fonction peut devenir trop compliquée
* il pourrait être prêt à temps pour la prochaine version
* seule une partie de cette branche doit être fusionnée dans la branche de développement principale.
* il peut dépendre d'autres fonctionnalités qui ne sont pas encore complètement réalisées
Vous devez donc faire attention à la façon dont vous gérez votre branche de fonctionnalité et vos commits : s'ils sont étroitement liés à la même fonctionnalité, tout se passera bien (vous fusionnez l'ensemble vers votre branche de développement principale lorsque vous en avez besoin). Sinon, les fusions partielles ne sont pas faciles avec ces outils.
Correction des bogues
La différence entre la correction des bogues pendant le développement et après la publication est que, dans le premier cas, vous pouvez souvent le faire de manière linéaire dans la même branche, alors que dans le second cas, vous devrez établir une branche de correction des bogues, et décider quels bogues vous devrez rétrocomporter dans votre branche de développement actuelle.
Examen du code
Il est préférable de l'utiliser avec des outils externes ( comme Crucible par exemple), et utilise abondamment les fonctions VCS telles que le blâme ou les annotations, afin de mieux attribuer les corrections de code après une révision.
Refactoring du code (post-review du code)
Si le remaniement est mineur, il peut se poursuivre dans la même branche. Mais s'il est important, une branche spéciale doit être créée, avec des tests unitaires effectués avant de commencer le remaniement.
Incorporer des correctifs
Même commentaire que le dernier point. Si le patch est important, une branche doit être créée.
Lancement de la nouvelle version de votre application
Un VCS ne vous mènera pas loin lorsqu'il s'agira de publier votre application, car il ne s'agit pas d'un outil de gestion des versions.
Vous devrez au préalable identifier une version à diffuser (label), mais après cela vient le processus de déploiement qui implique :
- arrêter ce qui est en cours d'exécution
- copier les nouveaux fichiers
- les déployer (mise à jour de la base de données sql, webapp, ...)
- instanciation de tous les fichiers de configuration (avec les bonnes valeurs, adresses, numéro de port, chemins, ...)
- le redémarrage (et si votre système est composé de plusieurs composants, les redémarrer dans le bon ordre !)
Les éléments clés de VCS et de la gestion des versions sont les suivants :
- ils ne sont pas très bien adaptés pour stocker des binaires à diffuser, ce qui signifie que vous en avez besoin pour construire votre application, et non pour stocker l'exécutable qui en résulte.
- ils ne sont pas toujours les bienvenus dans l'environnement de production (où les contraintes de sécurité limitent l'accès en écriture, ainsi que le nombre d'outils fonctionnant sur ces plateformes, essentiellement des outils de surveillance et de reporting)
Le mécanisme de libération a également une influence sur les dépendances binaires :
- pour les dépendances binaires externes, vous utiliserez probablement des mécanismes comme maven pour obtenir des révisions corrigées des bibliothèques externes.
- mais pour les dépendances internes, lorsque vous ne développez pas une seule application mais plusieurs qui dépendent l'une de l'autre, vous devez savoir comment référencer les binaires produits par les autres applications (dépendances binaires internes), et ils ne seront généralement pas stockés dans votre VCS (surtout dans la phase de développement, où vous pouvez produire des binaires de type beaucoup de versions différentes pour que vos autres applications puissent les utiliser)
Vous pouvez également choisir d'être dans les dépendances de source (et obtenir toutes les sources des autres projets internes dont vous avez besoin pour les vôtres), et un VCS est bien adapté pour cela, mais il n'est pas toujours possible/pratique de tout recompiler.
