Dépoussierez votre construction d’appli avec GRADLE

Les acteurs en place


GRADLE


Gradle est un moteur de production basé sur le langage Groovy fonctionnant sur une plateforme JAVA. Il permet d’automatiser les build, les tests, les publications, les déploiements, etc. pour une multitude de langages.

Apache Maven


Aujourd’hui Maven est utilisé par la majorité des développeurs pour automatiser le build et le deploy des applications.
Il se base sur un concept « Convention over configuration » qui impose le respect d’un certain nombre de règles :

  • Définition des règles de construction via des fichiers XML, les POM,
  • Nommage et structuration de répertoires projet (src/main/Java, src/main/resources, src/main/webapp, etc.).

A ce concept Maven accole un cycle de vie très stable basé sur des gaols prédéfinis (compile, test, package, install, deploy, etc.).
Les principaux reproches faits à Maven sont que

  • Maven est Monolithique, il laisse très peu de place pour les spécificités et la customisation,
  • Maven repose sur de la configuration XML qui devient rapidement peu lisible,
  • Maven propose un fichier de build par artefact,
  • Maven ne permet de Build d’un seul langage,
  • La résolution des problèmes de dépendances est difficile et fastidieuse.

Gradle avance ses atouts


Gradle reprend et agrège les points forts d’ANT, Maven, Ivy et Groove, apportant flexibilité et souplesse.
Il reprend les idées et concepts suivants :

  • Le concept « Convention over configuration » de maven
  • Le cycle de vie de Maven
  • La notion de repositorie de Maven
  • Le moteur de dépendances de Maven et Ivy
  • Le Scripting de ANT
  • Le langage de programmation de Groovy

Gradle repose sur un mécanisme de cycle de vie qui s’appuie sur un système de tâches. Ce cycle de vie est basé sur l’enchainement d’un certain nombre de tâches prédéfinies et customisable. Ce cycle de vie peut lui aussi être customisé via des taches personnalisées et dynamiques.
Définition d’une tache

task myCopy(type: Copy) {
    from 'resources'
    into 'target'
    include('**/*.txt', '**/*.xml', '**/*.properties')
 }

Cette liberté de création et modification de tâches offre à Gradle la décorrélation du build et du deploy ainsi que la gestion de plusieurs artéfacts au sien d’un même fichier build Groovy.

La définition des tâches et donc des règles de construction se fait à travers des fichiers écrit en Groovy. Un fichier de build Gradle (build.gradle) pour un projet Java tient en une ligne :

apply plugin:'java'

Gradle permet aussi une certaine souplesse dans la définition des repositories (adresse repository officiel, adresse repository local, adresse proxy, adresse serveur de partage, etc.) ainsi que dans la résolution des dépendances (remplacement de versions manuel, remplacement de dépendance manuel, etc.)
Définition de dépendance

dependencies {
    compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
    testCompile group: 'junit', name: 'junit', version: '4.+'
}

Définition de repositories

repositories {
     mavenCentral()
 }

Un point fort supplémentaire de Gradle est sa notion de build incrémental qui lui permet, grâce à la définition de point d’entrées et de sorties lors de la construction des livrables, de déterminer si le build est UP-TO-DATE ou non.
La commande d’init d’un projet est :

gradle init

Enfin, pour simplifier la notion de version au sien de projet, Gradle, lors de l’initialisation du projet, génére un wrapper dédié au projet qui contient l’ensemble des informations de versions y compris la version de Gradle lui-même. Ainsi, le build du projet est portable sur n’importe quel environnement. Le wrapper contient la version de Gradle et un lien permettant de télécharger cette version. Ce lien étant paramétrable à souhait.

Par François Nassoy, Chef de Projet



Retour DevoxxFr #2: Adoptez-les stratégies gagnantes de Atlassian

Damien Ridereau, Senior Developper chez Infotel, présente les grands principes qui permettent de faciliter l’innovation dans les projets logiciels d’envergue.

