Comme le mouvement Agile a rapproché donneurs d’ordre et équipes de réalisation autour d’une vision commune orientée « produit », le mouvement DevOps rapproche aujourd’hui les équipes de développement (DEV) et d’exploitation (OPS) autour d’une vision commune orientée « service », afin de mieux concilier réactivité et qualité de service.

DevOps aborde le paradoxe entre des équipes projets qui cherchent à livrer toujours plus fréquemment des nouvelles fonctionnalités d’une part et d’autre part des équipes d’exploitation qui cherchent à stabiliser et fiabiliser les systèmes tout en maitrisant leur coût.

On peut décrire DevOps selon trois axes :

• Aligner l’exploitation sur les enjeux métiers comme l’agilité a déjà aligné le développement sur le métier.
• Aligner le développement sur les réalités de l’exploitation pour rendre possible la mise en production, la disponibilité et la fiabilité des fonctionnalités métier.
• La transformation du métier d’OPS pour gérer des topologies chaque jour plus grosses et plus complexes avec l’adoption d’infrastructure as code et d’outils comme Chef ou Puppet. Les nouveaux OPS sont des programmeurs ! Ils débattent à la machine à café de TDD, de Ruby vs. DSL, de choix d’IDE, de Git vs. SVN, …

DevOps est souvent associé à la mise en place d’un processus de Continuous Delivery qui, dans la mouvance Lean, vise à déployer les fonctionnalités en production au plus vite et de maximiser les feedbacks. Nous reviendrons dans un autre billet sur les processus de Continuous Delivery.

La mise en place d’une culture DevOps touche les humains, les processus et les outils. Nous proposons une démarche englobant ces trois aspects en prenant comme point d’entrée les processus et, de proche en proche, faire évoluer les humains et les outils.

Lire la suite de cet article »

Répondant à la demande, le 31 janvier nous rééditerons la soirée des 13 et 20 octobre derniers !

La saison est au Continuous Delivery ! Venez découvrir comment automatiser le déploiement d’une application java web typique sur des serveurs Tomcat via une usine GitHub/Jenkins/Nexus.

Nous verrons plusieurs techniques de déploiement, de la plus simple à la plus sophistiquée :

1. déploiement sur Tomcat avec des commandes shell lancées par Jenkins au lieu de les lancer à la main ;
2. utilisation du tomcat-maven-plugin avec les conseils d’Olivier Lamy, lead developer du plugin et committer Tomcat ;
3. homogénéisation des déploiements du dev à la prod avec Jenkins associé à Rundeck pour gérer des commandes shell. Vincent Behar, committer Jenkins et ‘owner’ du jenkins-rundeck-plugin nous présentera cet outil Open Source en vogue chez les OPS ;
4. DeployIt : l’outil intégré d’automatisation des déploiements made in Xebia.

Pour avoir plus de détails sur le déroulement de l’atelier et pour vous inscrire, nous vous invitons à utiliser la page dédiée sur Eventbrite.

Pour déployer une application sur un serveur Tomcat distant, nous avons vu précédemment comment utiliser Apache Tomcat Maven Plugin. Nous pouvons aussi utiliser un script. Cette solution plus élaborée est certainement plus proche des solutions d’exploitation existantes aujourd’hui dans nos entreprises. 

Dans l’esprit DevOps, il faut avoir un mode de déploiement le plus tôt possible identique à celui de la production. L’approche par script convient ainsi à un maximum d’environnements possibles (du test jusqu’à la production).
Pour ce faire, le script sera placé sur le serveur distant et exécuté à distance.

Le but de cet article est de vous proposer une solution pour déployer une application web sur un serveur Tomcat distant à chaque commit sur votre repository. Pour cela, nous allons utiliser le plugin Remote SSH pour Jenkins.

Lire la suite de cet article »

Les 13 et 20 octobre derniers a eu lieu le deuxième Tech Event Xebia avec, cette fois, comme sujet le Déploiement Continu sur Tomcat avec Jenkins, Rundeck et Deployit. Pour l’occasion nous avons eu la collaboration spéciale de deux guest stars :

