Le contexte

Tout débute par un client. Une entreprise qui gère des documents et des articles sur tout ce qui concerne les textes légaux sur le droit du travail dans les sociétés françaises. Elle existe depuis des décennies et comme toutes les entreprises de média et de documentation, elle produit beaucoup de contenu chaque année.

Au fil des années, par la création de plusieurs sites web, ils ont une accumulation de divers technologies et langages. Le client souhaite aller de l'avant, réduire la dette technique et simplifier toute son infrastructure. Et réduire les coûts si possible.
Il désire donc basculer une bonne partie des sites actuels sur des sites statiques.

Mais avant d'investir de l'énergie humaine et de l'argent dans cette grosse migration, il est indispensable de tester les possibilités des solutions, vérifier que la solution matche bien avec le besoin et les enjeux business.

Choix des générateurs et du CMS Headless

Côté CMS, le choix est déjà arrêté sur Craft CMS. C'est un CMS qui propose une très bonne expérience pour l'édition et surtout, il permet un mode headless avec des fonctionnalités très intéressantes par défaut. On y retrouve notamment: un mode prévisualisation, une API GraphQL et des webhooks. Parfait pour fonctionner avec un site statique.

Le mode prévisualisation offre une bonne expérience aux responsables du contenu. Il est très important pour une complète adoption par l'équipe de pouvoir éditer du contenu et vérifier le rendu immédiatement.

Comme le mode prévisualisation est un prérequis, cela élimine déjà tous les GSS (générateur de site statique) pur HTML (Hugo, Eleventy, etc.) sur lequel on ne bénéficie pas de cette fonctionnalité.
On s'oriente donc sur deux solutions qui offrent la possibilité de fonctionner dans ce mode. C'est donc Nuxt.js et Next.js qui sont retenus.

Gastby aurait pu être utilisé aussi grâce à la nouvelle route API mais nous souhaitons conserver des process de build assez rapide. D'expérience, je connais bien Gatsby et je sais qu'il est le moins performant — ce prototype précède l'annonce de la version 3.0 annoncée comme plus rapide.

Pour être 100% honnête, cet article a mis de côté Gastby au profit de Next.js dès le départ.

Commençons avec Next.js

Nous commençons avec Next.js, et nous avons hâte de découvrir le mode incrémental. La vitesse de publication d'une nouvelle version du site est également un point important. En effet, Next.js a implémenté deux modes intéressants dans les dernières versions : le mode incrémental et la régénération des pages.

Néanmoins ces deux fonctionnalités et le mode prévisualisation ne sont pas disponibles dans le mode entièrement statique (export HTML). Donc pour Next.js, le mode hybride est obligatoire et demande donc un serveur Node.js pour le faire tourner. Pas de soucis aujourd'hui, car Vercel est très accessible en termes d'hébergement et Netlify propose aussi la possibilité de faire tourner Next.js en mode hybride sur son service.

Génération des 11 000 pages et premier blocage

Durant le développement, je travaillais avec un échantillon d'une centaine de pages. Jusque là, tout va bien. Je fais mon développement, j'ajoute les pages, la pagination. Tout fonctionne parfaitement.

Il est temps de tester avec les 11 000 pages. Et là, patatras ! L'API a du mal à suivre les requêtes. Eh oui, 11 000 pages, c'est autant de requêtes pour générer chaque page dans un temps très court. Évidemment, à ce stade, rien n'est optimisé du côté du CMS mais c'est un premier blocage dans la génération des pages.

Pour optimiser les appels vers l'API, je fais un système de cache qui permet d'utiliser les fichiers du cache au lieu d'appeler l'API. Je génère le cache juste avant le build.
Tout fonctionne parfaitement. Les 11 000 pages prennent entre 5 et 8 minutes pour être créées.

La surprise ou le blocage qu'on attendait pas

Bon OK, le temps de build des 11 000 pages est un petit peu long. Si on doit attendre à chaque fois entre 5 et 10 minutes pour avoir une nouvelle version en ligne, ce n’est pas top.

Mais là où nous avons été surpris, c'est quand nous avons testé le déploiement sur Vercel.
Une chose que j'avais oubliée, c'est que 11 000 pages, c'est entre 400 et 500 Mb. Et en upload, ça prend du temps. Beaucoup de temps !

