Jenkins dans les nuages

Une abeille m'a dit récemment qu'il était possible d'avoir un serveur d'intégration continue et de déployer son application sur le cloud en 2 minutes.
Challenge Accepted !
Voici donc les étapes qu'il m'a fallu pour arriver à ce résultat :


1 - Création du compte
Une fois sur le site de CloudBees, 2 chemin possibles : Soit par "Pricing", Soit directement "Sign Up".
Passé le formulaire d'enregistrement, on est invité à souscrire aux offres que l'on souhaite.


2 - Souscriptions
A ce moment, c'est un peu les soldes, on dispose d'un large choix :

• le DEV@Cloud avec un serveur Jenkins et le quota de build de 300 minutes par mois
• le RUN@Cloud avec 5 applications que l'on peut déployer sans toutefois la sécurité ni la scalabilité
• une base de données MySQL à hauteur de 5 MB
• en parlant de soldes, le partenariat avec SauceLabs donne une offre gratuite jusqu'au 20 Septembre avec des quotas qui permettent de se faire une bonne idée du service je pense (16 000 minutes / mois et 48 tests simultanés)
• pour le coup, le Sonar est payant (snif !)
• le repository d'artefact fourni par JFrog est payant aussi
• une offre New Relic gratuite qui offre un monitoring global des applications
• enfin une offre Cloudant pour une base de données distribuée As a Service basée sur Apache CouchDB

Une phase de validation à la Google avec un serveur vocal qui nous donne un code. Le message est en français s'il vous plait !


3 - Configuration
Fin du shopping, voyons voir ce qu'on peut faire. Sans surprise, on accède à une instance de Jenkins, une liste déjà conséquente de plugins est disponible en mise à jour.
Création du projet, configuration des sources, type de build, on n'est pas perdu.
A noter que CloudBees propose avec son offre un repository Git, mais il est tout à fait possible de connecter le Jenkins à son compte GitHub.
Pour ce faire, ne faites pas comme moi, pensez à ajouter la clé fournie par le Job Jenkins dans votre compte GitHub pour qu'il aille récupérer les sources. (RTFM...)


4 - Build
Lancez votre premier build, et pour les essais que j'ai fait avec des projets Maven, je n'ai pas eu de soucis de ce coté là. Si vous l'avez configuré, vous recevez les rapports de build sur votre boite mail, et c'est fini.


5 - Deploy
Le déploiement sur son instance RUN@Cloud est assez simple, on crée une application via son compte et il suffit d'installer le plugin CloudBees deploy dans le Jenkins. Pour la configuration, on est tenu par la main en nous proposant les noms disponibles.
On relance le build et quelques minutes plus tard, on peut commencer à faire joujou avec son application.


PS : ne mettez pas d'accent dans le Name pour la configuration du plugin de déploiement, il n'aime pas du tout.


6 - Mais mon application, comment je la configure pour la base de données ?
Très simple là encore, plusieurs solutions sont proposées via l'instance, il suffit de copier-coller le code proposé dans les bons fichiers et on y est.
cela correspond à un adressage JNDI, donc rien d'exotique, cela marche très bien qu'on soit en Spring ou JavaEE. Le seul fichier spécifique n'a pas d'effet de bord sur les conteneurs habituels. Ah oui et la base de données est sauvegardable en un clic !


Conclusion
L'abeille avait raison ! Tout ça reste du grand classique mais qui a le mérite d'être simple et il ne m'a fallu une bonne vingtaine de minutes pour monter un serveur Jenkins, un repository Git, une base MySQL et un Tomcat, 10 minutes de plus et j'ai mon premier build et l'application déployée et accessible. Sans aucune administration matérielle à assurer...


Certes, un compte gratuit ne permettra pas d'utiliser la plateforme pour un véritable projet de développement d'entreprise, mais il est largement suffisant pour se faire une idée de la plus value de la solution. D'ailleurs, même le compte gratuit, j'y vois un intérêt pour des formations, présentations, démos ou ateliers.


En ce qui concerne le service sur le cloud, par rapport à un AppEngine par exemple, c'est sans doute une question de goût. Pour me part, je suis plus séduit par la possibilité d'avoir une base de données MySQL sur laquelle mon code JPA pourra fonctionner complètement sans avoir un guide de développement décrivant les fonctionnalités possibles ou non. Même si je reconnais que la base de Google BigTable doit sans aucun doute mieux monter en charge, je n'en ai pas forcément besoin. Par contre, je suis certain d'avoir besoin d'un serveur d'intégration continue qui peut déployer une application à la demande ou en continu. Donc, la plus value du Jenkins remporte pour moi tous les suffrages.