• Olivier Lamy, architecte chez Talend, membre de la fondation Apache et committer sur Tomcat et sur Jenkins
• Vincent Behar, ingénieur Java à Exalead, owner du plugin Rundeck pour Jenkins et cofondateur de Paris Devops, 

Merci à eux pour leur participation à la préparation de l’atelier ainsi qu’à sa présentation.

Flickr est l’exemple le plus évoqué à l’heure actuelle de déploiement continu. Il existe bien d’autres exemples connus comme Outbrain, Wealthfront ou Etsy. Même si le nombre d’entreprises qui arrivent à ce niveau de maturité est encore faible, il est possible qu’à l’avenir cette méthode devienne une technique courante dans les projets avec la progression de l’agilité. Son implémentation oblige, en effet, à accomplir quelques principes du manifeste agile, dont par exemple :

Ainsi qu’à en pousser d’autres :

Lire la suite de cet article »

Le quatrième Paris DevOps Meetup aura lieu mercredi 4 Mai à partir de 19h00 dans les locaux de Xebia.

Au programme :

• Un retour d’expérience sur un gros projet agile distribué (100 personnes, 10 équipes, 4 pays) orienté culture DevOps, process… et (un peu outils).
• Monitoring dans un cadre DevOps : infrastructure, services, business, trend monitoring, alert monitoring, dashboards, wallboards, etc.

Les inscriptions se font sur lanyrd comme d’habitude : http://lanyrd.com/2011/paris-devops-meetup-4/

Notez bien l’adresse :
Xebia
156 boulevard Haussmann à Paris
Immeuble A – 7e étage

De nombreuses sociétés font aujourd’hui confiance aux technologies Java EE pour leurs applications critiques d’entreprise, leurs sites web et / ou leur intranet. Pourtant, nombre d’entre elles se retrouvent aujourd’hui confrontées à un obstacle de taille : comment déployer plus rapidement et de manière plus industrielle des applications toujours complexes, livrées de plus en plus fréquemment sur des socles middlewares différents et/ou sur des environnements de plus en plus nombreux ?

Les tâches de déploiement et de configuration des applications deviennent ainsi bien souvent un goulet d’étranglement quand elles ne sont pas un frein à l’activité.
Deployit, de la société XebiaLabs, a été conçu en collaboration avec KLM/Air France pour adresser cette problématique. Il est aujourd’hui mis en oeuvre avec succès par de nombreuses sociétés dans des secteurs très variés.

Les bénéfices de Deployit

• Réduire jusqu’à 95% des erreurs de déploiement et jusqu’à 50% de vos coûts de déploiement classique
• Réduire les temps d’attente des équipes via des déploiements en self-service et continus
• Standardiser les procédures de déploiement entre différents environnements
• Fluidifier les relations entre départements études, intégration/recette et production
• Augmenter contrôle et visibilité sur votre processus de déploiement applicatif
• Accélérer votre time-to-market

Programme du séminaire : le 29 avril de 9h45 à 11h45, 156 bd Haussmann 75008 Paris

• 9h45 : accueil
• 10h : présentation des enjeux du déploiement applicatif et de la solution Deployit
• 10h30 : démonstration produit
• 11h : retour d’expérience client Karavel/Promovacances

Public cible : Directeur Informatique, Responsable des Développements / Etudes, Responsable Intégration / QA / Tests, Responsable Production / Exploitation, Responsable Qualité, Architecte, Chef de projet

Inscription: http://www.xebialabs.com/seminaire-deploiement-automatique

Cyrille Le Clerc et Pablo Lopez ont le plaisir de vous inviter Jeudi 14 Avril à 19h00 pour une « Soirée Monitoring d’Applications Java avec le Fondateur et CTO d’AppDynamics » .

Nous avons profité du passage en Europe de Jyoti Bansal pour organiser avec les équipes d’AppDynamics un événement autour du monitoring de la « vraie vie » .

