Rendez vous au Devoxx France 2013

Si vous êtes un peu geek (ça doit être le cas, car vous êtes sur notre blog :)) et si vous surfez sur le web pendant votre temps de travail (?? :) ), vous savez certainement que le Devoxx France aura lieu le 27 mars prochain. Et comme pour la 1ère édition, FastConnect fait de nouveau parti des sponsors de cet événement.

Et une fois de plus, nos consultants se plient en 4 (ou en 2 .. ça dépend de l’agilité de chacun :)) pour vous préparer une petite surprise ici.

Donc rendez vous sur notre stand ou sur cette page à partir du 27 mars.

On vous attend ! Comment ? Vous n’y allez pas ? Oh .. vous allez nous manquer :(…. Mais rassurez-vous, vous pouvez toujours venir nous voir sur notre stand au BreizhCamp 2013, une conférence chez les bretons pour les bretons et les non bretons dont FastConnect est également sponsor.

A bientôt…

Les 5 mercenaires du Devops au Devoxx France

Du 18 au 20 avril 2012 s’est tenu la première édition du Devoxx France. A cette occasion, j’ai eu la chance de découvrir le mouvement Devops grâce à la présentation de ses 5 mercenaires que sont :

Devops est une contraction de Développeur et Opérationnel. Ce mouvement tente de réconcilier les développeurs et les opérationnels.

Malgré l’arrivé des méthodologies Agiles dans la plupart des structures, le monde des développeurs et des opérationnels reste scindé en deux. D’un coté, nous avons les développeurs qui fournissent aux opérationnels un « livrables », pendant que les opérationnels tentent de déployer le dit livrable.
Très souvent, la définition du livrable n’est pas la même que l’on se trouve du point de vue du développeur ou de l’opérationnel.
L’une des recommandations du DevOps est de définir un livrable compréhensibles par les deux parties.
Pendant la présentation, les 5 mercenaires nous montrent une forme de livrable depuis un Jenkins. Les livrables sont des packages natifs, des RPMs en l’occurrence.
Cette forme de livrable  :
  • est auto-suffisante
  • peut être facilement déployé
  • peut être rollbacké
  • est archivable
  • est configurable

Dans leur exemple, ils proposent de livrer des RPMs contenant le conteneur Tomcat ainsi que le War de l’application. Cela permet aux développeurs de maintenir une configuration du conteneur répondant aux besoins de leur application.

Une partie du déploiement de l’application peut être configurable et/ou laissée à la main des opérationnels afin de configurer les éléments dédiés aux environnements de production (mot de passe de la base de données, etc…).
Les RPMs peuvent être construits par Jenkins et mis à disposition des opérationnels sur un dépôt Maven.
Les opérationnels peuvent alors aller chercher une version spécifique du livrable pour le déployer, voir même utiliser Jenkins; ou tout autre outil de Build continu.
En allant même un peu plus loin, il est possible de configurer le Jenkins afin de déployer régulièrement l’application. Nous parlons alors de déploiement continu.
Cette approche permet
  • une meilleur entente entre les opérationnels et les développeurs
  • d’améliorer la qualité du livrable
  • d’augmenter la satisfaction des utilisateurs

Cependant, la mise en place de cette recette miracle peut rencontrer quelques difficultés :

  • Une résistance forte du au choc culturel. Toutes les structures ne sont pas prête à accepter une étroite collaboration entre les opérationnels et les développeurs.
  • Généralement, il est fortement recommandé d’avoir une application qui pratique déjà l’intégration continu. Oui, ça peut peut-être faire sourire, mais les applications qui pratiquent l’intégration continue ne sont pas aussi courantes.