Automatisez votre workflow front-end

Il était une fois un webmaster

Jadis, par des temps lointains datant de l’époque où l’on comptait encore les mégahertz des processeurs, il existait des gens qui concevaient, développaient, et alimentaient des sites Internet. Tout seuls ! Ces personnes possédaient toutes les connaissances nécessaires (et même des fois le matériel sur toute la boucle) pour mettre en place un site web. Équipés des meilleurs outils (Frontpage et Filezilla), ces êtres avaient le pouvoir rare en ces temps nouveaux : on les appelait les Maîtres du Web ! Bon en fait on les appelait pas vraiment comme ça, c’était webmaster mais je vous ai offert une super traduction, en tout cas moins ringarde que celle de l’académie française qu’on croirait sortir du film Les Visiteurs !

Enfin tout ça, c’était avant. Avant le Web : 0. 2.0 pardon. Oui vous savez cette époque où on a commencé à utiliser la méthode appelé AJAX (rien à voir avec le fameux produit pour laver le sol), pour faire du DHTML. Cette même époque où on a commencé à exploiter la puissance du réseau afin de faciliter les échanges sociaux. Ces temps où du coup, on a commencé à avoir des sites qui se rapprochaient plus des applications de par leur complexité et où tous les webmasters avaient un compte sur codes-sources.com.

Petit à petit, avec le temps, la pratique, l’évolution d’Internet, les webmasters, surchargés par la masse de travail à réaliser pour s’occuper d’un site, se sont scindés en différents groupes.

Certains sont restés sur la conception. D’autres sur la réalisation de contenus. D’autres encore se sont focalisés sur le développement du site en lui même. Toutes ces branches aujourd’hui ont chaque jour de nouvelles ramifications avec les nouveaux usages que nous faisons du web.

De part ma position dans ce milieu, je vais vous parler du poste de développeur, et plus précisément du développeur d’interface. Celui qu’on appelle encore par fois intégrateur (personnellement je trouve ce nom réducteur) ou encore développeur front-end.

Le webmaster c’est un peu comme l’agriculteur qui s’occupe d’aller au marché vendre ses produits. Il s’occupe de toute la ligne. Continuant dans une analogie similaire, le poste de développeur front-end peut être assimilés à une glue entre le back-end et l’interface utilisateur : il s’occupe de mettre en place la vitrine du magasin, avec les produits fait en arrière boutique (qui utilise des matières premières) et les croquis de l’architecte. J’aime bien cette analogie.

Après j’en aime bien une autre, celle du gardien de foot. Celui qui prend tout dans les dents à la fin si ça déconne tout du long.

Mais je m’égare, parlons automatisation.

Pourquoi automatiser ?

Alors que niveau back-end, les choses sont plutôt au point (que ce soit niveau système avec les gestionnaires de paquets, ou niveau logiciel avec les diverses possibilités qu’ont les développeurs pour faire du code propre, maintenable, testable au point de tourner en intégration continue… ), au niveau du front-end, on s’y met à peine.

C’est sûr que là comme ça, quand on résume notre façon de faire, on voit mal comment automatiser tout ça. Prenons un exemple de mise en place d’un projet web, du point de vu du développeur d’interface utilisateur.

On démarre notre projet, il va donc nous falloir une base.
Si vous ne souhaitez pas utilisez de base, rendez-vous au point 1.
Si vous souhaitez partir sur de l’existant, rendez-vous au point 2.

  1. Bon courage. Bisous !
  2. C’est parti, on va faire notre petit train train habituel

On est au top, on fait de la veille, donc on sait déjà sur quoi basé notre HTML : HTMLBoilerplate. On a là un squelette HTML accompagné de pleins de bonnes pratiques. Hop hop, on le télécharge. Selon les besoins on répète l’opération pour les différents boilerplates qu’on a habitude d’utiliser. Oui quoi, on est au top, on télécharge toujours les dernières versions. Ensuite, on va se prendre quelques petites bibliothèques (toujours selon nos besoins). Un petit coup de jQuery juste pour le petit slider de la futur home page du site e‑commerce, hop hop (non je plaisante, dans la vrai vie, ne faites pas ça). On n’oublie pas de télécharger notre carousel, et le lightbox pour les photos ! Ah mince, celui qu’on prends d’habitude ne marche pas avec la mise à jour de jQuery. Aïe, ouille. On en cherche un autre où on rétrograde de version ? Bref. Une fois qu’on a bien commencé tout ça, on code. Des jours, des semaines durant. On commence le style du site (on est des fous, on utilise un pré-processeur CSS). Ça compile. On teste et on fait tester (les fameuses recettes, non, pas celle de grand-mère). On débugue, on optimise. On commit. On versionne… Et ça recommence. On code. Ça compile. On teste. On débugue. Et ainsi de suite. À certains moments, on déploie, et avant ça, on optimise (minification, optimisation des images, des polices, etc.).

