Google Appengine : git push to deploy

Google App Engine 2013Avez-vous lu cet article ? le « Git Push to deploy » pour Google App Engine. Je passerais sur PHP et Python pour m’intéresser à Java, l’intéret étant de voir la capacité du service à compiler et packager le projet. J’étais vraiment curieux de voir ce qui était faisable sans la main sur la configuration du serveur de build, ou sans les plugins Jenkins qui vont bien.

Les fonctionnalités

Comme décrit dans l’article, nous allons pouvoir lier très simplement son projet App Engine à un repository Github. Le Hook de notification va parfaitement se mettre en place, et à chaque changement sur la branche Master (ah oui tiens, ce n’est pas personnalisable…), les sources vont être récupérées (accessibles via l’onglet « source »), et un build va être lancé.

Pour que cela fonctionne, le projet devra être un projet Maven standard, le pom.xml à la racine. La suite se déroulera en 3 étapes : Compilation, Tests et Déploiement. Nous avons un feedback à chacune de ces étapes, et tout s’arrêtera au moindre échec.

Au final, un fichier de log est généré, et téléchargeable. Si il y a un problème, ce fichier sera votre seule aide, heureusement, il est exhaustif : c’est la sortie console de Jenkins (oui, un jenkins a l’air d’être utilisé en arrière plan, je suis plein d’espoir pour la suite :-) )

L’interface

Capture git push to deploy

 Elle est claire, très simple et efficace. A chaque Release, une ligne va s’ajouter, affichant le dernier commit, la possibilité d’examiner le git diff pour la release, et une icône de feedback pour les différentes étapes. Je mettrais un petit bémol plus général sur la console d’administration des projets, qui a été refaite en 2013, et qui souffre de certaines lenteurs…

Bilan

J’étais très enthousiaste par la sortie de cette fonctionnalité: tout ce qui peut fluidifier le travail en équipe et faire gagner du temps sur une usine de développement est bon à prendre !
Cependant, la jeunesse du service me fait me demander dans quel cas c’est réellement utilisable… En effet, pas de possibilité de conditionner le déploiement, ou de choisir quelle branche git est la branche principale, par exemple…
Mais le plus handicapant, et de loin, c’est qu’aujourd’hui la plupart des projets Web vont aussi intégrer une usine de développement côté Front, et on aura besoin de Node / Npm / Grunt / Bower… D’ailleurs, nous n’avons accès à aucun de nos chers plugins Jenkins… Bref, dans ces cas là, il faudra se tourner vers des services plus complets comme le service @Dev chez Cloudbees.
Bref, pour démarrer un projet simple, ou en pur backend comme une API, c’est une bonne solution, gratuite et immédiate. Cette fonctionnalité aura le mérite de vous mettre sur de bons rails, votre projet étant standardisé, et les Tests Unitaires étant lancés régulièrement dès le début de votre projet, c’est un moindre mal !

En tout cas c’est un premier pas qui va dans le bon sens et j’espère qu’ils iront le plus loin possible pour deux mots d’ordre : Intégration Continue et Qualité !

LB.

 

Take Off Conférence

Vendredi, à Lille, dans les supers locaux d’Euratechnologies, j’ai pu assister à TakeOff, une conférence qui sort vraiment de l’ordinaire. Orienté aussi bien designers que développeur, je voulais féliciter les organisateurs pour l’éclectisme de leur programmation ! J’ai pu assister à des talks de 30min, dynamiques et originaux…

Je citerais pour cette journée le premier talk de Kathryn Rotondo : « So Easy a Child Could Do It: Designing Apps for Little Fingers ». Une bonne façon de commencer la journée en douceur, Kathryn nous présente toutes les bonnes pratiques pour nous aider à développer une bonne application à destination des enfants : iconographie, cheminement clair, évolution, couleurs, son… C’était vraiment sympa !
D’ailleurs en discutant avec elle, j’ai pu découvrir « Hopscotch: Coding for Kids« , une chouette application (malheureusement uniquement disponible sur l’AppStore), clairement un « Scratch like »…

Côté Google, deux speakers : Francesc Campoy Flores qui nous a présenté un parser Go pour jouer de la musique (qui n’est pas sans rappeler Overtone, le framework Clojure…). Talk dynamique et vraiment sympa !
Martin Görner a quand à lui fait un petit cours d’algorithmie en nous présentant BigQuery. Au delà du côté intéressant de son explication, il nous a encouragés à aller jouer avec les data sets disponibles afin d’appréhender la puissance de l’outil.