Clairement, au début, j'ai cru a un bug. J'ai coupé le déploiement au bout de 39 minutes. Oui, vous avez bien lu, 39 minutes. Et non, ce n’était pas un bug : j'ai testé sur Netlify, via FTP avec une connexion fibre, ça prend bien une bonne quarantaine de minutes !

Le constat est simple. Impossible de faire du full statique sur un très grand nombre de pages. Le statique ne s'y prête pas du tout. D'autant que les futurs sites doivent atteindre le double, voire le triple en quantité de pages.

La régénération incrémentale à la rescousse

C'est alors que la fonctionnalité de régéneration incrementale nous est apparu comme la solution ultime ! Next.js est en effet capable de générer une page sous forme statique lors de la visite. Générer ou régénérer.

On peut utiliser le mode fallback de la fonction getStaticPaths avec la valeur true ou blocking pour afficher une page non générée lors de la phase de build.

Ensuite, vous donnez un tableau vide comme valeur paths de la fonction getStaticPaths pour ne générer aucune page lors du build. Les pages seront générées à la demande en cas de visite.

Résultat, un temps de génération entre deux et quatre minutes pour un site statique hybride de 10 991 articles !

Cerise sur le gâteau, en utilisant le paramètre revalidate, on peut régénérer la page (temps en secondes) sans relancer un build. Cela veut dire qu'en cas de mise à jour de contenu, il n'est pas nécessaire de relancer un build !

La solution retenue

Bien que Nuxt.js ne propose pas de mode hybride comme Next.js pour le moment, nous sommes allés au bout du prototype. Nous avons fait la même application en mode full statique, car nous ne souhaitons pas utiliser le mode SSR (Server Side Rendering). Et comme vous devez vous en douter, nous avons rencontré les mêmes soucis de temps de build et de déploiement.

Nous avons hâte de découvrir plus en détail la version 3 de Nuxt.js avec le moteur Nitro, qui doit normalement permettre un mode hybride.

Donc pour le moment, Next.js est retenu pour la migration des premiers sites. On utilisera le mode hybride avec une génération des pages à la demande en utilisant un fallback en blocking pour être 100% SEO compatible.

L'idée de générer au build les X derniers articles pour accélérer le chargement des articles récents est évoqué. Nous n’excluons pas que certaines pages très anciennes ne soient peut-être jamais visitées et donc jamais générées.

Finalement, pour remplir le périmètre requis pour le projet : le mode prévisualisation, un processus de publication simple et automatique, aucune gestion de serveur et certaines pages accessibles uniquement par des abonnés ; Next.js semble être pour le moment la meilleure solution.

Prototype privé

Le projet est confidentiel et le code privé. Je ne peux pas fournir les données pour faire des tests.

L’émergence de solutions dédiées au déploiement automatisé de sites statiques est principalement l’apanage de sociétés américaines (Netlify, Vercel, Amazon, Microsoft, Digital Ocean, etc.). La bataille a commencé outre-atlantique pour s’arroger les parts de marché, maintenant que Netlify revendique plus d’un million d’utilisateurs. Il existe des hébergeurs en France, mais pas uniquement dédié à du déploiement automatisé de statique sur des CDNs.

Les offres dédiées Jamstack sont un terreau d’innovation, on a vu ainsi arriver les développements atomiques (une URL pour chaque commit), les intégrations au workflow Git avec mise à disposition d’un lien de prévisualisation lors de la soumission d’une modification sur le dépôt Git, l’ajout simplifié de fonctions Lambda, etc.

Matthias et Hubert nous confient que le statique ne représente pas plus de 5% des projets actuellement chez les hébergeurs plus généralistes, et rappellent que le besoin applicatif représente encore leur cœur de leur activité. Les documentations respectives des ces services sont générées avec Hugo et les deux hébergeurs permettent de pousser via Git. L’automatisation et l’expérience utilisateur n’est pas aussi poussée mais le workflow est similaire. On commence néanmoins à réfléchir à l’amélioration de la DX (Developer Experience), via l’amélioration des outils en ligne de commande dans un premier temps.

