Le Cloud au service de l'intégration continue

Il est bon de commencer par le pourquoi (c.f « start with Why » de Simon Sinek à l'USI 2011). En effet, pourquoi diable pousser le développement dans le Cloud ? Combien de temps me faut-il pour obtenir un environnement prêt à builder jours et nuits ? Combien de temps faut-il entre mon dernier build et la mise à disposition de mon application ? C’est pour répondre à ces problématiques que le passage à un modèle de « Development As A Service » prend tout son sens. Cet article s'inscrit dans la continuité de la réflexion d'OCTO sur ce thème, abordé lors de l’USI 2010 dans "opportunités du Cloud pour la direction des Etudes".

Le serveur d’intégration continue en mode SAAS

Une intégration continue réussie passe par un outillage riche et dont la disponibilité et l’extensibilité se doit être assurée et dont le serveur d’intégration en est le pilier. Une telle offre portée sur le Cloud apporterait un gain significatif pour l’IC en terme de rapidité de mise en place. En plus, selon les besoins on pourrait aisément enlever ou ajouter des instances (par exemple pour exécuter plus de builds en parallèle). Finalement, un tel service permettrait d’avoir une solution clé en main, avec pourquoi pas un écosystème de services, comme un outil de monitoring ou d’analyse de code, prêt à fonctionner d’un simple clic.

Les offres

À première vue, c’est un terrain encore peu exploité mais deux offres émergent pour le monde Java, celle de CloudBees que nous étudierons plus tard et celle d’Atlassian nommée Jira Studio. Cette dernière propose une multitude de services qui sont transversaux pour la D.S.I car agissant du développeur au métier grâce à l’interaction entre bugtracker, suivi de tâche et moteur d’intégration.

À noter également que le monde .Net n’est pas en reste. En effet, Microsoft pourrait bientôt proposer une offre similaire avec Team Fundation Server sur Azure comme le montre un post sur le blog de l’un des membres de l’équipe TFS.

Retour d’expérience sur Cloudbees

L’offre de CloudBees est séparée en deux parties, l’une réservée au développement (DEV@Cloud) et l’autre au déploiement (RUN@cloud). Dans la première, on a accès à des repositories (Maven, Git ou SVN) en lecture et écriture ainsi qu’à un serveur d’intégration (Jenkins), tout projets compilables sur celui-ci est donc accepté. Dans l’autre, on dispose d’une offre P.A.A.S simplifiée avec une base de données (MySQL) et un serveur d’application (Tomcat) qui ne supportera que des projets tournant sur une JVM. Voici un schéma montrant l’architecture des services proposés.

J’ai testé la solution « from scratch » pour compiler, tester et déployer un projet web à travers celui-ci. Il faut moins de 5 minutes, inscription comprise, pour accéder à un Dashboard avec l’ensemble des services « up & ready».

Pour mes tests, j’ai pris le projet open-source PigWeb (une application web de traduction). Après la phase de configuration, je lance mon premier build, celui-ci va être traité par un pool d’exécution et pousser les binaires vers mon référentiel privé.

Maintenant, je souhaite déployer mon application sur le Cloud et ainsi me rapprocher du monde du Continous delivery (c.f la présentation de Jez Humble à l’USI 2011). Simple ! Je créé une instance sur RUN@cloud, j’active et configure le plugin intégré dans Jekins en indiquant simplement une clé et un mot de passe fourni par CloudBees. Enfin, je n’ai plus qu’à cocher et définir les fichiers qui doivent être déployés sur mon serveur d’application. On lance notre build et voilà :).

Finalement, de l’inscription aux tests fonctionnels de mon application il m’a fallu moins d’une heure et tout ceci gratuitement.

Pour aller plus loin…

Quid de l'utilisation de notre UDD à la sauce CloudBees dans un contexte professionnel et/ou sécurisé ?

CloudBees ne propose pas de garantie ou SLA. De plus, comme tout SAAS sur un cloud public les instances sont mutualiséés et donc potentiellement plus vulnérables .

Cependant, l'accès au service nécessite une authentification, et les données sont privées aussi bien pour les référentiels que la base de données. Et pour aller plus loin CloudBees propose aussi des offres Pro, l'une hébergée sur un Cloud Privé (= instances non mutualisées) en phase Beta pour le moment. L'autre, pour ceux qui ne veulent pas laisser sortir les données de leur infrastructure, sous la forme d'un Jenkins enrichi à déployer chez soi.

D’autres services en S.A.A.S peuvent se greffer facilement à la manière de plugins comme du monitoring d’applications avec Web Relic (gratuit) ou encore de l’analyse de code avec Sonar (payant). Enfin, l'offre payante de CloudBees permet bien entendu d’ajouter des instances plus puissantes ou de l’espace disque.

Verdict

Avec des outils tels que CloudBees, la mise en place d’une intégration continue devient un jeu d’enfant en apportant rapidité de mise en place et extensibilité. On peut même pousser un plus loin le développement dans le Cloud en codant directement dans un IDE en mode web comme le très prometteur Exo-Ide intégrant prochainement le support natif de CloudBees (ceci pourrait faire l’objet d’un prochain article). Alors... prêt pour développer dans le Cloud ?

Liens utiles

Java et CloudBees : http://javaadventure.blogspot.com/2011/05/continuously-deploy-your-java-apps-to.html L’intégration Continue : http://continuousdelivery.com/2010/02/continuous-delivery/ Cloud Computing : http://fr.wikipedia.org/wiki/Cloud_computing Grails et CloudBees : https://malderhout.wordpress.com/2011/05/16/continuous-deployment-grails-apps-with-cloudbees-jenkins-github/