Dans les autres talks de la journée, je citerais celui de Jean-Pierre Coene qui nous a présentés de son oeil éclairé les différences culturelles entre les différents pays. Les réseaux ont beaux nous rapprocher, des différences fondamentales dans nos façons de travailler subsistent encore !

Mais surtout, LE talk qui m’a mis une grosse claque, c’est celui de Paul Rouget : « Frontend At The Engineering Level ».  Ingénieur chez Mozilla, Paul nous a fait une démonstration pendant 1h sur l’importance de connaitre le fonctionnement de son navigateur. C’est pour lui la seule façon de franchir un cap, et de faire les bons choix au cours de son développement Web. Bref, le monsieur maîtrise son sujet, présente bien, bref, c’était passionnant !

Si je devais être tatillon, j’aurais bien voulu que les organisateurs soient plus sévères sur les horaires de chaque talk, et peut-être que les petits couacs techniques auraient pu être évités… Mis à part ça, c’est du tout bon ! J’ai passé une excellente journée… Instructive, enrichissante, accompagnée de rencontres sympas et utiles. Avoir ce genre d’événement à Lille est vraiment un plus !

Et cerise sur le gateau, vous pouvez retrouver ces supers présentations sur Youtube ! (Celle de jeudi y sont déjà, pour vendredi je ne doute pas que ça ne va pas tarder…)

L.B.

Dart Flight School à Lille

Dart Black

 

L’un de mes premiers objectifs de l’année était de me lancer dans la vie associative à Lille. L’occasion s’est très vite présentée : avec la sortie de Dart en version 1.0 (et maintenant 1.1), Google a décidé d’organiser partout dans le monde ce qu’ils ont appelé des DART FLIGHT SCHOOL ! 

Le principe ? Google nous fournit des ressources, codelab, tutoriaux, entre autre par l’intermédiaire de Seth Ladd, Dev Rel autour du langage, et nous soutient logistiquement parlant, bref, ils investissent énormément pour la promotion de Dart.

J’ai profité de tout ça pour créer le Google Developer Group Lille par l’intermédiaire d’un groupe meetup. Meetup a quand même cet avantage de fédérer assez facilement une communauté, en tout cas sur Paris ça fonctionne très bien !
Je suis donc à la recherche de speakers autour des technologies Google, que ça soit pour du front (AngularJS, Dart, GWT (?)…) ou du back (Google AppEngine, ComputeEngine, Cloud Storage…). N’hésitez pas si vous voulez vous lancer !

Lille a l’air de profiter d’une communauté de développeurs assez active et j’ai pu déjà rencontrer quelques groupes très sympas, dont le Chti’Jug, le Chti’JS, l’espace de coworking du Mutualab, ou encore les gens de TakeOff. Mais j’imagine qu’il reste encore un peu de place pour quelques motivés !

Dart

Dart sera donc le premier sujet abordé. Je ne connais que très peu le sujet, et j’ai hâte de voir ce que ça peut vraiment donner. Un vrai langage côté browser, sur le papier ça me plait. Mais en vrai nous savons très bien que la VM Dart ne sera jamais intégrée à IE ou Firefox, alors pourquoi Dart ? Avec ma vision lointaine, je vois en positif que le langage a été conçu pour le Web. Le data-binding, une syntaxe moderne, Javascript a trop de faiblesses que Dart comble. Qui plus est, Google n’investirait pas autant d’énergie si ils n’y croyaient pas !
Mais à côté de ça, j’ai bien peur que Dart ait toujours besoin d’être compilé en Javascript, et l’idée ne me plait pas du tout. Qui plus est l’écosystème Javascript est en train d’exploser que ça soit dans les frameworks ou l’outillage ! TU et intégration continue ne sont plus des gros mots pour le front…

Pour vraiment juger il faut essayer, alors, le 13 février, venez essayer avec moi ! 

Bilan 2013 et Objectif 2014… Qu’ai-je appris cette année ?

Nous sommes en 2014, et j’aime bien faire un petit bilan professionnel de l’année passée. Qu’ai-je appris ? Aurais-pu faire plus ? Me suis-je amusé ?

Du Classic