Atlassian ou le développement logiciel Kick-Ass


Comme le souligne Tariq Krim dans son rapport à Fleur Pellerin, le logiciel vit actuellement sa révolution. Le développement passe de l’artisanat à l’ère industrielle. Les démarches de développement empiriques s’affinent et évoluent pour laisser place à des processus et méthodologies d’automatisation.

Cette transformation n’a cependant pas encore atteint la maturité et est toujours en phase d’évolution. Il est en effet fréquent de voir des projets fonctionnant de manière erratique et ne satisfont pas les attentes des utilisateurs. Dans sa conférence au DevoxxFR 2014, Samuel Le Berrigaud explique comment Atlassian a récemment revu en profondeur son organisation pour « kick-ass again » (déchirer de nouveau).

Mesurer à l’avance l’intérêt

Avant de commencer tout développement, il est important de savoir quel impact aura un produit ou une fonctionnalité. Un exemple marquant est le smartphone Kin développé par Microsoft et stoppé après seulement 48 jours de commercialisation car il ne correspondait pas aux attentes des utilisateurs.

D’autres sociétés comme IBM ont eu la bonne idée de simuler l’utilisation de leur produit avant de commencer tout développement. IBM prévoyait par exemple de créer un logiciel de commande vocale d’un ordinateur. Un utilisateur a été invité à tester le logiciel de simulation dont toutes les actions étaient réalisées par un humain. La conclusion de cette étude a montré que ce moyen d’interaction était fastidieux et fatiguant.

Souvent, une analyse préalable permet d’économiser beaucoup de temps et d’argent. Il est possible de réaliser de simples maquettes sur papier pour se projeter sur les fonctionnalités à développer.

Anticiper et intégrer le retour utilisateur

Un autre point important est la boucle de feedback utilisateur. Pour avoir un produit de qualité, le retour des utilisateurs est important;en conséquences, pour les inciter à donner leur avis, il est impératif de rendre l’interface de feedback facile à trouver, simple et rapide à soumettre. Le support doit être effectué par des développeurs pour leur permettre de mieux comprendre les utilisateurs et leurs besoins.



Dans les projets de grande envergure, les équipes de développement et de test sont compartimentées. Ainsi, quand une fonctionnalité est réalisée, celle-ci est transférée à l’équipe de test et est retournée aux développeurs si une anomalie est trouvée. Cette approche est partiellement contradictoire avec l’objectif de détecter le plus tôt possible un possible bug quoique souvent nécessaire. Pour remédier à cela, les développeurs doivent aussi réaliser une partie des tests. Une fois une fonctionnalité achevée, un autre programmeur va effectuer la revue de code et réaliser des tests sommaires. L’équipe de test prend ensuite le relais.
De même, les testeurs peuvent acquérir une connaissance de programmation pour mieux réaliser leurs tests. Cela peut passer par du « pair programing » avec un développeur. Il est aussi possible d’effectuer des blitz tests (tests éclairs) où toute l’organisation effectue en un temps court, le test de l’application ou d’une nouvelle fonctionnalité.



Sur le même modèle « trans-discipline », il est intéressant de former les développeurs au design. Atlassian a par exemple fait analyser Jira par un designer qui a remarqué que l’application contenait 20 types différents de listes déroulantes. Généralement seulement quelques règles simples et outils pour tester le design sont nécessaires. Comme pour les testeurs, il est primordial d’enseigner des bases de développement au(x) designer(s).


De manière générale la multiplicité et complexité des processus nuisent à la rapidité de développement. Quelques règles simples sont suffisantes, ceci se décline par exemple dans les règles de gestion de configuration pour paralléliser les travaux:

  • Une branche par nouvelle tâche
  • Les branches ont des durées de vie limitées (2 jours en moyenne)
  • Utiliser les Pull Requests pour informer les membres de l’équipe de la disponibilité d’une nouvelle fonctionnalité

