SAP HANA (sur Amazon Web Services), l’in-memory pour booster l’analytique.

16 janvier 2015 - Publié dans Bases de données, Big Data, Cloud, NoSQL

Nous vous proposons de parcourir les caractéristiques de HANA la base in-memory colonne développée par SAP, et vous inviter à connaître la solution au travers de l’offre de Amazon Web Services qui offre un terrain de jeu parfait pour un POC.

HANA : Une base colonne en mémoire

Avec l’avènement des nouvelles architectures matérielles vers 2005 ( CPU plus nombreux et plus rapides, RAM dépassant le TB ), les bases colonnes ont trouvé un support leur permettant de se développer industriellement. A ce jour, outre HANA, on peut citer Vertica ( HP ) ou Oracle ( option in-memory ) comme alternatives sur une machine Unix/Linux. Mais plus généralement, tous les grands éditeurs possèdent une option colonne dans leur catalogue et il est frappant d’observer qu’il n’existe pas (encore ?) de bases colonnes open source disponibles du type Cassandra ou Couchbase !

Les bases in-memory colonnes ont pour but d’optimiser l’OLAP, c’est-à-dire l’analytique en direct. Pour ce faire, elles se reposent sur les principales caractéristiques suivantes :

Un taux de compression de 10 ou plus sur les colonnes :

En effet, l’entropie est beaucoup plus faible sur une colonne que sur une ligne, les données se « ressemblant » plus. Ainsi, des algorithmes de compression moins consommateurs en CPU ( RLE, bit-vector, dictionnary, … ) ont pu être mis en oeuvre pour profiter de cette faible entropie.
Une nouvelle localisation des données :

Au démarrage de l’instance, les données sont chargées en RAM. Puis, la vectorisation des colonnes permet à ces dernières de résider dans les caches du processeur, d’où une accélération supplémentaire en terme d’accès à la donnée.
Une parallélisation accrue :

Au niveau des processeurs, la technologie SIMD ( SingleInstructionMultipleData ) permet d’effectuer des opérations binaires entre les vecteurs.

HANA propose d’aller plus loin en se positionnant comme une base pouvant également gérer l’OLTP, un choix différent d’Oracle qui propose le mode colonne en complément du mode ligne.

Pour ce faire, SAP a introduit un concept de merge delta permettant de gérer les mises à jour unitaires et en masse. Pour les mises à jour unitaires, la zone delta est en mode ligne. Les données sont ensuite déversées dans la zone réservée aux mises à jour de masse, zone en mode colonne non optimisée. Enfin, les données rejoignent la zone principale de manière asynchrone. Sur ce point, l’éditeur doit encore faire ses preuves, la plupart des cas d’utilisation publiés étant relatifs à la BI.

Quel impact sur le développement ?