Et à chaque nouveau projet, on repart du point 2.

Ne pourrait-on pas automatiser une partie de toutes ces tâches répétitives ? Ce ne serait pas être fainéant ? Surement un peu mais il faut un minimum de fainéantise à tout bon programmeur, justement pour programmer le plus possible afin de ne pas refaire encore et encore les mêmes choses qui peuvent être automatisées. En fait, ce serait reculer pour mieux sauter. Être plus efficace, afin de pouvoir se concentrer sur le code et sa qualité. Tout simplement.

Mais alors comment on s’y prendrait un développeur front-end aujourd’hui ?

Comment automatiser ?

Premier pas

Il existe depuis un petit paquet d’applications, pratiques pour les projets de petite envergure, telles que Codekit (OS X), Hammer (OS X), Prepros (OS X/Windows), Koala (Windows/OS X/Linux), Mixture (Windows/OS X), ou encore Scout (OS X/Windows).

Déjà lorsqu’on utilise ces applications, on passe à un cap supérieur. Il y a du mieux. Mais cela se limite souvent à quelque chose de similaire à de la compilation pour JavaScript et feuilles de styles. Il manque encore plein de choses à intégrer, comme par exemple la gestion des dépendances entre les librairies ou encore l’intégration des tests ou autres optimisations avant déploiement.

Gestion des dépendances

Il existe plusieurs packagers front-end qui peuvent répondre à ce besoin. Voici les principaux :

  • Bower (Pas de contraintes – JavaScript, CSS, Sass, Coffee, Images…)
  • Volo (Idem, pas de contraintes)
  • Jam (JavaScript)
  • Component (ce dernier est bien plus qu’un simple gestionnaire de paquets)

Concernant la partie dépendance on va dire que c’est du pareil au même. J’ai une petite préférence pour Bower de par sa communauté et les rockstars du web qui la soutiennent. Un comparatif en anglais est disponible sur GitHub.

Sans bower

Comme on l’a vu dans l’exemple précédent, sans gestionnaire de paquets/dépendances, ça peut vite être pénible et prendre un peu de temps pour s’occuper de télécharger ses bibliothèques favorites.

Avec bower

Avec un packager comme Bower, ça devient un jeu d’enfant. Plutôt que de parler voici ce que je viens de faire dans ma console, en moins de 25 secondes.

~
❯ bower search lightbox
Search results:

    bootstrap-lightbox git://github.com/jbutz/bootstrap-lightbox.git
    armory-blrrtstrap-lightbox git://github.com/psirenny/armory-blrrtstrap-lightbox.git
    olightbox git://github.com/olyckne/Olightbox.git
    rg-lightbox git://github.com/RGkevin/rg-lightbox.git

~
❯ bower install bootstrap-lightbox
bower bootstrap-lightbox#*  not-cached git://github.com/jbutz/bootstrap-lightbox.git#*
bower bootstrap-lightbox#*     resolve git://github.com/jbutz/bootstrap-lightbox.git#*
bower bootstrap-lightbox#*    download https://github.com/jbutz/bootstrap-lightbox/archive/v0.6.1.tar.gz
bower bootstrap-lightbox#*     extract archive.tar.gz
bower bootstrap-lightbox#*  deprecated Package bootstrap-lightbox is using the deprecated component.json
bower bootstrap-lightbox#*    mismatch Version declared in the json (1.0.0) is different than the resolved one (0.6.1)
bower bootstrap-lightbox#*    resolved git://github.com/jbutz/bootstrap-lightbox.git#0.6.1
bower jquery#>=1.7.1            cached git://github.com/components/jquery.git#2.0.3
bower jquery#>=1.7.1          validate 2.0.3 against git://github.com/components/jquery.git#>=1.7.1
bower bootstrap#>=2.0.4 <3.0       not-cached git://github.com/twbs/bootstrap.git#>=2.0.4 <3.0
bower bootstrap#>=2.0.4 <3.0          resolve git://github.com/twbs/bootstrap.git#>=2.0.4 <3.0
bower bootstrap#>=2.0.4 <3.0         download https://github.com/twbs/bootstrap/archive/v2.3.2.tar.gz
bower bootstrap#>=2.0.4 <3.0         progress received 2.2MB of 3.0MB downloaded, 74%
bower bootstrap#>=2.0.4 <3.0         progress received 2.5MB of 3.0MB downloaded, 84%
bower bootstrap#>=2.0.4 <3.0         progress received 2.8MB of 3.0MB downloaded, 94%
bower bootstrap#>=2.0.4 <3.0          extract archive.tar.gz
bower bootstrap#>=2.0.4 <3.0         resolved git://github.com/twbs/bootstrap.git#2.3.2
bower jquery#>=1.8.0 <2.1.0            cached git://github.com/components/jquery.git#2.0.3
bower jquery#>=1.8.0 <2.1.0          validate 2.0.3 against git://github.com/components/jquery.git#>=1.8.0 <2.1.0
bower bootstrap-lightbox#~0.6.1       install bootstrap-lightbox#0.6.1
bower jquery#>=1.7.1                  install jquery#2.0.3
bower bootstrap#>=2.0.4 <3.0          install bootstrap#2.3.2