Renforcer la communication

Dans un contexte de mondialisation, un nombre croissant de projets se retrouvent avec des acteurs dans différentes régions du globe et des équipes distribuées. Le chat est un choix judicieux qui résout la majorité de ces contraintes. Ce moyen permet de dialoguer à distance, sur différents fuseaux horaires et permet d’ajouter facilement de nouvelles personnes dans la discussion. Par exemple, grâce aux historiques de conversation, les équipes peuvent consulter les discussions réalisées pendant la nuit par les autres membres de l’équipe.

Automatiser

Un des axes cruciaux pour améliorer l’efficacité est l’automatisation. Par exemple, le build de Jira était compliqué, instable, et prenait plus d’une heure. Après optimisation, seulement 10 minutes étaient nécessaires.
Voici des leviers possibles d’amélioration :

  • Eviter de reconstruire les artefacts dont le code n’a pas été modifié
  • Paralléliser au maximum les tests
  • Avoir une stratégie de build différenciée:
    1. Tests de performance durant la nuit
    2. Tests de plateformes toutes les heures
    3. Intégration continue : build + tests unitaires et graphiques après chaque check in
  • Garder un œil sur les statistiques (ex : indicateurs de qualité de code)
  • Détecter les tests aléatoires

Ces axes d’amélioration ne prétendent pas servir de référence pour l’organisation des projets, mais proposent de se poser les bonnes questions pour pouvoir délivrer un projet de qualité dans les meilleures conditions.
En conclusion : « Etre excellent dans tout ce que l’on réalise ».



Livre Blanc ‘BigData au service du Système d’information’

Voici un billet qui sort des habituelles présentations de cas techniques, mais Il en représente d’une certaine manière l’aboutissement. Il a en effet pour objectif de donner la vision que nous avons, à Infotel, des enjeux relatifs au « BigData pour le Système d’Information ».

Nous travaillons auprès de grands groupes dans une diversité de technologies et de cas métiers très importante. Nous sommes impliqués de ce fait sur des projets sensibles, au coeur des SI, qui associent bien souvent des exigences très élevées en performance, en volume de données à traiter, et en rapidité d’évolution fonctionnelle.

Le BigData commence à bouleverser dans des proportions nouvelles nos habitudes. Enjeux, opportunités, stratégies de mise en oeuvre… voici ce que nous vous proposons de parcourir au travers de ce livre blanc.

Vous pouvez le télécharger ici : http://infotel.com/services/big-data-360/


Nous vous en souhaitons une lecture profitable et sommes à votre disposition pour en discuter avec vous.

Hubert STEFANI



Retour sur DevoxxFR 2013