Le développement des requêtes se fait en SQL et les procédures stockées sont écrites en SQL Script. La grammaire SQL est déjà bien étoffée ( lien : http://help.sap.com/hana_appliance => SAP HANA SQL and System Views Reference). En revanche, le langa
ge SQL Script (SAP HANA SQLScript Reference ) est principalement dédié au traitement OLAP, en particulier les fonctions qui ne sont utilisables que pour les lectures afin de les paralléliser au mieux. Les procédures, quant à elles, permettent d’encapsuler les requêtes SQL de toute nature, mais il est encore pénalisant de gérer les transactions ( commit & rollback non autorisés ) au sein d’elles.

De plus, SAP met en avant un modèle analytique basé sur des attribute view ( dimensions ), des analytical view ( tables de fait ) et des calculation views ( calculs sur les tables de fait ) permettant de concevoir un modèle en étoile dans un contexte colonne. Les calculation views se basent sur des CE-Build In fonctions ou des requêtes SQL de lecture. Il existe aussi un outil de conception entièrement graphique qui permet de mettre en oeuvre ce modèle analytique.

Lancer son instance HANA dans AWS

Afin de promouvoir HANA, SAP propose de s’initier à ce produit via Amazon Web Services (AWS). L’instance HANA peut être déployée à Francfort ou en Virginie du Nord. Petite limite observée à ce jour, Il est préférable de déployer sur l’instance des Etats-Unis, pour surmonter des problèmes de disponibilité (machine non réservée perte de contexte à chaque arrêt / démarrage ). Elle repose sur une machine Linux Suse de type m2.4xlarge ( 8 vcpu, > 60 GB RAM ).

En termes de coût, l’instance HANA est gratuite et l’infrastructure mise à disposition par AWS payante (Remarque : le coût de possession sur ses propres infrastructures n’est pas sur ce modèle). A titre d’exemple, le coût peut être déchiffré de la manière suivante :

$1.080 par heure d’exécution ;
$0.05 par GB au-delà de 30 GB par mois ;
$0.05 pour un million d’IO au-delà de 2 millions d’IO par mois ;
$0.095 par GB ( snapshot ) au-delà de 1 GB par mois ;
Taxes (20 %).

opérationnel en 2 heures

En termes technique, la procédure est décrite à cette adresse : http://scn.sap.com/docs/DOC-28294 et permet d’être opérationnel en 2-3 jours, le temps d’initialiser le compte AWS. Si ce dernier existe déjà, l’installation est faite en quelques heures, le temps de se familiariser avec la version cloud d’HANA.
Bien que relativement simple d’appréhension, la création de l’instance HANA peut vous conduire à recevoir des erreurs délivrées par les web services d’AWS.

Exemple : lors de la configuration du compte AWS, vous pouvez tomber sur cette page:

Dans ce cas, contacter le support disponible sous AWS ; il est très réactif.
Une fois l’installation effectuée, l’instance se pilote via le site HANA Enterprise Cloud/Cloud Appliance Library :

HANA STUDIO, client basé sur Eclipse, permet de développer, d’administrer et de monitorer l’instance HANA.

Pour étudier cette solution, j’ai créé quelques tables en mode colonne ( nombre de colonnes variant entre 10 et 50, nombre de lignes variant entre quelques dizaines de milliers et 1 million ). Mon objectif n’était pas de tester des grandes tables ( plus de 1 GB en mode compressé ), mais de vérifier l’efficacité de la compression en mode colonne. Sur ce point, j’ai bien retrouvé des facteurs de 10 ou plus sur les colonnes non uniques.

D’autre part, je souhaitais étudier le SQL Script et ses limites pour la mise à jour. Je vous ai déjà parlé de la non gestion des transactions, mais il faut aussi savoir qu’il ne dispose pas de bulk collect. Si vous souhaitez l’équivalent, il vous faudra par exemple utiliser le mode batch de la couche JDBC. Comme alternative payante, vous pouvez utiliser SLT, un outil de réplication ou Data Services, un outil de chargement des données. Pour le chargement des fichiers, vous disposez aussi d’une commande import gratuite et optimisée ( thread, batch size ).

Enfin, je me suis intéressé à l’optimiseur colonne de HANA afin de mieux comprendre comment il fonctionne en terme de gestion des jointures ( jointure à 1 ou n colonnes ), d’utilisation des colonnes, de calculs d’agrégat. Pour ce faire, un outil indispensable : SAP HANA Plan Viz. Pour information, Hana dispose aussi d’un optimiseur ligne pour les tables en mode ligne et d’un optimiseur en mode OLAP pour le modèle analytique.

Changer de technologie c’est changer de paradigme

Avant de se lancer dans le grand bain, il faut appréhender ce nouveau type de solution en changeant de paradigme : le mode ligne n’est plus applicable ; il faut comprendre comment les opérations de lecture et d’écriture sont repensées et construire son modèle de données selon ces particularités. Un simple exemple très explicite: les index sont la plupart du temps inutiles en mode colonne.
Enfin, je vous conseille de lire ce post : http://scn.sap.com/community/hana-in-memory/blog/2013/12/29/6-golden-rules-for-new-sap-hana-developers.

Pour en savoir plus sur les bases colonnes et HANA :

Column-Oriented Database Systems : S.Harizopoulos, D.Abadi, P.Boncz [ VLDB 2009 Tutorial ];
The Design and Implementation of Modern Column-Oriented Database Systems: D.Abadi, P.Boncz, S.Harizopoulos, S.Idreos [ Foundations and Trends in Databases, 2012 ];
Building Advanced Data Model with SAP HANA: W.Steyn [ 2011 ];
Best-practices-for-sap hana data load: http://scn.sap.com/community/hana-in-memory/blog/2013/04/08/best-practices-for-sap-hana-data-load.

Stéphane NOTTER, Expert Architecture des données.

Premier pas dans l’internet des objets avec les Beacons

9 octobre 2014 - Publié dans ElasticSearch, HTML5, Mobile / iPhone /Android

Nous voulons partager avec vous notre projet Beacon tout juste sorti par notre équipe Innovation.

L’idée est de pouvoir accompagner nos clients dans leurs projets disruptifs et force est de constater que l’Internet des Objets (IoT) est au cœur des enjeux du moment. L’annonce de Google concernant le ‘Web Physique’ (https://github.com/google/physical-web/blob/master/documentation/introduction.md ) ne va pas démentir cette observation.

Toujours plus contextualisée et personnalisée, l’information va vivre au contact des balises Beacons, tags NFC ou autre. Notre projet est de démontrer le potentiel de ces technologies en associant une application mobile avec une solution Web qui officie à la fois comme pilote des fonctions contextualisées et réceptacle du flot de données généré (…Big Data, le mot est lâché).

Fonctionnement schématique de la solution

Première étape, l’acquisition de la balise et sa configuration.

On trouve des sites qui offrent des packages prêts à l’emploi, il faut ensuite associer paramétrer les quelques informations qui seront émises par notre balise.

UUID : c’est l’identifiant unique de notre balise, modifiable et donc personnalisable
Major : un des paramètres modifiables; on pourra y associer par exemple un numéro de magasin
Minor : autre paramètre, qu’on peut penser comme une précision apportée à un ensemble de balises reliées par la valeur d’un ‘Major’, comme le rayon d’un magasin

Balises utilisées pour le projet d'Infotel

Deuxième étape, créer l’application qui va capter le signal et prendre la décision appropriée :

Prérequis, il faut que votre téléphone embarque la prise en charge du BlueTooth Low Energy, qui est aujourd’hui disponible pour les smartphone sous iOS, Android 4.3 et Windows 8.
Une fois maîtrisée la détection du signal, on crée différentes interactions, différenciées selon que l’application est en veille ou en premier plan.


Envoyer une alerte ou un message associé à la proximité d’une balise	Lorsque l’application est en veille, les notifications sont possibles, de manière plus ou moins intrusive.

Pour une interaction plus riche, on propose l’affichage d’un contenu HTML qui est fourni par notre serveur, mais on pourrait également constituer un message si l’application mobile embarque la logique (catalogue de produit embarqué, envois de messages en mode chat).

Voici le périmètre de notre solution :

Créer une application qui capte les signaux des Beacons,
Dans une approche connectée, envoyer au serveur les informations techniques de la balise associée à son identifiant,
Recevoir en retour l’action à déclencher qui se peut prendre une des valeurs suivantes :
Aucune action : nous voulons simplement enregistrer le passage de notre usager,
Réveil de l’application,
Affichage d’une notification,
Affichage d’un contenu Web (dans une WebView).
Filtrer les événements pour ne pas prendre en compte les signaux qui ne sont pas directement liés à notre parc de balises,
Afficher un sémaphore de présence de balises.

Par ailleurs, nous avons ajouté quelques fonctionnalités pour l’administration du parc : historique des signaux captés, débogage avec visualisation des informations techniques, configuration, et comportement par défaut au travers de ‘bouchons’ pour simuler une connexion à notre serveur.

Troisième étape, piloter son parc.

Il faut ensuite associer du contenu et des comportements à chaque balise, ce que nous faisons dans notre application centrale. En voici quelques captures d’écran représentatives.

Paramétrage d'une balise et association d'actions

Création d'une action type

Visualisation d'une événement lié à une balise

Quatrième étape, analyser et améliorer.

Pour faire vivre la donnée et comprendre les comportements relevés par nos balises, rien de mieux que d’utiliser la masse d’information correspondant aux événements en les déversant dans ElasticSearch (par exemple).

On crée ainsi des tableaux de bord dans lesquels on décline les différentes actions, avec une visualisation temporelle.

On peut ensuite se pencher sur une classification et une analyse plus poussée.

Infotel partenaire d’Elasticsearch

1 juillet 2014 - Publié dans Big Data, ElasticSearch

Infotel est fier de vous annoncer son nouveau partenariat technologique avec Elasticsearch, effectif depuis le 12 mai 2014.

Pourquoi ce partenariat ?

1.

Pour Infotel, il permet de développer son expertise reconnue dans la mise en œuvre de d’approches innovantes pour lesquelles Elasticsearch joue les premiers rôles.

2.

Pour Elasticsearch, il offre à ses clients la qualité de son support en l’accompagnant de l’expertise d’Infotel qui opère au cœur des systèmes d’informations complexes (Banque, Industrie Automobile, Assurance, Services…).

Infotel développe au cœur du métier de ses clients des solutions qui s’appuient sur les formidables capacités d’Elasticsearch à indexer et valoriser de très grandes quantités de données. Que ce soit de la donnée en texte libre (Documents, facture, Mails, tweets, forums..), des logs techniques, des logs applicatifs ou bien de la donnée statistique, la liberté offerte par Elasticsearch en fait un choix de premier ordre pour construire sa solution BigData.

Exemple : Solution d'exploration documentaire motorisée par Elasticsearch

De plus, Infotel poursuit la montée en compétences de ses collaborateurs sur les technologies Big Data pour vous permettre d’accéder à un savoir-faire reconnu et en ligne avec votre stratégie IT. Vous pouvez désormais le compléter avec le support Elasticsearch dont vous avez besoin, lors de vos développements ou votre passage en production.

Vous voulez en savoir-plus ?
N’hésitez pas à nous contacter : ingenierie.technique@infotel.com

Université de la Performance -retour sur DevoxxFR 2014

28 mai 2014 - Publié dans Java / JEE, Tests

Sebastien VAIRA, Senior Developper JEE / Grails revient sur une session Performance de DevoxxFR 2014

La performance, partie intégrante du travail de chacun d’entre nous, se doit d’être au cœur de nos développements ; nous ne devons pas négliger cet aspect et l’intégrer au plus vite dans nos cycles de développements. Car s’attaquer aux mesures (métriques) suite aux développements est rarement gage de réussite ; cela peut même induire une forte refonte du code, voire une remise en cause de l’architecture. Et c’est là que les plus grosses dérives se produisent…
Dans cet article, nous allons revenir sur les outils de référence et les pratiques qui ont été abordés lors du Devoxx 2014.

1. Préparer les jeux de données – Benerator

Il n’est pas toujours aisé de pouvoir disposer d’un jeu de données d’une volumétrie comparable à celle de PROD mais aussi d’une qualité semblable.
Certains d’entre nous, en particulier dans le domaine bancaire, ont également des contraintes d’anonymisation à respecter ; ce qui complexifie encore davantage la mise en place (l’acquisition) d’un jeu de données cohérent (vis-à-vis de la PROD).

Pour répondre à cette problématique, il existe l’outil : Benerator
http://databene.org/databene-benerator

Qui présente (entre autres) ces avantages :

Génère des données de TEST sans limite de taille
Rend anonymes les données sensibles
Insère des données en base si besoin / les ressort en fichiers sinon (CSV/XML/plat etc.)
Il embarque de base différents domaines (adresse, personne, web, finance etc.) pour faciliter la création de données
Il est multi-plateformes
Il supporte la majorité des BDD (Oracle, DB2, MySQL, PostgreSQL etc.)
Enfin, il est gratuit.

2. Exécuter une mesure unitaire – Chrome developer tools

La mesure unitaire réfère ici à un test de performance avec un utilisateur sur une base de données chargée.
Ceci peut facilement être réalisé avec Chrome DevTools qui nous fournit de nombreux composants pour :

tracer le temps réseau :
tracer la chronologie des événements (timeline) et ce qui prend du temps (chargement des ressources, parsing JS, calcul des styles etc.) :
tracer le temps d’exécution des scripts et l’utilisation mémoire :

3. Exécuter des tests de charge – Gatling

Cette fois par test de charge, on entend ici une cible de 100 utilisateurs par ex. et ce sur un volume BDD de PROD.
Simuler l’utilisation simultanée de votre serveur par X utilisateurs est généralement réalisé par l’écriture d’un script.
On connaissait jMeter, outil open-source d’Apache, qui réalise correctement ce travail mais qui est considéré, du moins au Devoxx, comme « ancestral ».
LoadRunner, logiciel HP payant ;
la tendance serait plutôt désormais à l’utilisation de l’outil Gatling :
http://gatling-tool.org/

Ce dernier offrant comme particularités :

Un vrai langage de développement pour les scripts : le Scala (il s’agit donc bien ici d’un développement à part entière dans le cadre d’un projet)
Un module ‘Recorder’ (sorte de proxy entre votre navigateur et votre application) vous aidant à écrire des scénarios ; pour ce faire, il suffit simplement de l’activer et de naviguer au sein de votre application Web…
La mise à disposition d’un plugin Maven gatling
La génération de rapports HTML avec graphiques très sympas (visuel + significatif) :

A noter, toujours dans la rubrique des tests de charge réalisables via Gatling, que bien souvent les tests suivants ne sont pas considérés/réalisés :
a) Test de rupture
Ayant pour objectif de déterminer les limites de votre application (en terme de nombre d’utilisateurs max ou de temps de réponse non acceptable)
b) Test de vieillissement (test d’endurance)
La capacité de votre application à fonctionner sur une période étendue (ex : 48h) avec une charge constante égale à la charge moyenne.
Il est évidemment conseillé de ne pas les négliger…