L’UX n’est cependant pas le premier facteur de choix des entreprises françaises, qui veulent avant tout pouvoir héberger au plus près de leurs utilisateurs quand elles visent le marché français.

Il est difficile de comparer des services spécialisés qui focalisent leurs efforts sur le frein à l’adoption et qui se content de recopier des fichiers statiques. Les services plus génériques qui gèrent de l’infrastructure et des serveurs ont beaucoup d’autres aspects à gérer, ne serait-ce que pour s’assurer de la sécurité de leur infrastructure.

Hubert précise que des fonctionnalités très prisées comme la prévisualisation automatisée de branche Git sont possibles pour des sites statiques chez Clever Cloud à condition de connaître leur API. Ce genre de fonctionnalité est beaucoup plus complexe à mettre en place pour des applications dynamiques.

Matthias confesse que l’importance de la Developer Experience (DX) est grandissante dans la communauté et que le déploiement de sites Jamstack est quelque chose qu’on voit se développer aussi chez des acteurs majeurs comme Amazon Web Services, Microsoft Azure, Digital Ocean ou Cloudflare récemment.

Il n’est pas aisé de pour nos hébergeurs français plus modestes de rivaliser avec les géants du secteur. Force est de constater q’il est plus facile aujourd’hui de déployer un projet statique chez les "gros". Les outils en ligne de commande, les APIs, les outils de monitoring continuent d’être au centre de l’attention des hébergeurs traditionnels, c’est leur cœur de métier. Il y a bien d’autres paramètres à prendre en compte, comme par exemple la qualité et la réactivité d’un support technique à visage humain, qui accompagnent les clients pour s’assurer de répondre à leurs besoins au plus vite.

Les gros acteurs comme AWS ne sont pas non plus à l’abri de pannes, comme on a pu le voir encore recemment.

Chez Clever Cloud, on peut déjà déployer des fonctions en mode PaaS (Platform as a Service), voire des functions as a service (FaaS) avec support de Web Assembly. Lors du développement de sa documentation en mode Jamstack Alwaysdata a pu expérimenté le besoin en fonctions dynamiques comme l’envoi de mail, un besoin qu’il est toujours possible de combler en développant soi-même la fonction manquante ou en se reposant sur des services et des API externes.

Arnaud souligne qu’il est peut-être plus rassurant pour des entreprises de pouvoir stocker leurs fonctions métier dans son Cloud privé afin de maîtriser son environnement. "La valeur ajoutée de notre métier c’est l’accompagnement et la gestion de la complexité" commente Matthias.

Cette complexité est aussi présente chez des acteurs comme AWS, et on est pas à l’abri pour autant d’un certain degré d’enfermement propriétaire lorsqu’on développe son application pour tourner sur ces plate-formes.

Les problématiques de protections des données, la volonté de ne pas dépendre d’entreprises étrangères qui ne sont pas soumises aux mêmes règles fiscales, des choix éthiques liés aux politiques énergétiques sont autant de critères qui entrent de plus en plus dans le processus de décision.

Le déploiement automatisé systématique c’est très pratique dans plein de cas, mais au prix de quel coût énergétique ? Il reste encore aux différents outils (CMS, plate-forme de déploiement) à donner plus de maîtrise (et de métriques) pour nous permettre de pouvoir estimer correctement l’empreinte énergétique de son workflow et de l’infrastructure utilisée.

L'automatisation est une des composantes qui permet de bien travailler en versionnant son projet et en configurant une publication automatique. Cette bonne pratique issue du développement permet de s'assurer que tout le monde peut contribuer et que les changements seront bien publiés. DJ Walker a pris le temps de passer en revue différents services pour vous, c'est parti pour la visite guidée.

Nous vous avons déjà parlé des avantages du déploiement automatique, et plus particulièrement de ceux des sites statiques. L'intégration continue et le déploiement continu sont la stratégie qu'on retrouve le plus souvent quand il s'agit de gérer la publication logicielle. Il existe une multitude d'options pour la mise en place de pipelines CI/CD, avec leurs forces et leurs faiblesses. Quelle est celle qui est faite pour vous ? Dans cet article, nous nous penchons sur cinq services différents avec lesquels vous pouvez développer, tester et déployer votre code.

