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/

6 commentaires pour “Le Cloud au service de l’intégration continue”

  1. Hello,

    Merci pour le post détaillé. Quelques infos additionnelles qui ne sont pas forcément connues ou claires pour tous:
    – avec les offres payantes, nous offrons bien évidemment différents SLAs, ils sont indiqués sur la page de pricing
    – nous avons un certain nombre de clients qui utilisent leur propre compte Amazon, i.e. des machines dédiées, ceci ne pose pas de problème. LoseIt! par exemple, dans ce modèle, génère 15’000 transactions par minute et dispose de plus d’un million de clients.

    A mentionner également, la possibilité pour les projets Open Source de bénéficier d’une offre gratuite étendue: http://www.cloudbees.com/foss/index.cb

    Meilleures salutations,

    Sacha

    CEO
    CloudBees, Inc.

  2. Merci Sacha pour toutes ces précisions.
    Il existe en effet des engagements en terme de rapidité de support en fonction de la criticité de l’incident. Mais nous n’avons pas trouvé de mécanisme de « Crédits de Services » tel qu’Amazon en propose pour EC2 lorsque le niveau de disponibilité passe en dessous des 99.95%. Est-ce quelque chose de similaire est inclus ou envisagé dans l’offre pro ?

  3. Philippe,

    Non, en effet, nous ne proposons en standard pas de mécanisme de crédit pour l’heure.

    Meilleures salutations,

    sacha

  4. [...] Le Cloud au service de l’intégration continue By Vincent Canuel & Philippe Guicheney, 2 August 2011 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 ? [...]

  5. [...] de notre UDD sur le Cloud est loin d’être trivial et reproductible , même si des usines  dans le Cloud [...]

  6. [...] Cloud deployment of all parts of the complete software factory is far from easy and reproducible, even if cloud software factories exist (see this article . [...]

Laissez un commentaire