Dépot subversion et Conventions de développement

Adresses du Dépot subversion :
Version en cours de développement(alpha) : https://www.bazzanella.org:888/com_asradius/svn/trunk
Versions béta intermédiaires : https://www.bazzanella.org:888/com_asradius/svn/trunk/branches/BL-x.x.x.x
Versions Release Candidate intermédiaires : https://www.bazzanella.org:888/com_asradius/svn/trunk/branches/RC-x.x.x.x
Dernière version de production stable : https://www.bazzanella.org:888/com_asradius/svn/trunk/tags/LIV-x.x.x.x

Droits sur le dépot :
le groupe dev fait partie des développeurs éventuels dit contributeurs. Ils ne peuvent pas livrer de versions stables. Ces versions sont vérifiées et livrées exclusivement par le noyau de l'équipe projet: le groupe administrateurs.
Le groupe rapporteur a un droit de lecture seule sur le dépot.

  • groups
    • owner = thierry
    • administrateurs = thierry,thus,microbug,syrus,sxpert,antibug
    • dev =
    • rapporteurs =
  • Racine (/)
    • @owner = rw
    • @administrateurs = r
    • @rapporteurs = r
    • @dev = r
  • trunk
    • @owner = rw
    • @administrateurs = rw
    • @rapporteurs = r
    • @dev = rw
  • branches
    • @owner = rw
    • @administrateurs = rw
    • @rapporteurs = r
    • @dev = rw
  • tags
    • @owner = rw
    • @administrateurs = rw
    • @rapporteurs = r
    • @dev = r

Convention de nommage des versions :
Version W.X.Y.Z

  • W : Numéro de version majeure. (Ajout de fonctionnalités majeures)
  • X : Numéro de version mineure (ajout de fonctionnalités mineures)
  • Y : Numéro de révision (Révision marquant la correction d'un bug logique ou fonctionnel en phase béta, rc, et production dites stable ou bien d'adaptations fonctionnelles de dernière minute pour l'utilisateur final)
  • Z : Incrémenté de 1 à chaque correction de bogues.( pour les bogues en phase béta, rc, et production dites stable)

Convention des phases de développement :

  • ALPHA (répertoire trunc): Première phase de développement concret du logiciel après le codage de l'application satisfaisant les fonctionnalités prévues dans la milestone(étape) correspondante.
    • Risque de bogues importants. (testée sur un serveur de développement)
  • BETA (répertoire branches préfixe BL): Deuxième période d'essai du logiciel avant sa publication.
    • Soumis à de nombreux tests avec des outils de tests unitaires et par l'équipe projet.
  • RC (répertoire branches préfixe RC): (Release Candidate). Une telle version du logiciel correspond usuellement, à quelques bogues près, à la version « finale » ou « stable » du dit logiciel ; elle est mise à disposition à l'équipe projet et à certains testeurs externes choisis, à des fins de « tests de dernière minute » visant à déceler les tous derniers bogues subsistant au sein du programme.
  • STABLE (répertoire tags préfixe LIV) : Le logiciel peut accomplir toutes les tâches prévues sans erreur, il arrive à sa version finale ou stable. Normalement, aucun bogue connu trouvé dans cette phase.
    • On préfixe les versions stables par LIV- et on fige le code dans le répertoire de marquage tags (lectures seules).
  • EXPERIMENTAL
    • Branche expérimentale (préfixé EXP dans branches). (testée sur un serveur de développement)

Le passage d'une version BETA à une version RC (Release candidate) s'obtient par un gèle des fonctionnalités de la BETA. Les développeurs opèrent sur la branche de la BL et la fusionne vers la RC au fil des résolutions des derniers bogues connus. Lorsque tous les bogues connus ont été fixés, on considère la RC comme stable et on la marque comme version dites de production stable.

Convention des résolutions de bogues :
Quelque que soit la phase de développement, et lors de la résolution d'un bogue simple ou complexe on créé la branche correspondante (BUG-numero), puis on marque cette branche (marque PRE-numero). On résoud le bogue dans la branche (BUG-numero), et on fait des tests unitaires de vérification. Une fois les tests réussis on commit et, on marque la résolution du bogue (POST-numero) dans la branche (BUG-numero).

On fusionnera ensuite le correctif dans la branche voulue (Grace aux marques PRE-numero et POST-numero). Une fois le correctif fusionné, on relancera les tests unitaires une seconde fois dans la branche voulue pour vérifier que tout fonctionne correctement.

  • Branches de correction de bogues
    • Préfixé BUG-numero avec numero comme le numéro du bogue dans le répertoire de branches
  • Marque de pré-correctif
    • Préfixé PRE-numero avec numero comme le numéro de bogue dans le répertoire de marques tags
  • Marque de post-correctif
    • Préfixé POST-numero avec numero comme le numéro de bogue dans le répertoire de marques tags

Convention de codage de l'application :
Chaque fonction doit être commentée précisément :
SE pour spécifications externes : Décrit l'objectif de la fonction
SI pour spécifications internes : Décrit certaines caractéristiques internes importantes de la fonction.

Le code doit être aussi simple que possible et fonctionner sous PHP 5 ou supérieur.

Formatage conseillé : 

function name( param1, param2, paramN )
{
 code
 ....
}

if ( condition(s) )
{
}
else
{
}

$variable = nomdefonction( param1, param2, paramN );

Si un morceau de code est complexe par nécessité, il doit être commenté de manière explicite.

L'organisation de l'application respecte autant que possible le modèle MVC (Modèle, Vue, Contrôleur) appelé également architecture 3 tiers.