Evènements Web

Symfony Live 2013 – Processus de développement au sein d’Overblog

0

Le 4 Avril dernier, Xavier Hausherr, CTO chez Overblog, présentait à l’occasion du Symfony Live 2013 le processus de développement de son équipe.

Ce processus a été complètement revu dernièrement, et laisse derrière lui le traditionnel cycle en V au profit d’un processus agile adapté au fonctionnement d’Overblog.

 

METHODOLOGIE AGILE

 

Les besoins des produits d’Overblog évoluant très rapidement et les spécifications détaillées étant rarement fournies, l’équipe s’est tournée naturellement vers la méthodologie SCRUM pour encadrer ce nouveau processus de développement. Je ne reviendrai pas sur les bases cette méthode, vous pourrez trouver énormément de ressources la concernant sur internet, mais voici les ajustements effectués par l’équipe d’Overblog :

  • Les sprints sont d’une durée de 2 semaines.
  • L’incrément d’un sprint est mis en production le premier jour du sprint suivant.
  • Le contenu du sprint est gelé le mercredi précédent la fin du Sprint afin de consacrer les 2 derniers jours aux tâches de debug et de refactorisation ainsi qu’aux réunions de fins de Sprint (démo et rétrospective)
  • Une revue de code est organisée le dernier jour d’un sprint permettant aux membres de l’équipe de mettre en lumière des parties de code intéressantes venant d’être développées.
  • Le poker planning est étalé sur l’ensemble du Sprint à raison de 30min tous les 2 jours. Cette mesure a été prise afin, d’une part, de ne pas avoir des sessions trop longues et, d’autre part, de pouvoir évaluer rapidement un item qui apparaîtrait au milieu d’un sprint.

 

PROCESSUS DE DEVELOPPEMENT

 

Afin de sélectionner un processus de développement adapté, Overblog a fixé le cahier des charges suivant :

  • Coder sans mettre en péril le projet
  • Travailler à deux ou plus sur des features
  • Tester chaque fonctionnalité avant mise en production
  • Intégration continue pour certaines fonctionnalités
  • Release pour les grosses fonctionnalités
  • Gestion des urgences
  • Être accepté par l’équipe SCRUM

L’équipe s’est d’abord intéressée au « Git Flow ». Le Git Flow est un modèle de structure d’un repository Git présenté par Vincent Driessen (@nvie) dans son post « A successful Git branching model » début 2010. Il se présente de la façon suivante :

 

 gitflow-1

 

Dans ce modèle, le développement s’articule autour de la branche « develop » qui représente le dernier état stable du projet et de la branche « master » qui représente de son côté le dernier état livrable du projet.
Les branches de type « feature » permettent de cloisonner les développements de fonctionnalités et particulièrement ceux qui nécessite plusieurs sprints pour pouvoir être livrables. Une fois qu’une fonctionnalité est terminée et stable, elle est réintégrée à la branche « develop » via un merge.
Lors de la « feature freeze », on crée une branche de type « release » ayant pour vocation d’être livrée en production. C’est cette branche qui est testée, debuggée, refactorisée (les modifications étant également reportées sur la branche « develop »).
Une fois que la release est considérée livrable elle est mergée avec la branche « master » représentant l’état de la production.
Si des bugs importants font leurs apparitions en production, il est possible de créer une branche de type « hotfix » basée sur la branche « master » afin de corriger rapidement le bug. La correction, une fois testée, est alors réintégrée dans la branche « master » (pour pouvoir être livrée) mais également dans la branche « develop » afin que les prochaines versions en tiennent compte.

Il est également possible de travailler à 2 sur une même fonctionnalité en définissant des «GIT remote » pointant vers les repository GIT des postes locaux des développeurs.

Ce processus répond à plusieurs des besoins de l’équipe mais présente plusieurs inconvénients :

  • Il n’y a pas de connexion centralisée
  • Le merge peut être compliqué et la responsabilité du merge n’est pas indiquée
  • Le moment où effectuer des tests n’est pas spécifié non plus
  • Le nom de la branche « develop » n’est pas très significatif

Ces limitations avaient déjà été remarquées par Scott Chacon, évangéliste Git.
Ce dernier propose dans un article daté d’Août 2011 une approche similaire basée sur Github qu’il appelle « Github flow ».

 githubflow-2

 

La branche « master » remplace la branche « develop » du Git Flow et la branche représentant l’état livrable devient la branche « stable ». On retrouve les branches de type « feature » et « hotfix » à l’identique mais les merges dans les branches « master » et « stable » (dans le cas d’un hotfix) se font à l’aide des pull requests de Github. Les modifications de la branche « master » sont réintégrées directement dans la branche « stable » via un processus d’intégration continue permettant de valider le code produit

Cette nouvelle méthode répondait plus largement aux besoins de l’équipe d’Overblog mais l’absence de release posait problème. Ils ont donc pris le parti de créer leur propre processus appelé modestement Overblog Flow;-)

Celui-ci reprend les points forts des 2 méthodes précédentes :

githubflow-3 

On y retrouve donc la structure principale de Github flow auquel des branches de types «release» ont été ajoutées. Leur utilisation n’est pas systématique, ainsi une feature urgente peut être mise en production rapidement via un processus d’intégration continue.

 

