Différentes étapes dans la vie d’un projet

1. Conception
2. Développement
3. Mise en prodution
4. Maintenance et Evolutions

Modéliser tout ça avec Launchpad


. Equipe de projet
`-- Produit
|-- docs
|-- devel
|-- build
| |-- version 1.x
| | |-- version 1.0.x
| | `-- version 1.1.x
| `-- version 2.x
| `-- version 2.0.x
|-- releaseXXX
|-- releaseYYY
`-- NonRegTests
|-- releaseXXX
`-- releaseYYY

Si vous vous referez à mon précédent article, vous saurez pourquoi je préconise la création d’une équipe.

Alors sur la page d’une équipe de projet, vous verrez tous les projets dont est responsable cette équipe.

Pour un produit, vous pouvez créer différentes branches de développement. Et c’est là que j’interviens 🙂

Je préconise de créer différentes branches afin de suivre les différentes étapes de la vie du projet :

[*Pratique : création du dossier de projet

mkdir Produit
cd Produit
*]

• la branche docs (optionelle) :

Cette branche devrait stockée toutes la documentation relative à votre Projet . Launchpad propose une section Blueprints à cette effet . Mais pour une raison de possibilité de migration vers d’autres serveurs, je conseille de faire une copie de cette documentation dans une branche docs