bootstrap-lightbox#0.6.1 bower_components/bootstrap-lightbox
├── bootstrap#2.3.2
└── jquery#2.0.3

jquery#2.0.3 bower_components/jquery

bootstrap#2.3.2 bower_components/bootstrap
└── jquery#2.0.3

~  24s

En quelques instants, j’ai cherché un paquet, et l’ai récupéré avec ses dépendances. C’est pas le pied ça ?

Scaffolding avec Yeoman

Le terme scaffolding est un peu un abus de langage lorsque l’on connait ses origines et ce que fait réellement Yeoman. Je n’ai pas encore vraiment exploité cette outil, bien que j’ai totalement conscience de ce qu’il permet. Je vais donc vous en toucher un mot.

Comme nous l’avons vu tout à l’heure avec notre exemple, après avoir téléchargé nos bibliothèques et autres boilerplates, il faut bien coller toutes ces pièces entre elles. C’est ce à quoi sert Yeoman. Il possède tout plein de générateurs qui peuvent (entre autres) exploiter Bower. Il y a même un générateur de générateur. Je vous laisse jeter un coup d’oeil sur les générateurs dont les noms vous diront quelques choses afin de bien comprendre ce que fera cette outil.

Automatisation des commandes quotidiennes

Le niveau suivant, après avoir créé sa base de projet avec des outils comme Bower et Yeoman, c’est d’automatiser les commandes du quotidien : pré-processing, tests automatisés, optimisation, déploiement… Nous avons depuis un bon bout de temps des clés en main pour résoudre cette problématique :

La base : Make

Make est une solution datant de 1977 ! C’est une commande qui permet tout simplement d’en exécuter d’autres, avec du code similaire à du shell script. Dans notre cas, on pourra se créer des commandes tel que make compilemake testsmake deploy… Voici un exemple plus parlant :

all: install build test

install:
    bower install

watch:        
    sass watch [...]

build:
    sass compile [...]
    uglify [...]

test:
    casper [...]    

Je n’ai volontairement pas rempli les sous commandes, mais vous devinez le principe : on déclare des tâches qui en exécutent d’autres. Ça évite de se taper les lignes à chaques fois. On peut même faire un tâche qui execute d’autres tâches. Dans notre exemple la commande make all.

Avec ce genre de petit fichiers en plus de Bower et Yeoman, on se simplifie carrément la vie. Et lorsque l’on travail en équipe, plus besoin d’expliquer la commande à lancer au nouveau développeur ou au sysadmin pour le déploiement.

Alternatives

Make étant assez limité, d’autres émules sont apparus adaptés à différents langages tel que Rake (Ruby), Cake (Clojure), Jake (JavaScript)… Il existe aussi Ant basé sur XML, ce qui rend les fichiers très verbeux. (Et puis bon, celui-là est fait en Java.) Je ne me suis fait à aucun de ces outils mais j’ai beaucoup accroché au petit dernier : Grunt.

La technique de porc

Bon ok, Grunt c’est pas vraiment un porc, plutôt un sanglier, et encore qu’il y aurait des origines en rapport avec Warcraft.

Donc avec cet outil, on passe au summum de l’automatisation. Pourquoi plus qu’avec les autres ? De part son écosystème. Grunt possède énormément de tâches déjà disponibles dont voici quelques exemples (je vous passe les grunt-compassgrunt-lessgrunt-uglify et compagnie):