La configuration est clé

Lors de l'évaluation de l'utilité d'un outil de CI/CD, je veux d'abord connaître la réponse à deux questions :

Quel niveau de contrôle ai-je sur l'environnement qui va générer une nouvelle version de mon application ? Pouvoir configurer l'environnement dans lequel vous allez lancer vos étapes de build est essentiel. J'ai tendance à préférer lancer les étapes de build dans un conteneur Docker avec une image définie par mes soins. Les conteneurs sont devenus le moyen idéal pour faire tourner du code dans un environnement reproductible et isolé.

Comment se configurent les étapes de build ? Vous pourriez simplement lancer vos tâches à l'aide d'un gros script shell ou d'un outil robuste comme make. Ces scripts peuvent toutefois devenir rapidement complexes et difficiles à déboguer. Idéalement, l'enchaînement des tâches est configuré à l'aide d'un langage de configuration qui offre des abstractions plus commodes pour éviter d'avoir à écrire de multiples scripts réutilisables. Bien qu'une syntaxe de configuration intuitive et facile à comprendre soit utile, quel que soit l'outil utilisé vous devrez en apprendre les rudiments, attendez-vous donc à lire leur documentation pour comprendre comment les utiliser.

Peu importe comment fonctionne la configuration, l'important est d'opter pour des outils qui vous permettent de stocker et versionner votre configuration de build dans votre dépôt. Stocker votre configuration présente plusieurs avantages. Lancer le build d'un commit précédent se fera avec la configuration correspondante à cette même période. Vous pouvez travailler votre configuration sur une branche à part, et tirer parti de la portabilité qui découle de l'utilisation de la gestion de version.

CircleCI

CircleCI est un service d'hébergement de CI/CD qui se connecte à votre dépôt et exécute vos étapes de build à chaque nouveau commit. CircleCI peut exécuter vos tâches dans une image Docker, une machine virtuelle Linux, ou une VM MacOS pour vos projets iOS.

La configuration se fait à l'aide d'un fichier .circleci/config.yml dans votre dépôt. Ce fichier indique l'image Docker à utiliser pour votre environnement de build, ainsi que les commandes à exécuter afin de générer, tester et déployer votre application.

CircleCI est le service utilisé par Forestry pour lancer ses tests et déployer son code. Il s'intègre sans problème avec GitHub et Bitbucket.

On aime

Le fait que ce soit à la fois hautement configurable et simple à intégrer avec les projets GitHub.

On est pas super fan

On ne peut pas connecter de projets GitLab à CircleCI pour le moment.

TravisCI

TravisCI est une solution de CI/CD hébergée qui s'intègre avec vos projets GitHub. Les builds TravisCI se configurent dans un fichier .travis.yml présent dans votre dépôt.

Les scripts de build s'exécutent dans un environnement Ubuntu qui peut être configuré à l'aide de commandes shell pendant la phase d'installation de votre build. TravisCI fournit également des abstractions pour installer différents langages de programmation dans votre environnement de build.

On aime

TravisCI promet d'être gratuit à vie pour les projets open source. TravisCI travaille de pair avec Github et peut lancer automatiquement les tests d'intégration lorsqu'une pull request est ouverte.

On est pas super fan

Avec TravisCI, vos builds doivent tourner dans un environnement Ubuntu. Vous pouvez installer Docker dans cet environnement pour récupérer des images, mais c'est la solution la plus verbeuse de toutes. De plus, vous ne pouvez utiliser TravisCI que si vos projets sont hébergés sur GitHub.

Drone

Drone est un serveur de CI/CD écrit en Go. Pour le moment vous devez héberger Drone sur votre serveur, mais une option d'hébergement dédiée est dans les tuyaux. Drone possède un système de plugin qui permet ainsi d'ajouter de nouvelles fonctionnalités.

Configurer un build pour Drone se fait à l'aide d'un fichier .drone.yml. On notera que la syntaxe de configuration de Drone est dérivée de la configuration de docker-compose. Si vous connaissez déjà docker-compose, vous serez en terrain connu avec le langage de configuration de Drone.