TESTS UNITAIRES ET FONCTIONNELS

 

Lors du développement, le développeur écrit et lance les tests unitaires dans son environnement local de développement. Une fois que la feature est considérée comme terminée par le développeur, il soumet une pull request au lead developer. L’incrément, une fois validé, est déployé sur un serveur de test afin de passer une série de tests via Jenkins :

  • Tests unitaires PHP (PHPUnit)
  • Tests unitaires JS (YUI Test)
  • Qualité du code
  • Respects des normes
  • (…)

Une équipe « Qualité » est ensuite chargée d’écrire des tests fonctionnels couvrant la nouvelle fonctionnalité. Ces derniers sont également exécutés sur la plateforme de tests via Jenkins. Ils sont rédigés dans le langage Gherkin et exécutés via Cucumber.

L’incrément est ensuite déployé sur une plateforme de « staging », plus proche de la production (configuration des serveurs, données, etc.) . Il subit alors de nouveau une série de tests via Jenkins (tests unitaires et fonctionnels).

Si les tests sont concluants, l’incrément passe alors en production. Cette dernière étant également testée fonctionnellement chaque nuit.

 

CONCLUSION

 

Dans un esprit agile, Overblog a su composer sa propre méthodologie de travail en s’inspirant et en adaptant des méthodes existantes qui ont fait leurs preuves. Il est certain que cette méthode sera affinée au fur et à mesure des sprints dans les mois et années à venir, s’adaptant aux nouvelles contraintes techniques et humaines de l’équipe et aux nouveautés à venir mais l’ensemble semble déjà un succès au vu de la qualité du travail accompli, du nombres de blogs hébergés et des bonnes critiques sur la nouvelle version du site que l’on peut lire en général.

Vous trouverez ci-dessous le lien vers les slides de la présentation ainsi que les liens se rapportant aux articles cités.

 

REFERENCES

 

 

Symfony et eZPublish : embarquement immédiat

0

Cet article résume la conférence qui s’est tenue lors du Symfony Live 2013 Paris, relative à la nouvelle version du CMS bien connu eZ Publish.

 

@jeanvoye a commencé sa présentation par poser une question simple : « Qui a déjà travaillé avec eZ 3.x ou eZ 4.x ? » Et à ceux qui ont répondu positivement, il leur a simplement dit « eZ 4.x n’est plus eZ Publish, eZ Publish est désormais eZ 5 ».

Pour sa nouvelle version eZ Systems, éditeur d’eZPublish, a voulu se recentrer sur son cœur de métier à savoir la gestion de contenu et l’expérience utilisateur tout en gardant une architecture scalable et durable.

(Note : Durable comme la version précédente qui est opérationnelle depuis 10 ans)

 

Plusieurs pré-requis étaient indispensables pour la conception de cette nouvelle version comme :

  • une intégration simple d’une API ;
  • un modèle HMVC (Hierarchical Model View Controller), donc pas de logique dans les vues, contrairement aux versions 4.x et antérieures ;
  • un nouveau moteur de template ;
  • des composants découplés.

 

Pour répondre à toutes ces attentes, plusieurs choix ont été étudiés. Parmi ces possibilités figuraient notamment :

  • un framework fait maison
  • Zeta Component
  • Zend Framework
  • Symfony 2

 

Et finalement pour sa version 5 d’eZ Publish, c’est le framework PHP Symfony2 dans sa version intégrale qui a été retenu, ccontrairement à Drupal qui dans sa dernière version (v 8) utilise seulement des composants Symfony 2.

 

Les développeurs d’eZ Publish se sont lancés dans un véritable challenge, car ils ont voulu, entre autres, conserver la même structure que eZ 4.x, mais également le système de templating et le fallback au niveau du routage.

Ce chalenge a été relevé avec succès, car eZ Publish 5 permet une entière rétrocompatibilité avec les versions 4.x en incluant directement ce dernier et en utilisant un système de route dynamique qui fait le passage entre les deux versions en fonction du contexte, la base de donnée restant la même pour les deux. Cette fonctionnalité permet une grande souplesse d’utilisation et d’évolutions pour les sites existants en version 4.x. Les nouveaux développements à apporter sur ces sites pourront alors se faire en eZ 5 et l’interfaçage entre les deux ne posera aucun problème.

 

Cette fusion permet à la fois à SensioLabs de confirmer son statut d’acteur majeur de la communauté PHP Open Source, et également à la communauté Symfony de s’agrandir encore plus (ce fut déjà le cas avec la communauté Drupal).

 

Pour conclure en quelques mots sur cette nouvelle version de eZ Publish , elle se présente comme une application Symfony 2 standard + des bundles (API Rest) + un BackOffice pour gérer le contenu.

D’ailleurs la flexibilité du back-office est conservée, on pourra donc le modifier et y apporter des fonctionnalités/des interfaces spécifiques à chaque projet.

Concernant les versions actuelles et à venir, la version 5.0 est disponible depuis novembre 2012, la version 5.1 est prévue pour mi-mai et la version 5.2 est quant à elle prévue pour novembre 2013.

 

Switch to our mobile site