J’ai commencé 2013 par ce qu’on appelle communément « un grand compte », avec  un projet Titanesque. Je ne rentrerai pas dans les détails, mais sur le contenu, j’ai eu droit à de l’Oracle / Hibernate, Spring, des pages et des pages de formulaire, le tout porté par un bon gros Liferay. Et tout ça était relié à plein d’autres applications du même genre, à travers des Web Services SOAP. résultat22693-le-plat-de-spaghettis   De la frustration, mais des technos solides qu’il est bon de maitriser, dans une ambiance positive avec quelques personnes avec qui j’ai pris plaisir à travailler.

De la Mobilité

Changement de registre. Un client arrive, avec un besoin un peu flou, et peu d’argent (en gros un mois de développement). « Je veux un site web, une application mobile, Android, iOs, stocker des photos, scanner des choses, gérer des données de référence, des droits d’accès, etc… Carte blanche sur la techno employée ». Ah. En 20 jours, donc… Et bien cela m’a permis de bien m’amuser :-). Et une mission comme celle-là, c’est une formation accélérée pour n’importe qui ! L’objectif étant d’avoir très rapidement une usine de développement, une application web et une API pour communiquer avec mes applications mobiles, j’ai choisi des technos que je savais adaptées, sans obstacle pour moi. Bref, à la fin de la première matinée, j’avais mon application sur Github, le hook Cloudbees / Jenkins qui va bien avec mon déploiement sur Google AppEngine. Une dépendance Maven vers Jersey, et j’aurais mon API sans soucis au fur et à mesure de mon développement. L’API, un jeu d’enfant. Un coup de Twitter Bootstrap et AngularJS pour le front, et ça irait tout seul. Mais même avec la meilleure volonté du monde, comment produire ces deux applications mobiles dans le temps imparti ? Nous sommes partis sur la solution Apache Cordova, couplé à JQuery Mobile pour le thème et éviter de se poser des questions. Pour des raisons fonctionnelles, nous avons aussi utilisé AngularJS côté mobile, ce qui devait nous simplifier la vie, et ce choix a été payant. Heureusement que nous n’avions pas Windows Phone en cible, la stack choisie n’aurait pas fonctionné. Bref, je me suis éclaté ! On apprend à coder vite, à s’appuyer sur des choses fiables, à s’adapter très très vite quand on rencontre un problème (aaaahhh les plugins Cordova… *soupir*), et on écarquille les yeux quand on se rend compte à quel point on peut produire vite, sans contrainte.

Mes coups de coeur :

cordova            appengine

(Oui, Cordova est quand même très chouette, malgré si l’on entend que c’est l’application mobile du pauvre…)
(Et oui, on y a passé un chouilla plus de temps que prévu ;-) )

Du WEB

On enchaîne avec une mission pure WEB… Environnement Google AppEngine, un besoin simple, mais on passera un peu plus de temps sur le design. AngularJS est alors incontournable, j’essaye de m’y intéresser plus, de penser aux directives, aux bonnes pratiques… Autant la courbe d’apprentissage est très rapide pour les besoins primaires, autant je trouve que ça se complique aussi très vite dès que l’on pense « composant ».
Mais clairement, ça aurait été difficile de passer l’année 2013 sans y toucher.angularjs

De l’Intégration

Oui, des EIP : Enterprise Integration Patterns. Je ne pensais pas compléter ma panoplie de développeurs par ce domaine, mais certaines opportunités m’y ont amené, sans que je ne le regrette le moins du monde !
L’intégration de données peut paraître moins sexy. Pourtant, en quelques mois j’ai croisé de vraies problématiques importantes, formatrices ! On pensera fiabilité, performance… On s’adapte aux contraintes systèmes, on se devra d’être flexible, on découvre de nouveaux patterns, et on pensera un peu différemment.

Mon nouvel ami : apache-camel-logo

De l’Associatif

En 2013, j’ai encore rencontré plein de gens vraiment passionnants et passionnés. J’ai assisté à des JUGs, à des meetup, j’ai assisté à Devoxx France, et j’ai même eu la chance d’être speaker au Jug Summer Camp.
Grâce à l’équipe du Google Developer Group Paris, j’ai aussi pu m’impliquer un peu plus dans l’organisation de plusieurs soirées, pour des technos et une communauté que j’apprécie.
Je ne suis resté qu’à peine deux ans à Paris, mais je pense ne pas avoir perdu mon temps sur place… Merci à toutes les personnes qui m’ont appris autant, c’était vraiment, vraiment bien.

Et maintenant ?

Et 2014, c’est Lille ! Je sens qu’ici aussi il y a des choses à faire. Un Chti Jug est actif, un ChtiJS aussi, et j’ai moi-même quelques ambitions.