On aime

Drone propose des matrices de builds pour permettre de tester simplement votre code dans de multiples configurations, par exemple différentes versions de vos dépendances.

On est pas super fan

Drone est un arrivant relativement récent, et sa documentation aurait besoin d'un peu d'amour.

GitLab CI

Si vous utilisez GitLab pour héberger votre code, vous avez déjà accès aux outils d'intégration continue de GitLab. Tout ce que vous avez à faire est d'ajouter un pipeline de CI à votre projet avec un fichier .gitlab-ci.yml. J'aime le fait de ne pas à avoir à parcourir une interface graphique pour configurer l'intégration continue d'un projet — si vous avez plein de projets et que vous souhaitez gérer leur intégration continue par lots, cette option vous donne des possibilités d'automatisation.

On aime

GitLab CI est compatible avec toutes les versions de GitLab : vous pouvez l'utiliser sur gitlab.com ou sur votre instance GitLab hébergée. Le composant d'intégration continue de GitLab est écrit en Go, il est donc facile à exécuter sur les systèmes d'exploitation majeurs, y compris Windows et MacOS. Vous pouvez même lancer vos tests d'intégration en local sur votre machine !.

On est pas super fan

Forcément pour utiliser GitLab CI, vous devez héberger votre code source avec GitLab, le fait de pouvoir héberger vous-même votre suite logicielle devrait vous rassurer si vous avez peur d'être trop dépendant d'un service tiers.

Jenkins

Jenkins est un serveur d'intégration et de déploiement continu que vous installez et lancer sur votre propre serveur. Le projet Jenkins a débuté en 2004 et aujourd'hui c'est une solution adoptée par les entreprises qui souhaitent posséder leur propre infrastructure de CI.

Jenkins dispose d'une foule de plugins pour l'ajout de fonctionnalités à votre serveur de CI. Les builds sont configurés dans un fichier Jenkinsfile, à partir du moment où vous avez installé le plugin Pipeline recommandé. Comme CircleCI, vous pouvez configurer votre environnement de build à l'aide d'une image Docker, même s'il existe également beaucoup d'autres options.

Jenkins est écrit en Java et est compatible avec les principaux systèmes d'exploitation. Les builds peuvent tourner sous environnement Linux, BSD, MacOS ou Windows.

On aime

Jenkins est totalement libre d'utilisation et open source. Jenkins supporte les plugins et dispose d'une bibliothèque très fournie de par sa relative longévité dans le domaine de l'intégration continue.

Le fait de pouvoir faire tourner ses builds sur n'importe quel système d'exploitation, y compris Windows ou Mac OS, car Jenkins est écrit en Java.

On est pas super fan

Pas grand-chose à redire à ce niveau : Jenkins peut faire à peu près tout ce que vous voulez ! Toutefois, il se peut que les petites équipes n'aient peut-être pas envie de devoir se coltiner la maintenance et l'hébergement de leur propre serveur d'intégration continue.

Choisir l'outil qui vous convient le mieux

La variété d'options pour la mise en place de l'intégration et du déploiement continu a rendu l'automatisation plus accessible que jamais aux développeurs. Les projets open source qui possèdent des prérequis assez simples peuvent tirer parti de l'offre gratuite de TravisCI. Les utilisateurs de GitLab devraient se pencher sur l'utilisation de GitLab CI. Drone est une bonne solution pour ceux qui recherchent une solution simple à héberger soi-même, surtout s'ils apprécient la syntaxe de docker-compose. CircleCI est un bon choix pour ceux qui veulent de la souplesse mais qui ne souhaitent pas héberger leur serveur. Jenkins demandera quelques heures et de l'huile de coude, mais c'est un logiciel capable de faire beaucoup de choses.

