Image
Haut
Découvrez le site de La Belle Assiette
Navigation
20 octobre 2013

Dans les tuyaux de la plateforme

Lors du précédent article nous vous avons fait découvrir la naissance des nouveautés sur La Belle Assiette. Sur celui-ci nous verrons plus en détails comment nous gérons le code source de la plateforme.

Une bonne base

Pour permettre le suivi des modifications apportées à la plateforme et simplifier le travail en équipe, nous utilisons le célèbre gestionaire de code source, GIT.
Nous le couplons au service en ligne Github pour le système de ticket, la centralisation du code et la visualisation de celui-ci.

Nous avons architechturé notre dépot sur la base de deux branches principales permanentes et d'une multitude de branches fonctionnelles temporaire.
Cette architecture est librement inspirée de "Git Flow"

Les deux branches permanentes sont "Master" et "Develop".

"Master" contient uniquement les versions stable de La Belle Assiette. Cette branche est mise à jour à chaque mise en production. D'ailleurs, le serveur public (labelleassiette.fr) ne bouge pas de cette branche. Cette branche est un peu une branche *de garage* dans le sens où elle ne fait que recevoir des modifications.

"Develop" recevra les modifications des branches fonctionnelles. Son état est quasiment stable. Si nous ne sommes pas dans une phase de mise en production, cette branche ne diverge pas de "Master".

Les branche fonctionnelles sont nommées en fonction de leurs apports.
Dernièrement nous avons ajouté un type de menu, elle se nommé "cbo_menucocktail". Sa stabilité n'est pas assurée, c'est la branche de développement.

Nouvelle fonctionnalité

Au commencement d'une nouvelle fonctionnalité, nous créons une nouvelle branche issue de "Develop".

Comme nous l'avons vu dans l'article précédent, la fonctionnalité a été decoupée en petite étapes techniques (les "Issues").

Chaque "Issue" fera l'objet d'un développement et d'un "commit" séparé. Faire de petits commits logiques et fonctionnels permet une revue de code simplifiée.
Chaque commit répondant à un ticket comportera une référence à l'issue. Cela permet de voir le commit à la suite de l'issue dans Github
ABO Request  Link to search results · Issue  1932 · LaBelleAssiette LaBelleAssiette
Egalement, nous avons mis en place un système de template pour les messages de commit

Titre (moins de XX chars)
Description
Issue #XXX

Pour suivre l'avancement des tickets, nous utilisons un systeme de label.
Chaque ticket comporte un label de priorité, jaune, orange, rouge (du moins au plus important). Pour ceux d'avancement, nous avons, "In progress", "On Stage", "Good to GO!" ou "Mods Required"
Une fois l'issue developpée, le label passe à "in progress". Les modifications apportées par le développeur sont encore en local chez lui, mais le reste de l'équipe est au courant de l'avancement de son travail.
A la fin de son développement, le serveur de pré-production passera sur sa branche pour que l'équipe de test puisse verifier son travail. Le label des issues sera actualisé pour passer à "On stage".
Le développeur aura créé une "pull-request" sur github. L'avantage est multiple: mettre à plats les ajouts apportés par sa branche, permettre la revue de toute la branche et indiquer les actions à effectuer lors de la mise en prod.

A ce moment là, les testeurs appliquent le label "Good to GO!" ou "Mods Required" avec un commentaire sur chaque issue.
Le développeur et les testeurs itère jusqu'a que tout les tickets soit "Good to GO!".

En route vers la production

Tout est enfin validé et testé, la prochaine étape nécessite d'appliquer la branche fonctionnelle à "develop". Avec github, il nous suffit d'accepter la pull-request.
Apres un petit tour de test sur cette branche avec le serveur de pre-prod, nous corrigeons les derniers micro-soucis ou nous appliquons la branche "Develop" sur "Master"


Détails precis

Merge

Nous avons fait le choix d'effectuer tout nos merges avec l'option "–no-ff". Nous gardons la logique des branches et il est plus facile d'annuler un merge. 
git merge --no-ff --ff (1)

Rebase

Le rebase est un point important de notre architecture.
Imaginons que  "develop" est mis à jour pendant le développement d'une branche fonctionnelle.
Le développeur souhaiterai bénéficier des ajouts, il lui suffit de "rebase" sa banche. C'est à dire qu'il va avancer le point de création de sa branche au dernier commit de "Develop".

Git rebase

Même s'il ne souhaite pas profiter des ajouts apporter à "develop" pendant le développement de sa branche, il est judicieux de rebase avant de merger sur "develop" pour gérer les conflits en amont.

Aussi, nous privilégions le pull avec l'option "–rebase" pour éviter les commits de merge en cas de travail à plusieurs sur une même branche.

Bug

Il arrive parfois de devoir faire des corrections rapides qui ne peuvent suivre notre organisation.
Dans ce cas, nous créons simplement une branche à partir de "develop" nommée "hotfix_XXX". Nous effectuons un ou plusieurs commits sur cette branche. Puis nous la mergeons (toujours aevc –no-ff) sur "develop" et "master"

hotfixe

 
Cet article vous a intéressé ? Recevez les prochains par email:





Envoyer un commentaire

Écrit par

Catégories

Uncategorized

Tags

,