[Techdays 2014] Cycle de vie d’un projet web agile avec TFS 2013, Azure VM et Monaco

Techdays2014Ceci est un retour sur la session « Cycle de vie d’un projet web agile avec TFS 2013, Azure VM et Monaco » des TechDays 2014.

Elle a été découpée en trois parties :

  1. Quelques rappels sur l’industrialisation et azure
  2. La mise en place d’un projet
  3. La réalisation de celui-ci.

Cette Session a été animée par Franck Farré et Fabrice Hautot, tous deux de chez SQLI.

Pour voir le pitch de la session, c’est par ici : Descriptif de la session .

Rappels sur l’industrialisation

J’ai beaucoup aimé leur rappel sur l’industrialisation qui est « Une démarche pragmatique et progressive » basée sur différentes briques parmis lesquelles une méthode agile telle que scrum.

Ils ont d’ailleurs repassé quelques minutes sur la présentation de scrum à partir de ce schéma :

Cycle Scrum

Ils ont également représenté visualstudio.com (anciennement TFService) qui prend en charge des projets de types Scrum ainsi que d’autres briques permettant de s’industrialiser comme un Source Control, gestionnaire de build, du monitoring, et toute une batterie de gestion de tests.

Bref, TFService représente la grosse brique d’ALM.

visualstudio.com

La dernière partie de leurs rappels a portée sur Windows Azure puisque leur démo s’appuyait dessus pour toute la partie serveur.

La mise en place du projet

 Le backlog

Concernant la mise en place du cycle de vie agile, tout commence avec le backlog. Y seront définies les différentes stories, chacune possédant un indice d’effort (le chiffrage de l’équipe de réalisation) et un indice business qui correspond à l’importance de la story coté produit.

BacklogWithEffort

Toutes ces stories vont ensuite être intégrées a des Sprints, des itérations, qui vont correspondre à une répartition en lots. Chaque sprint pouvant se clore par une livraison du produit. Il est intéressant de gérer ses sprints avec leurs dates de début et de fin.

La création des projets

Vient ensuite la partie un peu plus technique de création de l’architecture logicielle, du squelette de l’application.

Cette opération est évidement liée à une tâche et peut donc être suivie dans le backlog scrum.

Les speakers ont alors ouvert Visual studio 2013 et nous ont montrés les différents projets qu’ils utilisaient.

Parmis ceux-ci nous avons pu voir :

–          Les différents projets liés à l’application (web, business et data)

–          Un projet d’architecture (avec le Layer Diagram)

–          Un projet ce documentation (ils ont mentionnés SHFB : Sandcastle Help File Builder)

–          Un projet de base de données

Leur attention s’est particulièrement focalisée sur le layer diagram permettant d’avoir une vision macro de l’application.

D’autres avantages sont que ce diagramme sert de documentation à l’application. Il est également possible de faire ‘valider’ son architecture à chaque build. Cela évitera à un petit malin d’appeler directement la couche data depuis le frontal web par exemple.

Ils nous ont tout de même dit que cette validation pouvait devenir longue pour de gros projets.

Voici un exemple de layer diagram :

LayerDiagram_example

Cette présentation des projets s’est terminée par la mise en place d’un environnement d’intégration continue à l’aide d’un Windows Azure Website.

La réalisation du projet

Après la mise en place du projet vient sa réalisation. Chaque jour qui passe va voir son lot de tâches accomplies, de problèmes, etc. Tout ceci pourra être visible à partir de la fenêtre de sprint, en affichant la board, correspondant numérique de notre mur à post-it J.

BacklogBoard

Présentation de Monaco

Ils nous ont ensuite présenté le projetMonaco. Il s’agit d’un éditeur en ligne proposant IntelliSense.

Cet outil est une solution de fixing rapide puisqu’il permet d’éditer tout fichier sur le serveur visualisé. Ainsi pour leur application de test Asp.Net MVC, seuls les fichiers non compilés sont éditables. Pour un Projet en PHP ou nodejs, tout serait modifiable.

Le raccourcis ultime de monaco est le CTRL+E qui permet de trouver rapidement un fichier ou une classe.

Pour activer Monaco, il suffit de se connecter au backoffice sur le portail Azure, aller dans la configuration du Website et de cocher la case d’activation de Monaco.

Monaco prend également en charge une option de staging, pour permettre à l’éditeur du fichier de tester sa modification avant de vraiment les déployer.

La problématique des builders Azure

Pour continuer, nos speakers nous ont parlé des tests unitaires. Ces tests sont lancés à chaque checking dans le projet.

Pour le moment, TFService étant gratuit pour les projets de moins de 5 contributeurs, la mise en place du projet n’a couté que du temps puisque même le builder rentre dans cette tarification.

Il y a cependant une limite à ce que vous pouvez builder dans les « hosted builders » vis à votre disposition dans visualstudio.com.

Il est notamment interdit :

–          D’avoir un build supérieur à une heure

–          Traitant plus de 75go de données.

–          D’installer des composants tiers sur le builder

–          D’obtenir les droits administrateurs sur cette machine

–          De s’y connecter en remote desktop

–          D’y lancer des tests en mode interactif.

Ces limites font que pour certains projets, un builders fourni par defaut ne suffira pas. Il faudra alors que vous en créiez un et le rattachiez à votre collection de projet visualstudio.com.

La session s’est finie sur cette démo très technique : la mise en place de ce environnement en powershell sur Windows Azure.

Conclusion

Cette session fut pour moi très intéressante. Elle montre que TFS réponds à de nombreux besoins, aussi bien côté pilotage de projet que du côté de leur réalisation.

Il est finalement assez simple, grâce à l’environnement visualstudio.com et à Windows Azure, de bien lancer son projet pour se focaliser sur son code business propre.

Encore un grand merci aux speakers pour la pertinence de leur session.

Nombre de vue : 300

AJOUTER UN COMMENTAIRE