En l’espace de quelques années Netlify est devenu un acteur incontournable de l’écosystème Jamstack - ils sont d’ailleurs à l’origine de cette appellation - et des sites statiques. Nous sommes nous-mêmes des utilisateurs plus que satisfaits de ce service et l’article que vous lisez en ce moment est lui-même hébergé sur un de leurs CDN. Netlify c'est le genre de service qui a réussi à faire de ses clients ses premiers ambassadeurs, tant leur produit est plus que recommandable.
Netlify — la contraction de Net et Simplify — a pour but de simplifier la mise en production et de fournir tous les outils modernes nécessaires à des stratégies de déploiement agiles à tout un chacun, sans avoir besoin pour cela d’être un devops confirmé. Ce n'est pas simplement une solution pour héberger vos sites statiques à moindre frais, le passage de Smashing Magazine à une architecture Jamstack hébergée par Netlify a montré que ça pouvait aller bien au delà en faisant appel à différentes APIs et microservices.
Phil Hawksworth, nouvellement en charge des relations avec les développeurs chez Netlify a publié une liste de fonctionnalités disponibles quelle que soit la formule utilisée, même celle entièrement gratuite.

Mais d’abord, comment démarrer simplement

Si vous ne connaissez pas encore ce service, sachez que c'est extrêmement simple d’héberger un site chez Netlify. Nul besoin de connaître toutes les fonctionnalités avancées pour vous lancer.

La manière la plus simple d’héberger un site chez Netlify est de glisser-déposer un dossier contenant vos fichiers dans un navigateur sur https://app.netlify.com.

Vous pouvez aussi déployer directement grâce à l’utilitaire en ligne de commande, mais je prefère vous renvoyer à la documentation pour ça, sinon vous allez croire que j'essaie de caser discrètement des éléments en plus dans ma liste. Bon OK, c'est ce que je faisais, vous m'avez démasqué. Passons maintenant à la liste à proprement parler.

1. Déploiements atomiques avec publication et retour en arrière immédiats

Si vous avez déjà rencontré des problèmes de mise en production ou de déploiement sur des projets de développement web, vous apprécierez grandement cette fonctionnalité.

Chaque génération réussie sur Netlify entraîne le déploiement d’une nouvelle instance de votre site. La publication sur les différents extrémités des nœuds du réseau de CDN de Netlify et l’invalidation de cache se font automatiquement et de manière quasi-instantanée, à tel point que que je trouve inutile de mesurer combien de temps ça prend.

Les déploiements sont immutables. Cela signifie que chaque résultat de déploiement correspond à une version du site qui ne changera jamais. Les mises à jour créent de nouvelles instances du site pour remplacer les versions précédentes (qui sont gentiment remerciées pour leur service et mises au repos, sans être supprimées pour autant). Cela veut dire que vous pouvez revenir à tout moment à une version précédente de votre site d’un simple clic dans l’interface d’administration ou via l’API.

En fait, tout ce que vous pouvez faire dans l’interface d’administration, vous pouvez le faire aussi avec l’API. La documentation de l’API vous explique comment faire tout cela. Je ne compte pas même pas ça comme une fonctionnalité à part entière ici, c'est juste un petit bonus de plus !

2. Notifications et permaliens

Une fois encore, il y a plus d’une fonctionnalité dans cet élément de ma liste, il faudra vous y faire.

Netlify vous permet de configurer des notifications en fonction des différents types d’évènement liés à un déploiement. Vous pouvez définir qui sera informé en cas de nouveau déploiement, ou lorsqu'un déploiement réussit, échoue, est verrouillé ou déverrouillé (je ne vous ai pas dit mais on peut aussi choisir de faire pointer la version du site vers un déploiement en particulier).

Vous pouvez envoyer des notifications par mail ou sur un canal Slack (je suis fan, tous mes projets ont un canal Slack dédié à l’intégration continue). Vous pouvez même décider qu'une notification va déclencher un webhook, ajouter des messages à des commits Git ou commenter sur des pull requests.

Ce qui rend ces notifications encore plus utiles, c'est qu'elles incluent un lien unique vers le déploiement en question. Je vous ai dit que tous les déploiements sont immutables et toujours actifs. Cela signifie que chacun d’eux possède sa propre URL pour qu'on puisse y accéder et voir ce déploiement en particulier.

Avoir des liens uniques pour chaque déploiement c'est énorme. Vous pouvez partager à tout moment n'importe quelle version de votre site avec votre équipe en charge des tests, votre client, ou n'importe qui d’autre. "À quoi ressemblait la version 3.2.14 du site déjà ? Tiens, voilà le lien."