Je m’arrête là car on a plus de 1700 tâches disponibles, il y a donc de tout et n’importe quoi. Mais si vous pensez à une tâche Grunt, il est possible qu’elle existe déjà. Et si ce n’est pas le cas, il est très facile d’écrire ses propres tâches Grunt, sans forcément devoir les publier où que ce soit.

Pour découvrir Grunt pas à pas, je vous invite à lire l’article Premiers pas avec Grunt. Si vous souhaitez aller plus loin ou que vous voulez directement mettre vos yeux dans du code source, je vous invite aussi à regarder le code source du projet HappyPlan, un générateur de site statique basé sur Grunt. Vous y verrez comment exploser votre Gruntfile en petits fichiers, beaucoup plus pratique pour la maintenance.

Alternatives intéressantes à Grunt

Il existe aujourd’hui deux alternatives sérieuses à Grunt.

Brunch

La première est Brunch.io. Le projet se veut plus simple et plus rapide d’utilisation au détriment de la flexibilité qu’apporte Grunt. Je vous invite à regarder le tableau comparatif afin de vous faire votre propre opinon. Notez que pour les points concernants l’intégration de Bower et de Source Maps, cela peut se faire via des plugins Grunt. Il reste donc bien la vitesse comme argument majeur.

Gulp

La deuxième alternative tout fraîche est Gulp. Le point fort de ce petit dernier est son approche par flux plutôt que par fichiers. Cela afin d’avoir de meilleurs performances en évitant multiples lectures/écritures durant votre workflow. Ne parlons pas de la flexibilité car ici point de configuration, juste du simple code à coupler avec de simples composants (cf la page du projet où vous trouverez des exemples). Je vous invite à lire ces slides : Gulp, The streaming build system qui montrent avec des schémas les différences entre ce projet et l’approche de Grunt. Vous trouverez les composants Gulp disponible via cette simple recherche sur npm.

Personnellement, j’utilise actuellement Grunt pour son écosystème, mais je pense essayer Gulp sur mon prochain projet. En effet quand on commence à avoir un workflow très poussé, on peut commencer à sentir de petites lenteurs avec Grunt.

J’espère vous avoir donné envie d’automatiser votre quotidien de développeur front-end. En ce qui me concerne, je ne pourrais plus faire machine arrière, surtout depuis que j’ai gouté au livereload !

À noter que derrière le mot livereload ne se cache pas uniquement l’application Livereload. Il existe maintenant tout un tas de composants à brancher sur votre workflow actuel.