Autour des technos Google, il y aura toujours des choses à faire, et des gens à rencontrer ! J’en ai profité pour créer deux choses :
- le Meetup GDG Lille : www.meetup.com/GDG-Lille/
- Le Twitter qui va avec : https://twitter.com/GDGLille/
Les premières soirées vont arriver courant février ! N’hésitez pas à me contacter si vous avez des envies ou des besoins.

J’ai aussi une liste de technos auxquels j’ai envie de m’intéresser de plus prêt :
- Docker
- Dart
- Java 8
- suivre encore et toujours le monde Javascript, en pleine effervescence…

Et vous, avez-vous ciblé vos technos de 2014 ?

[CloudBees] Déployer sur Google App Engine avec le même numéro de version que dans le Pom.xml Maven

cloudbees-logo

Connaissez-vous CloudBees ? C’est un outil super (Une de ses fonctionnalités, les ClickStart, présentée ICI), qui est dans la mouvance des PaaS, et qui a la particularité de proposer un service qu’ils appellent « Dev@Cloud ». Concrètement qu’est ce que c’est ? Un repository Git privé, un Jenkins rien que pour nous, qui nous permet de builder, ou de déployer nos projets Java ou NodeJS sur leur partie « Run@Cloud » (concrètement des instances Amazon). Bref, CloudBees fournit une usine de développement pour de l’intégration continue. (Nous pouvons bien entendu brancher notre Jenkins vers n’importe quel repository git, genre Github).

Depuis quelques temps, CloudBees permet de déployer aussi sur Google App Engine, et c’est à cette fonctionnalité que nous allons nous intéresser.

Une fois que nous nous sommes authentifiés à travers https://appengine.cloudbees.com/index.html, il suffit de suivre le workflow pour déployer son application immédiatement.

Configuration Jenkins

Allons voir ce qui se passe, et comment Jenkins déploie sur Google App Engine.
Un plugin est là, en post-build, pour faire le boulot.

jenkins-appengine

Le Besoin

Nous voyons que nous pouvons surcharger le numéro de version de l’application. Par défaut dans la configuration CloudBees, le numero de version est surchargé par le numéro de build. C’est à dire qu’à chaque fois que l’on build son application, une nouvelle version est déployée sur Google App Engine. Bon, pourquoi pas…

Mais nous avons un POM.xml qui contient déjà un numéro de version du projet. Comment l’utiliser ?

Solution

Première étape : enlevons la surcharge faite par Jenkins (cf capture d’écran). Dans ce cas-là, c’est le numéro de version contenu dans le fichier appengine-web.xml qui sera utilisé.

<application>monapplication</application>
    <version>${appengine.app.version}</version>
    <threadsafe>true</threadsafe>
</appengine-web-app>

Au moment du build Maven, nous remplissons automatiquement la variable appengine.app.version avec le numéro de version du projet. Pour ce faire, dans le POM.xml, nous définissons simplement:

<properties>
    <appengine.app.version>${project.version}</appengine.app.version>
    <appengine.target.version>1.8.1</appengine.target.version>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
 </properties>

Dans l’idée, ça devrait fonctionner.

Problème : Google App Engine n’accepte ni les majuscules, ni les « point » dans ses numéros de version. Autant dire que 1.0.0-SNAPSHOT ne colle pas trop à la spécification :-)
https://developers.google.com/appengine/docs/java/config/appconfig?hl=fr )

Solution : Utilisation du plugin maven gmaven-pugin, dans la phase « Initialize », pour changer un peu le numéro de version afin qu’il soit accepté par Google App Engine.

<plugin>
    <groupId>org.codehaus.gmaven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <version>1.5</version>
    <executions>
        <execution>
            <!--<id>properties</id>-->
            <phase>initialize</phase>
            <goals>
                <goal>execute</goal>
            </goals>
            <configuration>
                <source>
                    <!-- version pattern : 1.0.2-snapshot -->
                    project.properties["appengine.app.version"] = project.version.replace(".","-").toLowerCase()
                </source>
            </configuration>
        </execution>
    </executions>
 </plugin>

On remplace les point par des tirets, le tout en minuscule et nous voilà App Engine Compliant.

Conclusion

Maven est tout à fait capable de gérer différents profils, des configurations, et il est de notre intéret de garder cette logique pour gérer son versioning. Un petit plugin muni d’un script Groovy pourra nous aider à passer quelques obstacles simplement.

LB.