4. Industrialisation/automatisation des tests de charge – Jenkins, Capistrano, Chef

La question des performances est souvent traitée à la fin du projet ;
Ce qui implique que si elles ne sont pas acceptables, des dérives risquent d’être observées pour rectifier le tir ; l’architecture risque même d’être revue !
Ainsi donc, pour éviter ce type de faux pas, il faut intégrer les tests de performance au plus tôt dans le cycle de développement de nos projets et ce de préférence au sein d’une intégration continue.

Jenkins, outil open-source d’intégration continue, est un bon candidat pour ce faire.
http://jenkins-ci.org/

Au sein d’un job spécifique gatling, il permettrait par ex. de :

a) Créer un environnement
b) Réaliser un/des tirs de performance
c) Détruire ce contexte.

On pourrait ensuite visualiser les tableaux de bord Gatling résultants directement sous Jenkins.
Une des particularités intéressante en découlant serait de poser des limites sur les temps de réponse attendus pour votre application (ex : <=200 ms) ; De sorte que si un des développeurs impacte l’aspect performance, le build Jenkins soit en conséquence cassé et le développeur notifié par mail… A noter, dans l’optique de mise en place sous Jenkins d’un environnement adéquat pour réaliser les tirs de performance (ex : application déployée temporairement sur un espace virtuel), que ce dernier peut facilement être couplé aux outils suivants : ‘Chef’ et ‘Capistrano’. Chef permettant de déployer facilement serveurs et applications sur un emplacement physique/virtuel/cloud : http://www.getchef.com/chef/