[*Pratique : création de la branche docs

mkdir docs
bzr init docs
# Puis mettre sa documentation dans le dossier
touch docs/Ma_doc
bzr add docs/*
# vérifier avec :
bzr status docs
# Faire votre premier commit
bzr commit -m "Mon premier commit documentation" docs
# voir les révisions
bzr log docs
*]

• la branche devel :

C’est la première branche de développement et elle est très importante. C’est sur elle principalement que va évoluer le projet. vous y mettrez votre code et y implémenterez vos nouvelles fonctionnalités.

[*Pratique : création de la branche devel

mkdir devel
bzr init devel
# Puis mettre son code dans le dossier
touch devel/Mon_Code
bzr add devel/*
# vérifier avec :
bzr status devel
# Faire votre premier commit
bzr commit -m "Mon premier commit developpement" devel
# voir les révisions
bzr log devel
*]

• les branches releaseXXX :

Une fois que vous avez une version stable de votre logiciel, vous voudrez en faire des versions distribuables (releases) . Vous devriez créer une branche pour chaque release majeure. Une release majeur est la livraison un lot de fonctionnalité qu’on avait décidé de livrer. Donc il y a un moment où il faut arrêter une liste de fonctionnalités sur lesquelles on va travailler (et non pas en rajouter au fur et à mesure ) .

Vous créé donc une branche release-N en portant la branche devel stable avec toutes vos belles fonctionnalités sur une nouvelle branche release-N . Cette branche sera utilisé pour les builds et les versions mineures.

[*Pratique : création des branches release-N

# normalement, pour tout bien faire, vous devriez tagger la révision qui sera portée
cd devel
bzr tag release-0.x
cd ..
# copie de la branche, ne pas faire une copie simple (cp -rf) mais bien :
bzr branch devel ./release-0.x
# celà vous permet de garder les traces des fichiers.
bzr log release-0.x
*]

• la branche build :

Vous y stockerez les fichiers distribuables ( source tar.gz, .deb … ) de chaque release, classé par version mineure . C’est le meilleur moyen de savoir lesquelles de vos versions se baladent dans la nature .

[*Pratique : création de la branche build

mkdir -p build/release-0.1/0.1-1
bzr init build
# Puis mettre ses fichiers distribuables dans le sous dossier
bzr add build/*
# vérifier avec :
bzr status build
# Faire votre premier commit
bzr commit -m "Version 0.1-1 ajoutée" build
# voir les révisions
bzr log build
*]

• la branche Tests de non regression (optionnelle mais très conseillée) :

Pour chaque release, il serait bien d’écrire des tests,en particuliers pour chaque bogue (test afin de reproduire le bogue ) afin de vérifier que le bogue est réglé. Si vous stockez ces tests, vous pourrez les réutiliser pour vérifier que vos fix ou évolution ne cassent pas la résolution des bogues précédents.

[*Pratique : création de la branche NonRegTests

# Je vous laisse faire, je pense que vous avez compris le principe ;-)
# vous devriez avoir ça :
.
|-- NonRegTests
|-- build
| `-- release-0.1
|-- devel
| `-- Mon_Code
|-- docs
| `-- Ma_doc
`-- release-0.x
`-- Mon_Code
*]

Evolution et Maintenance

• [* Maintenance *] : travail sur la branche releaseXXX concernée.

Les modifications sur cette branche doivent étre portées sur la branche devel. Ceci permet de retrouver les corrections de bugs sur la branche de développement. Les corrections apporter sur la branche d’une release doivent être porté sur les branches de releases supérieures. L’inverse n’est pas vrai. Cela risquerait de casser la branche de release inférieure si le bug concerne une fonctionnalité qui n’y était pas implémentée. Aussi, face à un bug, déterminez s’il est applicable aux releases inférieurs encore maintenue, et corrigez sur la plus basse release concernée.^[1]

[*Pratique : Portage des corrections de releases sur devel

# faisons un fix
touch release-0.x/Mon_Fix
bzr add release-0.x/Mon_Fix
bzr commit -m "Mon premier fix" release-0.x
# c'est le moment de porter notre fix sur devel
# l'option -d permet de rester à l'extérieur de la branche pour effectuer le merge
bzr merge -d devel release-0.x
# et là on se retrouve avec (tree -L 2)
.
|-- NonRegTests
|-- build
| `-- release-0.1
|-- devel
| |-- Mon_Fix
| `-- Mon_Code
|-- docs
| `-- Ma_Doc
`-- release-0.x
|-- Mon_Code
`-- Mon_Fix
# les changements dans release-0.x se sont retrouvés dans devel
*]

• [*Evolution*] : travail sur la branche devel.

Cette branche est non retroporté sur les branches releaseXXX (pour les raisons cités plus haut). Si vous fixez un bug sur la branche devel, il ne sera pas porté sur les branches de releases existantes. Ce qui signifie que l’utilisateur n’aura jamais son fix sur sa version ( et donc pas sur les dépots de sa distribution Ubuntu par exemple. Donc les fix sur les branches « devel » sont à proscrire.

[*Pratique : Evolutions sur devel

# faisons une évolution
touch devel/Mon_Evolution
bzr add devel/Mon_Evolution
bzr commit -m "Ma première évolution" devel

# et là on se retrouve avec (tree -L 2)
.
|– NonRegTests
|– build
| `– release-0.1
|– devel
| |– Mon_Fix
| |– Mon_Evolution
| `– Mon_Code
|– docs
| `– Ma_Doc
`– release-0.x
|– Mon_Code
`– Mon_Fix
# les changements dans devel ne se sont pas retrouvés dans release-0.x
*]

2{Evolutions et gros fix2}

Quand vous avez une équipe formée de plusieurs développeurs et que ceux ci travaillent sur le même projet. ils voudront certainement modifier un certain nombre de fichiers en même temps. ceci résulte à des conflits non gérables. La préconnisation serait que chaque développeur responsable d’un gros fix ( c’est à dire qui implique beaucoup de modifications ou un relativement long travail ) ou une évolution se fasse sa branche relative à ce produit ( avec le numéro d’iddentification de l’évolution ou du bogue ) et l’héberge sur son espace Launchpad. Un développeur peut travailler sur plusieurs projets donc bien mettre la branche dans le bon projet.

[*Pratique : Gros fix et évolutions

# Prenons l'exemple d'une évolution
# pour un fix nous aurions pris la branche release-N concernée
bzr branch devel ./evolution-2
# Tout se passe comme avec les branches releases sauf que vous devez
# faire un push pour mettre vos changements sur la branche devel
# ne le faire qu'à la fin

# simulons une situation réelle
# la vie continue sur la branche devel
touch devel/Continue_Life
bzr add devel/Continue_Life
bzr commit -m « continue life » devel
# je fais mon évolution
touch evolution-2/Mon_Evolution-2
bzr add evolution-2/Mon_Evolution-2
bzr commit -m « Mon évolution 2 » evolution-2
*]

Je délivre mon évolution [[Si jamais j’essaie un bzr push directement, j’aurais cette erreur :

bzr: ERROR: These branches have diverged. Try using « merge » and then « push »

Ceci est une restriction pour vous empêcher de tout casser :-p. Normalement vous devez faire un « merge » pour récupérer les changements dans la branche devel. vous vérifier que cela ne casse pas votre implémentation. Et ensuite vous faites le push]]

[*
# merge
bzr merge -d evolution-2 devel
bzr ls evolution-2
bzr status evolution-2
bzr commit -m "Merge avant push" evolution-2
# enfin le push
bzr push -d evolution-2 devel
*]

Ouf ! On a fini . Si vous voulez finir en beauté, installez bzr-gtk et tapez bzr visualize devel . Vous aurez une vue de l’évolution de votre projet 😉

P.S. :
Vous remarquerez que je n’ai pas abordé les étapes de téléchargement du code sur Launchpad . Je suppose que vous savez le faire (voir cet article) . L’important c’est de mettre vos codes à des endroits clairs et logique.

J’aurais mis toutes les branches sauf evolution-2 sur la page du Projet de l’équipe, et la branche evolution-2 sur ma page personelle sous ce projet:
[*bzr push sftp://wattazoum@launchpad.net/~wattazoum/Produit/evolution-2*]