A l’heure où l’architecture des applications d’entreprise devient de plus en plus complexe et distribuée, l’outillage dans le domaine du monitoring et du troubleshooting est un élément clé du système d’information. Notre objectif est que chacun en retire des idées immédiatement applicables et se forge une vision des problématiques que les systèmes de monitoring gèrent aujourd’hui et traiteront demain.

Après avoir consulté des Dev et des Ops des secteurs Telcos, Finance, Retail et Voyage, nous avons établi un programme reprenant des cas de notre vie quotidienne illustrés dans une application transactionnelle de eCommerce « réaliste » (1) que nous avons déployée en cluster sur 5 serveurs Amazon EC2., que nous soumettrons à diverses déconvenues courantes.

Lire la suite de cet article »

Depuis le traditionnel outil make, introduit en 1977 pour livrer en production un logiciel, plusieurs étapes, de la construction du logiciel au processus de livraison, ont été automatisées. En réalité, être professionnel lorsqu’on parle de développer des logiciels, c’est, a minima, savoir automatiser la compilation et les tests en intégration continue. Mais un autre sujet progresse aussi dans le domaine de la gestion du cycle de vie des applications (Application Lifecycle Management – ALM), il s’agit de l’automatisation des déploiements. Cette progression est en partie due à nos environnements (serveurs d’application, ESB, EAI, etc.) qui sont de plus en plus complexes et étendus. Le nombre croissant de nouvelles versions d’une application, demandées par le business moderne, et le fait que le déploiement doit être suffisamment fiable pour ne pas risquer d’interrompre un service en ligne sont deux raisons supplémentaires qui poussent à s’intéresser à cette question. Ajoutez à cela que les infrastructures en cloud gagnent un peu plus de terrain chaque jour, et vous conviendrez que l’on a encore un long chemin, à la fois motivant et intéressant, à parcourir.

Lire la suite de cet article »

Dans un précédent article sur le déploiement, j’ai présenté l’ensemble des tâches à mettre en œuvre pour déployer une application Java dans un environnement d’entreprise. Le scénario décrivait étape après étape la configuration de chaque composant comme les serveurs web, les pare-feux, la base de données et les ressources externes JEE. Le point clé à retenir était que ces différentes configurations de composants avaient autant d’importance dans un déploiement que l’installation d’un fichier EAR ou WAR.

Mais voilà, comme on l’avait rapidement suggéré précédemment, il existe un scénario légèrement plus compliqué que celui décrit ci-dessus ; il s’agit du cas de mise à jour d’une application vers une nouvelle version. Bien que le déploiement initial d’une application soit forcément important, un certain nombre de raisons me fait penser que le déploiement d’une nouvelle version l’est encore plus.

Lire la suite de cet article »

Après avoir abordé la gestion des fichiers de logs, nous continuons aujourd’hui la série « Applications Java prêtes pour la Production » avec l’audit.

Par audit, nous entendons l’audit des actions importantes réalisées sur une application.

Pourquoi auditer ?

Est-il vraiment utile de générer des informations d’audit dans nos applications ? Sans explications de juriste, quelques exemples suffiront à nous en convaincre :

• Un site web de partage de photos doit pouvoir dire qui a uploadé quelle image, depuis quelle adresse IP et à quelle date.
• L’application d’administration d’un site de e-commerce doit tracer toutes les modifications de prix pour empêcher un employé astucieux de baisser à 1 euro le prix de son téléphone préféré le temps de passer commande.

Pour revenir à des explications plus théoriques, les logs d’audit nous apportent :

• les informations nécessaires à la justice en cas d’infraction,
• la détection d’intrusions,
• la reconstitution des événements en complément des logs d’exceptions pour aider au diagnostique de problèmes.

Nous nous placerons dans le cas le plus fréquent où nous ne développons pas d’outil pour consulter ces informations d’audit et où un accès direct au média de stockage (grep sur fichier texte, sql sur base de données, etc) suffit.

Lire la suite de cet article »