Capistrano permettant d’exécuter des commandes SSH sur des serveurs distants :
http://capistranorb.com/

6. Problème de contention/identifier une fuite mémoire – VisualVM

Pour mesurer la consommation des ressources d’une application tournant sous la JVM, il est préconisé d’utiliser l’outil VisualVM, fourni dans les distributions Sun du JDK.
Egalement disponible en téléchargement ici :
http://visualvm.java.net/

Cet outil nous offre une petite interface graphique simple pour le suivi :

De l’utilisation CPU
De la consommation mémoire
Du volume de classes chargées par la VM
Des threads

Il permet aussi :

De réaliser le monitoring sur une application distante :

De réaliser un profilage CPU/mémoire :
Et enfin de diagnostiquer les fuites mémoires (par analyse des opérations qui consomment le plus)

Avec ce type d’outil, vous avez désormais de nombreuses possibilités pour analyser les problèmes de contention.

7. Identifier un problème d’index – jstack, explan plan

8. Mise en place du monitoring – collectd, Graphite et Metrics

Collectd : outil portable écrit en C et agissant tel un démon qui ‘monitore’ tout périodiquement et collecte des métriques relatives aux statistiques de performance du système
http://collectd.org/
Graphite : outil écrit en Python proposant des interfaces graphiques avancées pour le suivi temps-réel des métriques de votre serveur
http://graphite.wikidot.com/
Metrics : librairie Java intégrable dans votre projet via Maven et permettant de mesurer le comportement des composants critiques ; A noter qu’il se couple à Graphite pour la partie reporting.
http://metrics.codahale.com/
metrics-spring : annotation Spring ‘@Timed ‘ sur les méthodes (sensibles) de votre serveur ;
permettant d’obtenir ce type de sortie console/log:

