SVNBOOK Chap4 Branching and Merging Common Branching Patterns Release Branches
De Framalang Wiki.
Cette page fait partie du projet Version control with subversion.
| Pseudo | Code | Rôle | Statut |
|---|---|---|---|
| Sub Versif | SVF | Traduction | Fait |
| Hotshot92 | 1ere Relecture | Fait | |
| Validation |
Sommaire |
Titre
Release Branches
Branches de publication
Paragraphe 1
Most software has a typical life cycle: code, test, release, repeat. There are two problems with this process. First, developers need to keep writing new features while quality assurance teams take time to test supposedly stable versions of the software. New work cannot halt while the software is tested. Second, the team almost always needs to support older, released versions of software; if a bug is discovered in the latest code, it most likely exists in released versions as well, and customers will want to get that bug fix without having to wait for a major new release.
En général un logiciel suit un cycle de vie classique, répétant les trois étapes suivantes en boucle : code, test, publication. Il y a deux problèmes avec ce processus. Premièrement, les développeurs doivent continuer à écrire de nouvelles fonctionnalités pendant que les équipes d'assurance qualité prennent le temps de tester des versions supposées stables du logiciel. Les nouveaux développements ne peuvent pas s'arrêter pendant que le logiciel est en cours de test. Deuxièmement, l'équipe doit presque toujours effectuer le support des versions anciennes et publiées du logiciel ; si un bogue est découvert dans le code le plus récent, il existe probablement aussi dans les versions qui ont été publiées, et les clients voudront obtenir le correctif pour ce bogue sans avoir à attendre la publication d'une nouvelle version majeure.
Paragraphe 2
Here's where version control can help. The typical procedure looks like this:
1. Developers commit all new work to the trunk. Day-to-day changes are committed to /trunk: new features, bug fixes, and so on.
2. The trunk is copied to a “release” branch. When the team thinks the software is ready for release (say, a 1.0 release), /trunk might be copied to /branches/1.0.
3. Teams continue to work in parallel. One team begins rigorous testing of the release branch, while another team continues new work (say, for version 2.0) on /trunk. If bugs are discovered in either location, fixes are ported back and forth as necessary. At some point, however, even that process stops. The branch is “frozen” for final testing right before a release.
4. The branch is tagged and released. When testing is complete, /branches/1.0 is copied to /tags/1.0.0 as a reference snapshot. The tag is packaged and released to customers.
5. The branch is maintained over time. While work continues on /trunk for version 2.0, bug fixes continue to be ported from /trunk to /branches/1.0. When enough bug fixes have accumulated, management may decide to do a 1.0.1 release: /branches/1.0 is copied to /tags/1.0.1, and the tag is packaged and released.
Voici où la gestion de versions peut apporter de l'aide. La procédure standard ressemble à ceci :
1. Les développeurs livrent tout leur nouveau travail au tronc. Les modifications quotidiennes sont livrées à /trunk : nouvelles fonctionnalités, corrections de bogues, etc...
2. Le tronc est copié vers une branche "de publication". Lorsque l'équipe estime que le logiciel est prêt à être publié (disons en version 1.0), /trunk peut être copié vers /branches/1.0.
3. Les équipes continuent à travailler en parallèle. Une équipe commence à tester rigoureusement la branche de publication, pendant qu'une autre équipe continue avec les nouvelles tâches (disons pour la version 2.0) sur /trunk. Si des bogues sont découverts dans l'un ou l'autre des emplacements, les correctifs sont reportés de l'un à l'autre selon les besoins. Il arrive cependant un moment où même ce processus s'arrête. La branche est "gelée" pour les tous derniers tests juste avant publication.
4. La branche est étiquetée et publiée. Quand les tests sont terminés, /branches/1.0 est copiée vers /tags/1.0.0 en tant que cliché de référence. L'étiquette est exportée et livrée aux clients.
5. La branche est gérée au fil du temps. Pendant que le travail continue sur /trunk en vue de la version 2.0, les correctifs de bogues continuent à être reportés de /trunk à /branches/1.0. Lorsque suffisamment de correctifs se sont accumulés, les responsables peuvent décider de publier une version 1.0.1 : /branches/1.0 est copiée vers /tags/1.0.1, et cette étiquette est exportée et publiée.
Paragraphe 3
This entire process repeats as the software matures: when the 2.0 work is complete, a new 2.0 release branch is created, tested, tagged, and eventually released. After some years, the repository ends up with a number of release branches in “maintenance” mode, and a number of tags representing final shipped versions.
Ce processus entier se répète au fur et à mesure que le logiciel gagne en maturité : quand le travail pour la version 2.0 est terminé, une nouvelle branche de publication 2.0 est créée, testée, étiquetée et finalement publiée. Au bout de quelques années, le dépôt finit par avoir un certain nombre de branches de publication en mode "maintenance", et un certain nombre d'étiquettes représentant les versions finales publiées.