Et cet accès instantané vous est partagé directement à chaque notification.

3. Branches de déploiement et sous-domaines

C’est bien pratique de pouvoir déployer d’autres branches que celle de production. Pouvoir développer de nouvelles fonctionnalités dans des branches dédiées et ensuite pouvoir les tester et les passer en revue sur votre environnement de production, c'est incroyablement puissant.

Netlify vous permet de garder le contrôle sur la façon dont vous déployez. Vous pouvez choisir de déployer uniquement la branche de production, toutes vos branches, ou seulement certaines branches.

Une fois déployée, chaque branche sera accessible depuis un sous-domaine généré en fonction du nom de la branche utilisée. Ça donne un truc comme ça :

ma-branche--mon-site.netlify.com

Grâce à la gestion des DNS de Netlify, vous pouvez aussi choisir d’affecter vos propres sous-domaines à des branches. Vous avez une liberté totale pour définir comment les différentes branches vont pousser du contenu sur les différents sous-domaines de votre site.

4. Tests A/B, Tests A/B avec plusieurs variantes ou tests séparés

Il existe plusieurs variantes et termes pour désigner les tests A/B, Netlify appelle cela le split testing parce que c'est ce que ça fait : découper le trafic de votre site entre les différentes branches de votre choix.

Vous pouvez partager le trafic de votre site en autant de branches que vous le souhaitez et définir le pourcentage de trafic attribué à chacune des branches.

Cette fonctionnalité me bluffe. Elle rend les différents types de tests A/B vraiment trivial à mettre en place. Si vous tirez déjà parti du déploiement de branches, il n'y a pas grand-chose à faire de plus.

Vous me direz que beaucoup d’entreprises peuvent vous vendre des services de tests A/B pour votre site. J'ai été un grand adepte de ces services. Mais la plupart, si ce n'est tous, vont faire ça en magouillant un peu à coup de JavaScript une fois votre site servi et chargé dans le navigateur.

Vu le mal qu'on se donne, en tant de développeurs web, à minimiser l’impact qu'ont les ressources externes en JavaScript sur le rendu de nos sites, c'est vraiment bête de réduire tous ces efforts à néant en introduisant un ralentissement de la performance dans notre rendu.

De plus, si la performance des différentes variantes que nous testons diffère de la production, alors comment pouvons nous bénéficier d’une comparaison vraiment fiable de la performance de ces options ? Les tests sont faussés.

L'approche de Netlify c'est de servir chaque variante de test directement depuis son CDN optimisé. Tous les trucs super intelligents comme la répartition du trafic, les variantes de tests et l’assurance de la consistence d’utilisation se passent au niveau du CDN - sur les nœuds les plus proches possibles de l’utilisateur.

Chaque variante de test est servie et rendue comme sur la "production". Fantastique.

5. Commandes de génération contextuelles

Non seulement vous pouvez déployer différentes branches, mais vous pouvez aussi personnaliser le contenu et les environnements de vos déploiements en fonction de différents contextes comme la préproduction, la qualification et la production.

Il fut un temps où c'était compliqué de mettre en place différents environnements de déploiement pour votre projet. Netlify rend les choses plus simples que je ne l’ai jamais vu. Vous pouvez créer staging.votre-projet.com et testing.votre-projet.com et tout ce que vous voulez à côté de votre www.votre-projet.com simplement à l’aide d’un peu de configuration. Et ils tournent tous sur des environnements identiques, c'est très important pour la fiabilité du développement et la stratégie de déploiement.

Vous pourriez vouloir lancer des commandes de génération légèrement différentes en fonction de l’environnement sur lequel vous déployez, ou générer une fonctionnalité pas encore disponible en production. Vous pouvez faire tout cela en configurant différents contextes de déploiement.

Cela vous permet de faire des choses comme générer la production avec npm run build:prod et une branche de fonctionnalité avec npm run build:ma-fonctionnalite. Pratique !

Cela se paramètre à l’aide d’un fichier de configuration netlify.toml qu'on peut laisser à la racine du projet pour accéder à toutes sortes d’options pour vos déploiements sur Netlify.

Par exemple :