9. Tuning système – Bonnie++

Les développeurs ne sont pas toujours à incriminer dans le cas de performances insatisfaisantes ;
N’oublions pas que les disques durs, CPU, cartes réseaux sont autant de composants qui peuvent influer sur les résultats d’une application ; et donc par conséquent l’aspect ‘Tuning d’infrastructure’ est alors à considérer.
A été abordé lors du Devoxx un petit outil de benchmark : « BONIE++ » pour réaliser une analyse système et vérifier si des optimisations sont possibles.
http://www.coker.com.au/bonnie++/

Conclusion

Cet article a plutôt vocation à être un recueil d’outils (en tout genre) pour réaliser des mesures unitaires/de charge, automatiser ces tests au sein d’une intégration continue, disposer de tableaux de bord modernes, être capable suite à l’obtention éventuelle de résultats négatifs de diagnostiquer un problème de contention/fuite mémoire/index et aller pourquoi pas jusqu’à du tuning système.
Chacun de ces outils a été abordé, ses facettes notables retranscrites ; je laisse néanmoins à chacun d’entre vous la possibilité de ‘creuser’ et de déterminer la réelle valeur ajoutée de l’outil au sein de vos projets.

Dépoussierez votre construction d’appli avec GRADLE

25 mai 2014 - Publié dans Java / JEE, Process et méthodologies

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.

Les experts d’Infotel

Le blog des experts du groupe Infotel