Bonnes pratiques Subversion

mai 13th, 2009

Hello,

je continue sur ma lancée,
après avoir lu énormément de documents, acheté des livres, préparer la mise en place de SVN.

Voici ce que je ressors des bonnes pratiques Subversion.

1° REGLES D’UTILISATION
1.1 Règles sur les livraisons (commit)
Dans l’ordre de priorités :
- Valider que la copie locale fonctionne / compile avant de commiter.
- Faire un update avant de travailler, cela mettra à jour votre copie locale et fusionnera les modifications.
- Faire un update avant de commiter, si vous ne le faites pas et que l’état du référentiel a changé, un message « Out-of-date » apparaîtra afin de vous dire de mettre à jour votre copie locale.
- Pas de message vide ou mal rempli sur la saisie de commentaire.
- Utilisez un Update général plutôt qu’un update par fichier.
- Faites des commit contenant un maximum de fichier par rapport à une fonctionnalité, cela permettra de revenir en arrière plus facilement et évite de polluer les logs.
- Commitez le plus souvent possible.
- Utilisez un système homogène, c’est-à-dire même format de fichier (UTF8/ANSI…), même norme de codage (utilisez un maximum de fois les fonctionnalités de formatage de texte de votre application). Par exemple Ctrl+K + D sur visual studio, Ctrl + F sur eclipse, sinon il convient d’utiliser une convention de tabulation. Cela permettra d’améliorer la gestion des conflits.

1.2 Gestion de conflits
Afin de gérer au mieux les conflits, les équipes doivent pouvoir communiquer facilement entres elles.
Pour limiter l’impact dans l’utilisation de branche, il est conseillé d’effectuer un merge très régulièrement (2 fois par semaine par exemple sur un projet).

1.3 Respect des rôles
La création du référentiel et de sa structure se fait par le service dédié (où minimum 4 personnes pourront le faire).
Pour tout accès supplémentaire à un prestataire extérieur sur un projet, c’est également ce service qui affectera les droits au projet concerné.

Il est important dans la gestion de projet de définir qui est apte à créer une branche et à effectuer les fusions, dans le cas de notre société, la règle est que ce soit le chef de projet technique qui le fasse.

Toute mise à jour du serveur Subversion ou migration d’un ancien projet sur le nouveau serveur sera effectué par le service dédié.

2° GESTION DES FICHIERS
2.1 Structure

La structure du projet doit être faite par le chef de projet technique, il doit mettre en place la politique des fichiers à exclure, l’arborescence à utiliser.
Il faut ignorer les contenus de tous les répertoires qui ne doivent pas être versionnés type (Cache, Temp, etc.)

2.2 Opérations sur les fichiers
Utilisez le plus souvent possible les outils clients pour effectuer les opérations sur les fichiers tels que copie/déplacement/suppression.
Utilisez la même casse pour les noms de fichiers de même type.

2.3 Fichiers à exclure
Un maximum de fichiers binaires doivent être exclus du versionning, cela comprends :

  • Fichiers compilés
  • Fichiers de configuration finaux
  • Fichiers d’imports / exports
  • Journaux d’application
  • Fiches de catalogues / images produits etc.

2.4 Ce que vous pouvez inclure en plus
Dans la phase projet, il est parfois intéressant de pouvoir versionner d’autres éléments que le code source, cela peut-être :

  • Fichiers de modification de structure de base de données
  • Elements statiques de la charte graphique
  • Des fichiers types sur la configuration à adopter (par exemple configuration.dev.php, configuration.preprod.php ou Web.dev.config, web.preprod.config), veuillez par contre ne jamais laisser une extension exotique pouvant permettre de télécharger le fichier s’il devait être disponible en production
  • Documentation de projet / utilisateur

2.5 Mise en production et préproduction
Une réunion sera prévue avec les responsables d’équipes afin de pouvoir mettre en place un système homogène dans les livraisons en préproduction et production.

3° Rappel sur le vocabulaire

Etiquettes de versions

Etiquettes de versions

Head : Dernière révision sur le référentiel
Base : Révision extraite sur la copie locale
Commited : Dernière révision de changement d’un fichier
Prev : Précédente révision avant la révision de changement d’un fichier (Committed – 1)
Commit : Action de livrer des modifications de la copie locale vers le référentiel.
Update : Mettre à jour une copie locale par rapport au référentiel.
Switch : Passer d’un environnement à un autre en ne récupérant que les modifications.
Merge : Action de fusion entre deux branches.
Conflict : Une mise à jour a été demandée mais il est impossible de croiser les données parce que les modifications sont trop proches entre la copie locale et le référentiel, le fichier est donc en statut conflict.
Resolved : Un conflit avait été déclaré sur le fichier, il est maintenant résolu, pour propager cette modification, il faut livrer les modifications.
Get Lock : Verrouiller un fichier afin qu’une autre personne ne puisse livrer ses modifications sur ce même fichier.
Release Lock : Libération du verrou sur le fichier, il est ainsi disponible aux autres utilisateurs.
Export : Exporter signifie copier le répertoire local ou une partie du référentiel dans un répertoire sans aucune référence au versionning.
Import : Importer un projet de la copie locale vers le référentiel, mais ne relie pas les éléments locaux au versionning.
Checkout : Extraction du référentiel vers la copie locale, il est possible de l’exécuter même dans un répertoire non vide.

Répondre