Voilà, c’est notre deuxième participation au DevoxxFR (sur deux éditions) et, bien qu’il y ait des redondances d’une année sur l’autre, l’impression qui s’en dégage est celle d’un souffle de fraîcheur et une volonté positive de bouger les lignes; Concrètement, être confronté à la fine fleur du développement et ses retours d’expérience sur des cas très pointus ne peut qu’être profitable :

  • Cela ouvre l’esprit quant à l’application sur nos projets présents ou à venir,
  • On capte indéniablement l’énergie positive qui se dégage de ces success story (… On peut aussi apprendre à la ‘Failure Conference’ http://france.thefailcon.com/) ,
  • On entrevoit notamment ce qui fait les succès des ‘Grands Du Web’ et comment on peut en tirer parti pour nos projets qui doivent composer avec un historique pas toujours simple à adresser

Comprendre les technologies qui motorisent les grands du Web

Exemple : L’utilisation de briques BigData pour booster son architecture et lui permettre de faire face aux défis de volumétrie que nous observons et qui n’en finiront plus de déferler :

  • Hadoop / Storm / Mahout,
  • Implémentation de solutions ‘Cloud’ : CloudBees, Google App Engine…
  • Du SQL au NoSQL (avec des morceaux de ElasticSearch dedans)

Bien plus que Java et la JVM

Toucher concrètement du doigt les nouvelles technologies (plus ou moins matures… il faut savoir faire le tri) donne une furieuse envie de faire bouger les lignes parfois un peu trop rigides (Architecture, Pratiques de développement)… à faire avec discernement bien entendu.

Par exemple : On a pu observer la poursuite de la montée en puissance du JavaScript et sa professionnalisation; on peut naturellement retenir cette approche pour :

  • L’écriture de tests d’acceptance (KarmaJS, PhantomJS, Mocha, Chai…),
  • La réalisation d’applications pures JS + CSS / HTML5 avec Angular / Ember /Backbone.

Autre observation: on en finit plus également de constater les mérites des langages fonctionnels pour leur expressivité et leur robustesse (Scala , Haskell…) et globalement les bénéfices de regarder plus loin que le seul langage Java.
Les combats épiques de Frameworks (Grails vs Play ! ) et de langages ont été à la fois réjouissants et instructifs : il faut juger constamment les technologies qu’on utilise ou qu’on pourrait utiliser et les mettre en perspective de nos propres enjeux.

et après DevoxxFR ?

Dans les jours à venir, nous reviendrons en détail sur un certain nombre de conférences et ateliers, en attendant notre conclusion est la suivante :

Il est nécessaire de cultiver son ouverture aux technologies et méthodes qui nous permettent de mieux répondre aux défis posés par nos projets :

  • C’est plus valorisant de constater qu’une de nos propositions a pu répondre positivement à une problématique (Performance, Accélération des livraisons, Qualité globale),
  • C’est une manière concrète de montrer à notre client et à nos collègues la valeur ajoutée que l’on apporte, au-delà du rôle frustrant à terme de ‘simple réalisateur’.

Cette curiosité et ce savoir-faire se cultivent continuellement (blogs, tutoriaux, projets), mais également au travers des Groupes d’utilisateurs (Java UG, Hadoop UG, Mongo UG, Android UG….) et DevoxxFR constitue un des moments incontournables pour avoir un aperçu de l’effervescence de ces éco-systèmes.



BitBucket vs GitHub

ou ‘Un coup d’œil aux gestionnaires de code source distribué’

Dans le domaine des solutions d’hébergement de projet autour du gestionnaire de source Git, deux solutions tiennent le devant de la scène aujourd’hui : Github et Bitbucket.

Voici un petit comparatif des forces et faiblesses pour vous aider à choisir, en fonction de vos attentes et de votre organisation.

Pour parler popularité, Github concentre la plus grande partie des dépôts de sources (plus de 2 millions, avec une grande représentation de projets ‘stars’ : Grails & spring sont sur Github). L’avance prise sur BitBucket s’explique notamment par les fonctionnalités et innovations apportées à ce qui est véritablement une plateforme de développement… BitBucket faisant surtout du suivisme.

Il est important de noter que BitBucket est supporté par Atlassian, qui a une certaine assise dans le monde open source (JIRA, Confluence ….)

Ils partagent une caractéristique commune et étonnante : la taille illimitée des espaces réservés au code source. Cela s’explique facilement par la nature décentralisée de Git et Mercurial et donc par la volumétrie intrinsèquement modeste du code et des méta-données.

Comparaison

Voici une grille de comparaison des tarifs et de caractéristiques structurantes prou des projets ‘Entreprise’

comparatif quantitatif Github BitBucket

(la soft limit pour github est là pour prévenir les abus, il n’y a pas de limite réelle sur la taille)

Sur ces données, les deux solutions sont relativement proches; l’écart se creuse en revanche sur la complétude des fonctionnalités couvertes, qui sont mieux adressées par GitHub:

comparatif qualitatif Github BitBucket

Plus éloquant, voici une liste des fonctionnalités intéressantes de Github dont ne dispose pas Bitbucket:

fonctionnalités supportées par GitHub uniquement

Pour aller plus loin