11 commentaires sur cet article

  1. MathRobin mthrobin@gmail.com, le lundi 9 décembre 2013 à 10:22

    Hello ! Merci pour toutes ces petites explications qu’on a tendance à croire que tout le monde est au courant mais en fait non. Comme toi, pour Gulp, le prochain projet que je ferai l’utilisera, ça a l’air, au delà des perfos, d’être bien plus agréable à mettre en place.

  2. Geoffrey, le lundi 9 décembre 2013 à 18:07

    Hello,
    Merci pour cet article fort sympathique !
    Je ne connaissais pas Gulp, thanks :)

    Sinon je crois qu’il y a une faute qui se répète : « On test », il me semble que c’est plutôt « on teste », non ?

    Merci

  3. MoOx, le lundi 9 décembre 2013 à 20:14

    Pour la faute « On test », c’est très probable, je ne suis pas un cador en orthographe :)

  4. Raphael, le lundi 9 décembre 2013 à 23:00

    Hello,

    Très joli article sur des techniques et outils qui deviennent de plus en plus nombreux, voire complexes.

    Automatiser devient une nécessité dans un environnement de production.
    Le tout est de savoir jusqu’où on devient dépendant d’outils multiples et différents. Et surtout si à force d’outiller, on ne perd pas un peu de saveur dans notre beau métier ;)

    Note, j’ai repéré plusieurs petites typos :
    – « On oublie pas »
    – « après avoir télécharger »
    – « après avoir créer sa base »

  5. _kud, le mercredi 11 décembre 2013 à 10:00

    Quand tu parles de saveur Raphael, tu parles de faire des trucs à l’arrache en mode ftp, tout le monde bosse sur le même serveur de dev, et YOLO dès qu’on met en production ?

  6. _kud, le mercredi 11 décembre 2013 à 10:09

    Je peux comprendre la crainte qu’ont les gens à voir leur métier s’industrialiser. Et je comprends aussi le fait que rendre scriptable tout notre workflow et donc exécutable par n’importe quel benêt (”grunt dist”) peut faire peur car cela simplifie grandement notre développement au point qu’une fois ces scripts faits, ton expertise technique ne sert plus vraiment à rien.

    Cependant, ce genre de workflows permet :

    1/ que tout le monde développe dans le même contexte et donc réduit les frictions, les marges d’erreurs (avec la production au passage)
    2/ d’augmenter la productivité
    3/ de faire en sorte qu’une nouvelle personne arrivant dans la boite n’a pas une pile de docs à apprendre avant d’être opé
    4/ de se concentrer sur autre chose de plus essentiel que la manière de compiler / mettre en prod, etc :)

  7. MoOx, le mercredi 11 décembre 2013 à 10:13

    On peut enfin effectivement se concentrer sur le code.
    C’est pour la même raison que j’ai arrêter d’utiliser des distributions linux où j’avais plus souvent des problèmes à chaque mise à jour/changement de hardware.
    J’ai un itruc, et Ça Marche™
    Dans la même idée, j’ai mis en place mon workflow, et Ça Marche™ pour quiconque lance la commande adéquat.
    :)

  8. _kud, le mercredi 11 décembre 2013 à 10:15

    C’est super important lorsqu’une personne arrive sur un projet (open source ou non) qu’elle puisse d’emblée en quelques lignes commencer son dev.

    Typiquement, sur mes projets open source, je fais en sorte d’avoir deux lignes de commande pour commencer le projet

    ”make install” puis ”grunt”. Là, tu es opérationnel pour bosser dessus.

  9. Raphael, le jeudi 12 décembre 2013 à 21:27

    @_kud « Quand tu parles de saveur Raphael, tu parles de faire des trucs à l’arrache « .

    Si pour toi il n’y a que « tout noir » et « tout blanc », effectivement…
    Je parlais effectivement d’un truc un peu intermédiaire où l’humain peut encore décider, affiner, revenir en arrière, faire des choix, innover, etc.

    Je ne critique pas du tout l’intérêt de ces outils, cet intérêt est évident et indiscutable.

    Ce que je tenais à dire – si c’est possible – c’est que si l’objectif est d’automatiser et de se faciliter les tâches en unifiant nos divers outils, comment se fait-il que cet article en propose… un 15aine différents qui se complètent les uns les autres ?
    Oui certains sont des alternatives à d’autres. Mais c’est justement mon interrogation : c’est tellement la jungle qu’on ne sait aujourd’hui pas lequel survivra et combien ne seront plus mis à jour dans 2 ans.
    Baser une stratégie de production sur des outils aussi jeunes et multiples mérite peut-être une petite réflexion préalable.

  10. Pomeh, le vendredi 13 décembre 2013 à 00:00

    Merci pour cet article très intéressant. C’est vrai que maintenant qu’on a tellement de technos différentes (pré-processeur CSS etc) et d’outils différents (JSHint, unit test & co) l’automatisation devient presque vitale pour les projets.
    Cet article me fait penser à celui-ci http://zachholman.com/talk/unsucking-your-teams-development-environment/ à propos de Github : lorsqu’une nouvelle personne arrive chez eux, elle est opérationnelle en 20 minutes ! Ça parait totalement hallucinant !!

    Par contre je rejoins Raphael sur le fait que 1) il y a tellement d’outils différents qui font la même chose qu’on s’y perd très vite et ça peut décourager, et 2) on ne sait pas trop quelle est la stabilité et la pérennité des différents projets. Par exemple le projet Twitter Bootstrap (un peu hors contexte mais c’est pour l’exemple!) n’a même pas 3 ans (il date d’avril 2011) et il a déjà 3 version majeures différentes ! Si je pars pour bosser sur un gros projet qui va durer plusieurs mois/années, ça parait compliqué d’utiliser des outils qui risquent d’être déjà déprécie avant la fin même du projet. Quid de la documentation, des bugfix etc ? C’est bien que les choses évoluent rapidement, ça montre de l’intérêt et permet d’avoir des outils toujours plus performants, mais si je dois totalement réapprendre à utiliser mes outils tous les 6 mois c’est contre-productif. Enfin là je m’éloigne un peu trop du sujet de cet article…

  11. Franck, le lundi 1 septembre 2014 à 15:54

    Bonjour,
    9 mois après, est-ce que cette analyse est toujours d’actualité ? Comme vous le dites si bien, les technos se renouvellent à une vitesse grand V. Certaines nouveaux apparaissent, d’autres deviennent plus matures, d’autres dépassés.
    Est-ce aussi valable pour des projets mobiles ou existent-ils des outils similaires ?
    Merci à vous pour ces informations et les retours,
    Franck