Catégories
Plugin et site web

Smashing Podcast Episode 29 avec Leslie Cohn-Wein – Smashing Magazine

Nous vous demandons à quoi ressemble le dogfood du Jamstack chez Netlify. Pouvez-vous déployer une application entière sur un CDN? Drew McLellan s'entretient avec l'ingénieur du personnel de Netlify, Leslie Cohn-Wein, pour le savoir.

Dans cet épisode, nous vous demandons à quoi cela ressemble de dogfood le Jamstack sur Netlify. Pouvez-vous déployer une application entière sur un CDN? Drew McLellan s'entretient avec l'ingénieur du personnel de Netlify, Leslie Cohn-Wein, pour le savoir.

Afficher les notes

Mise à jour hebdomadaire

Transcription

Photo de Leslie Cohn-WeinDrew McLellan: Elle est une spécialiste du frontend primée originaire d'Austin, mais vivant maintenant à Dallas, au Texas, via un passage à New York. Pendant ce temps, elle a travaillé pour des agences et a créé des sites pour des clients tels que Nintendo, WorldPride et Jerry Seinfeld. Elle est maintenant ingénieur frontend chez Netlify, où, entre autres, elle travaille à la création de l'application que les clients utilisent pour gérer leur service et leurs déploiements. Nous savons donc qu'elle est une ingénieure frontend accomplie, mais saviez-vous que, lorsqu'elle vivait à New York, elle a été juge assistante de cuisine de piment trois années de suite. Et celui-là est en fait vrai. Mes amis fracassants, veuillez accueillir Leslie Cohn-Wein. Salut, Leslie. Comment ça va?

Leslie Cohn-Wein: Je fracasse.

A dessiné: Je voulais vous parler aujourd'hui de la façon dont Netlify mange sa propre nourriture pour chien, pour utiliser cette expression charmante, quand il s'agit de construire sur le Jamstack. Je devrais mettre cela un peu en contexte en disant que jusqu'à il y a quelques mois, nous travaillions ensemble dans la même équipe chez Netlify. Et quand j'y suis arrivé, le processus de développement m'était vraiment étranger, même après 20 ans en tant que développeur. J'ai trouvé que c'était vraiment fascinant et qu'il valait la peine d'être exploré un peu, avec un public plus large. Je devrais probablement souligner que nous en parlons car cela constitue une étude de cas vraiment intéressante et ce n’est pas une grande publicité sponsorisée pour Netlify. Tout le monde devrait vérifier Vercel. Mais je pense qu'il y a beaucoup de choses précieuses qui peuvent être apprises en en discutant, en particulier du point de vue Jamstack. Parce que Netlify est un très grand partisan de l'approche Jamstack et que le service est en quelque sorte offert au client et est construit autour de cette idée de construction de projets Jamstack. Mais le service est également construit en utilisant ces principes lui-même. N'est-ce pas?

Leslie: C'est, oui. Beaucoup de gens considèrent en quelque sorte cette architecture Jamstack comme des sites statiques, mais nous sommes vraiment en train de faire du dogfood ce que signifie créer une application Jamstack avec l'interface Netlify. Parce que c'est une application React qui est une application Jamstack complète que nous déployons Netlify sur Netlify donc… Oui, nous essayons vraiment et repoussons les limites du possible.

A dessiné: Je pense qu'il y a parfois cette idée que Jamstack est idéal pour les sites statiques, comme vous le dites, et l'aspect API entre en jeu si vous voulez envoyer un formulaire à une adresse e-mail et que vous pouvez simplement faire quelque chose de facile comme ça, mais vous pouvez éventuellement créez une application Web entière de cette façon. Mais tu fais ça, n'est-ce pas?

Leslie: Ouais, absolument. Notre application, qui parle spécifiquement de ce que vous voyez si vous vous connectez sur app.netlify.com, est alimentée par… nous avons une API REST interne, mais le frontend, comme je l'ai dit, est purement Jamstack. Nous avons donc notre propre étape de construction, nous surveillons l'application au fur et à mesure qu'elle se construit dans l'application, et nous nous déployons sur notre propre système.

A dessiné: Donc, quand il y a un processus backend impliqué, et qu'il y aura toujours une sorte de niveau de processus backend, vous savez, des données persistantes ou, dans le cas de Netlify, en commençant par un déploiement ou autre, ce backend est juste une sorte de est construit comme une série d'API qui peuvent ensuite être consommées par le frontend?

Leslie: Oui, il existe donc plusieurs modèles différents de la façon dont vous pouvez faire en sorte que cela fonctionne. Dans la plupart des cas, dans notre application, nous utilisons la récupération côté client avec React, non? Ainsi, nous servons une sorte de shell statique de l'application, puis nous récupérons les informations de l'utilisateur à partir de notre API REST interne au moment de la demande. Jamstack est intéressant car il y a certaines choses que vous pouvez préconstruire, et nous essayons de nous en remettre quand nous le pouvons. Et puis, lorsque nous parlerons de certaines des données les plus dynamiques, nous utiliserons cette récupération côté client afin de nous assurer que nous récupérons les données les plus récentes.

A dessiné: Je pense que cela m'a surpris, lorsque j'ai commencé à travailler sur l'application, à quel point ce qui est accompli dans le frontend, en particulier lorsqu'il s'agit d'interagir avec des API externes et d'autres choses. Je sais que lorsque Netlify interagit avec votre fournisseur Git, il va donc sur GitHub et obtient une liste de dépôts, tout se passe entre votre navigateur et GitHub. Et à part peut-être… passer par une fonction sans serveur qui met des secrets sur la demande ou quelque chose de léger comme ça, la plupart de cela se passe simplement d'une manière Jamstack-y. Il ne passe pas par une sorte d’infrastructure principale de backend Netlify. Donc, c’est assez fascinant. Cela va vraiment bien au-delà d'un simple site statique avec quelques appels d'API pour faire de petites choses. C’est cette véritable fonctionnalité de base, n’est-ce pas, qui est mise en œuvre dans le navigateur?

Leslie: Absolument. Cela pousse vraiment, je pense, ce concept de ce qu'est un ingénieur développeur frontend, non? Et c'est quelque chose qui me pousse, en tant qu'ingénieur frontend, à être meilleur et à réfléchir davantage à ce genre de… la couche API, qui n'est pas quelque chose dont j'ai toujours été aussi proche. Je travaille plus dans l'interface utilisateur, les couleurs et les systèmes de conception, et donc c'est vraiment… J'ai trouvé que travailler sur une application Jamstack à grande échelle m'a poussé à être un meilleur développeur.

A dessiné: Être un développeur frontend, ce n'est pas connaître le CSS de fond en comble, bien que cela en fasse partie. Il ne s'agit pas de connaître le HTML de fond en comble, mais cela en fait partie. Il s’égare aussi dans ce territoire qui était traditionnellement réservé à un ingénieur backend, ce qui est assez intéressant. Netlify utilise-t-il un nouveau rendu côté serveur pour

Leslie: Pas que je sache.

A dessiné: Donc, tout est littéralement fait, comme vous le dites, vous servez un shell, puis il est rempli de requêtes adressées à différents points de terminaison d'API pour en quelque sorte le remplir.

Leslie: Exactement.

A dessiné: Et vous dites que c'est une application React?

Leslie: Oui. Oui. Réagir. Nous utilisons React Redux en ce moment, et en ce moment nous sommes PostCSS, mais nous expérimentons également notre architecture CSS.

A dessiné: Ne sommes-nous pas tous? Alors, vous créez l'application dans React, puis vous la déployez sur Netlify?

Leslie: Oui. Peut-être que ma partie préférée de tout ce processus est la magie de Deploy Previews, que nous obtenons via Netlify. Donc, ce qui se passe, c'est que vous … vous travaillez dans GitHub, vous augmentez votre PR. Donc, vous ouvrez votre PR dans GitHub, et cela va créer automatiquement une version de votre aperçu de déploiement de l'application. Nous utilisons donc Deploy Previews de l'application elle-même pour tester, pour nous assurer que tout fonctionne comme il se doit. Nous effectuons nos tests. C'est ce que nous utilisons pour vérifier manuellement lors de l'examen du code. Donc, nous avons en quelque sorte tout ce déploiement continu mis en place directement à partir de GitHub.

Leslie: Et puis l'une des autres choses intéressantes que nous avons mises en place est que nous avons en fait deux sites Netlify différents qui proviennent du même référentiel où réside notre application. Donc, nous avons à la fois notre application, nous avons une instance de Storybook qui contient en quelque sorte nos composants d'interface utilisateur pour l'application. Donc, nous avons à la fois notre application elle-même, nous avons les composants de l'interface utilisateur Storybook, et nous avons essentiellement un site Netlify qui montre notre interface utilisateur Storybook. Et puis, nous avons également un troisième site qui exécute un analyseur de bundle Webpack. C'est donc une interface utilisateur visuelle qui vous donne une arborescence, une visualisation de tous les ensembles d'applications, et nous pouvons en quelque sorte évaluer leur taille, et c'est juste un rappel pour nous de revérifier en quelque sorte. À chaque déploiement de l'application, nous pouvons vérifier et nous assurer que nous ne faisons rien de bizarre avec la taille de notre offre. Ainsi, ces trois sites sont générés en une seule Pull Request de l'application. Ainsi, vous obtiendrez des liens pour prévisualiser, essentiellement vos aperçus de déploiement, à la fois du livre d'histoires de l'application et vers ce profil d'application que nous pourrons vérifier.

A dessiné: Et avec les aperçus de déploiement, cela devient essentiellement votre environnement de préparation, n'est-ce pas?

Leslie: Exactement. Nous n'exécutons pas vraiment un environnement de développement traditionnel, car nous sommes vraiment convaincus que nos aperçus de déploiement sont essentiellement ce qui va être mis en ligne lorsque nous cliquons sur ce bouton de fusion et lancons la version officielle de notre branche principale dans notre application principale. J'adore le fait que nous puissions compter sur Deploy Previews comme environnement de préparation. Nous sommes convaincus que cela correspondra à la production. Nous le construisons avec toutes les variables de production, tout ce qui… les variables d'environnement, tout cela est intégré dans l'aperçu de déploiement. Donc, c'est un peu comme une situation sans souci. Tant que votre aperçu de déploiement fonctionne, vous savez que l'application fonctionnera également.

A dessiné: Et je suppose qu'en tant qu'organisation, si votre aperçu de déploiement ne correspond pas à ce qui est mis en ligne, c'est un problème de service que Netlify souhaite résoudre. Donc, cela fonctionne plutôt bien de ce point de vue. Donc, vous avez passé en revue un aperçu de déploiement, tout est parfait, le PR est fusionné. Que se passe-t-il alors?

Leslie: Ainsi, étant donné que Netlify exécute tout notre déploiement continu, nous l'avons essentiellement tout branché afin que toute fusion dans notre branche principale lancera automatiquement un déploiement de production officiel avec l'application. Donc, généralement, si vous êtes le développeur qui a fusionné votre propre PR, vous entrerez dans le réel … vous devez vous assurer de vérifier vos onglets, car si vous avez un aperçu de déploiement de l'application ouvert et de l'application, vous devez vous assurer que vous voulez généralement suivre dans la vraie application. Alors, vous devez vérifier votre onglet. Mais, oui, dans l'application, vous entrez généralement, vous pouvez regarder les journaux de compilation pour cette fusion que vous venez de lancer, donc tout est automatique. Et dès que ces journaux de construction sont terminés et que le site est en ligne, tout ce que vous avez à faire est d'actualiser la fenêtre de votre navigateur et vous verrez tout ce que vous venez de déployer, qui doit être mis à jour dans l'application.

A dessiné: Et disons que vous détectez un problème une fois qu’il est en ligne, que faites-vous alors?

Leslie: C’est une très bonne question. Et peut-être l'une de mes choses préférées à propos de l'utilisation de Netlify avant même de travailler chez Netlify, c'était comme un peu de magie pour moi, car Netlify a en quelque sorte intégré, ce que nous appelons, des retours en arrière. Donc, essentiellement chaque déploiement sur Netlify… parce que nous utilisons cette architecture Jamstack, chaque déploiement est atomique. Cela signifie donc que vous disposez de l’historique complet de chaque type de déploiement que vous avez effectué sur un site, et que vous pouvez instantanément revenir à l’un de ceux-ci. Donc, si nous déployons accidentellement un bogue ou si quelque chose est cassé, la première chose que nous faisons habituellement est d'arrêter cette intégration continue. Donc, nous allons entrer et c'est juste un bouton dans l'interface utilisateur de Netlify que vous dites, "Arrêtez la publication automatique", et ce que cela fera, c'est arrêter cette connexion avec GitHub. Donc, si mon coéquipier fusionne soudainement aussi son PR, nous n'allons pas réintroduire le bug, rien de tel ne se produira.

Leslie: Donc, nous arrêtons tous ces déploiements automatiques. Et puis tout ce que j'ai à faire est de retourner dans ma liste de déploiements et de trouver le dernier déploiement fonctionnel, d'appuyer sur un bouton de plus qui dit: «Publier celui-ci», et il sera mis en ligne. Donc, ce que cela fait, c'est que cela enlève cette pression pour pouvoir vraiment revenir en arrière, regarder le code, comprendre ce qui s'est réellement passé. Parfois, cela signifie faire un retour Git sur votre branche principale et ramener la branche principale là où elle devait être. Et parfois, c'est un correctif ou vous vous lancez sur une branche et vous le réparez et vous n'avez même pas vraiment besoin de vous soucier de revenir dans Git. Et puis, lorsque vous êtes prêt à revenir en arrière, vous vous assurez que tout fonctionne sur votre aperçu de déploiement de l'application, et vous pouvez simplement réinitialiser tout cela. Ainsi, dès que vous démarrez ces déploiements automatiques, vous êtes de retour en affaires.

A dessiné: Donc, j’ai repéré un problème ici.

Leslie: Oh oh.

A dessiné: Vous utilisez Netlify pour déployer des modifications dans l'application Netlify. Et si le bogue que vous avez déployé vous empêche de revenir en arrière? Que faites-vous alors?

Leslie: J'ai des cauchemars. Non. En fait, nous pouvons gérer cela de plusieurs manières. Ainsi, si nous supprimons l'application et que nous ne pouvons pas utiliser l'interface utilisateur pour suivre ce processus, nos aperçus de déploiement s'exécutent en fait sur notre API de production. Donc, ce que cela signifie, c'est que même si l'application ne fonctionne pas, nous avons toujours ces déploiements atomiques. Donc, si vous avez un lien de GitHub, peut-être d'un ancien ou récent PR, et que vous avez cette URL de déploiement d'aperçu, vous pouvez en fait accéder à l'aperçu de déploiement de l'application et apporter les modifications dont vous avez besoin, revenir en arrière et publier un déploiement plus ancien. à partir de l'aperçu de déploiement. Et cela continue de frapper notre API de production, donc cela affectera toujours l'application, puis cela la réactivera. C'est comme une sorte d'emoji cérébral qui explose, mais c'est une façon de le faire. Nous pourrions également publier un déploiement plus ancien à partir de certains de nos systèmes backend. Nous pourrions demander à nos ingénieurs backend de publier cela pour nous. Ou vous pouvez toujours utiliser Git pour revenir en arrière et essayer de pousser cela vers le haut, mais c'est un peu effrayant parce que vous ne pouvez pas regarder ce que vous faites.

A dessiné: Je suppose que vous avez juste besoin d'un esprit très clair pour gérer cette situation.

Leslie: Ouais.

A dessiné: Mais il est totalement récupérable, ça sonne.

Leslie: Ouais. Eh bien, et une fois que vous avez publié votre déploiement de travail, toute la pression est coupée. C’est vraiment la plus belle partie. Et j'ai trouvé que cela fonctionnait également dans les agences. Être en mesure de revenir en arrière a vraiment sauvé la vie… Cela vous rend également moins préoccupé par la publication de nouveaux changements. Si vous cassez quelque chose, il faut une seconde pour le faire reculer, ce qui correspond très bien au type de mouvement rapide et à faire sortir les choses du modèle.

A dessiné: Absolument. Je pense que ce type de flux de travail complet fonctionne généralement mieux lorsque vous faites face à de très petits changements. Je veux dire, idéalement, vous voulez créer une succursale, mettre en œuvre un petit changement, augmenter un PR, puis le ramener le plus rapidement possible. Ce qui fonctionne évidemment bien pour les ajustements, les corrections de bogues et les petites choses, mais cela ne fonctionne pas aussi bien pour les fonctionnalités majeures lorsque cette fonctionnalité peut prendre des semaines, voire des mois, à partir du moment où elle est prête à être déployée. Comment gérez-vous ce genre de processus?

Leslie: Ouais, c’est une excellente question. Nous avons donc récemment commencé à utiliser un peu plus les indicateurs de fonctionnalité. Avant de parler un peu plus de la façon dont nous faisons cela, je vais parler de ce que nous faisions. Donc, avant d'utiliser les indicateurs de fonctionnalité, je pense que tout le monde est familier avec l'idée de la branche de fonctionnalité de longue durée. Nous les détestons tous, non? Mais nous travaillerions sur nos petits PR. Nous fusionnerions chacun d'entre eux individuellement, après examen du code, dans cette branche de fonctionnalités plus longue. Ainsi, vous auriez simplement toutes vos nouvelles fonctionnalités au même endroit, vous pourriez avoir un aperçu de déploiement avec lequel vous pouvez tester cette nouvelle fonctionnalité. Parfois, ce modèle nécessitait des déploiements coordonnés entre d'autres équipes. Ainsi, lorsque nous étions prêts à dire: «D'accord, cette branche de fonctionnalités, nous sommes prêts à la fusionner et à la mettre en ligne», cela signifiait parfois: «D'accord, vous devez vous assurer que le backend a déjà déployé sa modification», peu importe Le travail d'API que nous effectuons dans notre fonctionnalité est prêt à démarrer. S'il y a des documents sur notre site de documentation qui doivent être mis en ligne en même temps que la fonctionnalité, vous devez en quelque sorte coordonner et appuyer sur les boutons en même temps.

Leslie: Ce modèle est… il a fonctionné pour nous, mais vous avez raison, ce n’était peut-être pas le plus fluide. C'est en fait assez drôle, notre co-fondateur et PDG de Netlify, Matt Biilmann, a en fait lancé notre fonction d'analyse en utilisant ce processus sur scène à Jamstack Conf London l'année dernière. Il a donc utilisé notre fonctionnalité de déploiement de verrouillage pour essentiellement prendre l'aperçu de déploiement de la nouvelle fonctionnalité d'analyse et la publier en direct sur scène. Donc, c'était plutôt cool.

Leslie: Mais, comme vous l’avez dit, c’est… vous avez un peu moins confiance en vous. Tout est encore en quelque sorte caché dans cette Pull Request. Cela devient un peu lourd. Quelqu'un doit approuver cette demande d'extraction finale qui est généralement assez volumineuse. C’est un peu écrasant. Donc, de nos jours, nous utilisons principalement des indicateurs de fonctionnalité. Nous utilisons un service appelé LaunchDarkly, qui nous permet d'encapsuler notre nouvelle interface utilisateur avec ces indicateurs, afin que nous puissions continuer à fusionner du code en continu, même si l'interface utilisateur n'est pas quelque chose que nous voulons que les clients voient. Donc, assurez-vous simplement dans l'environnement de production que votre indicateur de fonctionnalité est désactivé, nous pouvons déployer le code, le fusionner, et personne … en supposant que vous êtes un utilisateur général, vous n'allez pas voir cette nouvelle interface utilisateur.

A dessiné: Ainsi, un indicateur de fonctionnalité est fondamentalement comme un commutateur dans le code qui dit: "Si cette fonctionnalité est activée, utilisez ce nouveau code, sinon utilisez cet ancien code."

Leslie: Exactement.

A dessiné: Cela signifie-t-il que vous obtenez une sorte de base de code désordonnée avec toutes ces fourchettes en place? Comment gérez-vous cela?

Leslie: Oui, je pense que c’est… quiconque utilise des indicateurs de fonctionnalité est probablement habitué à ce genre de bataille: quand nettoyez-vous les indicateurs de fonctionnalité? Combien de temps les laissez-vous là-bas? Nous avons en quelque sorte atterri environ deux semaines après la sortie d'une fonctionnalité majeure, nous avons des rappels. Heureusement, LaunchDarkly a récemment mis en place une fonctionnalité qui informera Slack. Vous pouvez donc le connecter à Slack, et il vous dira simplement: "Hé, votre indicateur de fonctionnalité est … Vous êtes en production depuis deux semaines. Il est temps d’aller vous assurer de nettoyer votre drapeau dans le code. »

Leslie: Donc, nous essayons et nettoyons cela assez rapidement, mais c'est, pendant ce temps entre les deux, il est bon de savoir que le drapeau est toujours là. Même si vous avez publié la fonctionnalité, cela signifie qu'une fois de plus, en un seul clic, vous pouvez entrer et désactiver ce drapeau car il y a un bogue, s'il y a quelque chose qui apparaît. Nous aimons donc les laisser un peu, juste pendant que la fonctionnalité est vraiment en train de cuire, pendant que les gens s'y habituent, pour nous assurer qu'il n'y a pas de problèmes majeurs. Mais ensuite, nous essayons de revenir dans le code et c'est un peu de nettoyage, donc ce n'est pas un processus idéal, mais généralement la suppression de l'indicateur ne prend pas très longtemps, vous supprimez simplement quelques lignes de code.

A dessiné: Donc, je suppose que l'approche la plus simple pour implémenter un indicateur de fonctionnalité pourrait être simplement… comme une variable de configuration dans votre application qui dit: «Cette fonctionnalité est activée ou désactivée», mais vous avez besoin d'un moyen de vous assurer qu'elle est activée pour les bonnes personnes et pour les bonnes personnes. Et je suppose que c’est là qu’un service comme LaunchDarkly entre en jeu, car il faut que… Je veux dire, il faut essentiellement ce qui active et désactive une variable à un niveau extrême, n’est-ce pas?

Leslie: Oui. Oui. C’est exactement ça. Donc, il y a des moyens que nous pourrions avoir, même sans LaunchDarkly, en gros configurer nous-mêmes une variable de configuration que nous gérons en quelque sorte de notre côté. L'une des choses que j'aime à propos de LaunchDarkly, c'est qu'il existe différents environnements. Donc, ce que nous pouvons faire est essentiellement d'activer un indicateur de fonctionnalité pour nos aperçus de déploiement. Ainsi, toute personne qui consulte en interne sur Netlify, un aperçu de déploiement de l'application peut avoir accès à la nouvelle fonctionnalité, peut la tester, mais là encore, dès qu'elle est mise en production en production, cet indicateur est désactivé. Donc, il y a très peu… encore une fois, vous devez en quelque sorte vérifier votre onglet et vous assurer que vous êtes conscient du type de segment dans lequel vous vous trouvez, car vous ne voulez pas vous surprendre et penser que vous avez lancé quelque chose qui vous ne l'avez pas fait, vous devez être un peu prudent là-bas. Mais, en général, cela fonctionne assez bien et LaunchDarkly vous permet également d'effectuer ces déploiements sélectifs. Ainsi, vous pouvez déployer une fonctionnalité sur un certain pourcentage de votre base de code ou sur un segment d'utilisateurs spécifique, des personnes ayant un type de plan spécifique ou un type d'utilisateur spécifique. Ainsi, cela vous permet de contrôler beaucoup plus sur qui vous relâchez.

A dessiné: Ouais. Cela peut être très puissant, je suppose, en particulier avec de nouvelles fonctionnalités ou fonctionnalités dont vous vous attendez peut-être à résoudre un problème. Peut-être que vous améliorez une fonctionnalité pour la rendre plus compréhensible, vous pouvez peut-être l'essayer avec 10% des utilisateurs et voir s'ils rencontrent les mêmes problèmes et…

Leslie: Exactement. C’est aussi un excellent moyen d’obtenir des commentaires, oui.

A dessiné: J'imagine qu'utiliser LaunchDarkly de cette manière, plutôt que de lancer votre propre solution, est en quelque sorte un autre aspect de l'approche Jamstack, n'est-ce pas? Il s'agit simplement d'utiliser une API qui vous donne cette fonctionnalité sans avoir à vous soucier de la façon dont vous la mettez en œuvre vous-même et de la façon de la développer et de la façon de la maintenir et de la conserver afin que vous puissiez simplement l'externaliser, dites: «Oui, nous sommes va utiliser cette API et tout le reste est pris en charge. »

Leslie: Oui. Oui, exactement.

A dessiné: Ainsi, cette approche vous permet de valider essentiellement de petites fonctionnalités en production, mais elles sont simplement cachées derrière l'indicateur. Et puis, lorsque tout est prêt, vous pouvez simplement retourner le drapeau et vous pouvez le réactiver rapidement en cas de problème.

Leslie: Oui, exactement. Cela rend nos lancements un peu moins excitants. Auparavant, vous appuyiez sur ces gros boutons et il y a tout ce code qui est fusionné et vous regardez vos journaux de construction et c'est ce moment d'anticipation. Et maintenant, vous accédez à un appel Zoom, vous cliquez sur un bouton et c'est en direct.

A dessiné: Ouais. Je pense que lors du dernier lancement de fonctionnalité, j'ai travaillé sur un Netlify, nous avons utilisé cette approche. Et cela avait été des semaines de travail pour toute une équipe de personnes, et nous avons eu un appel Zoom pour coordonner la sortie, et tout le monde a confirmé que leurs pièces étaient prêtes. Et puis j'ai retourné l'indicateur de fonctionnalité et l'ai activé pour tous les utilisateurs, et c'était tout.

Leslie: Terminé.

A dessiné: Et c'était fini en quelques minutes et c'était vraiment décevant.

Leslie: Ouais, c’est un peu triste.

A dessiné: Il n'y avait pas de paumes moites, il n'y avait rien, ce qui est bien sûr exactement ce que vous voulez, n'est-ce pas? C'est ainsi que vous savez que vous disposez d'un processus robuste, si activer quelque chose pour tout le monde n'est tout simplement pas un gros problème.

Leslie: Exactement. Et si vous devez revenir en arrière, encore une fois, c’est aussi simple que cela, c’est un clic. Cela soulage une partie de cette pression, de l'anxiété.

A dessiné: Donc, vraisemblablement, je veux dire, tous les changements ne seront pas que des changements frontaux. Parfois, il y aura des changements de backend, et vraisemblablement ils ont leurs propres indicateurs de fonctionnalités aussi bien dans la plupart des systèmes backend. Donc, vous avez également mentionné les documents. Existe-t-il un moyen de coordonner tout cela ensemble? Est-ce que tout le monde retourne son drapeau en même temps? Ou comment ça marche?

Leslie: Ouais. C'est donc un domaine sur lequel nous travaillons activement dans les équipes de Netlify en ce moment, nous travaillons à une solution qui nous permettrait peut-être de tout lier à un seul drapeau dans LaunchDarkly, que tous nos systèmes utilisent , toutes nos bases de code utilisent. Ainsi, dans un monde idéal, nous serions en mesure de retourner un drapeau et de dire: "D'accord, il s'agit de basculer sur le nouveau point de terminaison de l'API qui est également utilisé sur le frontend avec cette nouvelle interface utilisateur qui est enveloppée dans un indicateur de fonctionnalité, ainsi que cette partie du site de documentation, qui contient de nouvelles informations sur cette nouvelle fonctionnalité. » Et vous inversez cet indicateur, il a un impact sur tous ces référentiels. Nous n’en sommes pas encore tout à fait là. Nous travaillons là-dessus, mais je suis ravi de voir si nous sommes en mesure de coordonner et de travailler tout cela.

A dessiné: Netlify, en tant que service, est en quelque sorte adapté aux chantiers de cette manière. Le travail que vous et votre équipe faites avec le produit a-t-il réellement influencé le développement du produit?

Leslie: Je dirais que c’est définitivement le cas. Tout le monde dit toujours que vous n'êtes pas votre utilisateur, ce qui, je pense, est vrai la plupart du temps, sauf parfois lorsque vous êtes votre utilisateur. Ce qui est amusant chez Netlify car je pense que la plupart des personnes de l'équipe frontend en particulier sont des personnes qui ont déjà utilisé Netlify en tant que produit. Et certainement parce que nous utilisons Netlify pour déployer Netlify, nous sommes confrontés aux mêmes défis que je pense que certains de nos utilisateurs font. Donc, d’une certaine manière, si nous rencontrons un problème, nous essaierons de le signaler au reste de l’entreprise. Nous le mentionnerons lors d'un appel d'ingénierie ou nous ferons appel à notre directeur technique et lui dirons: «Hé, c'est quelque chose avec lequel nous luttons. Y a-t-il quelque chose que nous pourrions intégrer au produit qui faciliterait cela pour nous et pour tous nos utilisateurs qui déploient des choses similaires que nous sommes? » C’est donc une position unique, mais c’est amusant de voir comment la feuille de route du produit est développée.

A dessiné: Je suppose qu'il y a probablement peu de gens qui utilisent Netlify aussi intensivement que Netlify lui-même.

Leslie: Ouais. Ouais. Je pense que c’est à peu près correct. Je regarde Netlify à la fois quand je le construis et quand je le déploie, donc je suis assez familier avec lui.

A dessiné: Et puis le week-end, vous travaillez sur un projet parallèle et vous vous retrouvez à nouveau dans Netlify.

Leslie: Ouais. C’est en fait très vrai. Ouais. Oui. Oui en effet.

A dessiné: Avez-vous des exemples de la façon dont la direction produit a été influencée par le travail effectué par l’équipe?

Leslie: Ouais. Nous avons donc récemment lancé un nouveau type de tableau de bord de destination pour l'application que nous appelons la présentation de l'équipe. Donc, avant, lorsque vous vous connectiez à Netlify, vous arriviez sur la page du site, qui serait simplement une longue liste de vos sites. Et nous voulions donner aux gens un peu plus une zone de contrôle de mission où ils peuvent en quelque sorte voir beaucoup d'informations importantes en un coup d'œil, accéder aux choses qui vont leur être les plus utiles. Et donc, c'était une nouvelle fonctionnalité que nous avons créée. Dans l'itération initiale, nous essayons de le sortir rapidement, nous avons une petite carte sur cette interface utilisateur qui renvoie à vos dernières versions. Il vous montre que toute construction de toute votre équipe devrait apparaître dans cette carte.

Leslie: Et au début, nous n'avions en fait pas lié ceux-ci à la construction… le journal d'affichage lui-même. Donc, c'était juste une liste où vous pouviez la vérifier. Vous pouvez cliquer sur la page des constructions pour obtenir une sorte de vue similaire. Mais je travaillais en fait sur quelque chose ce week-end, un site personnel, et j'avais activé cette vue d'ensemble de l'équipe et j'étais ennuyé parce que j'ai réalisé que je me suis connecté à Netlify et que je voulais aller voir cette version qui se passait de mon projet, et je ne pouvais pas simplement cliquer dessus et y aller directement. J'ai dû cliquer sur la page des versions, puis cliquer à nouveau. Donc, le lendemain au travail, je suis entré et j'ai ajouté ce changement et lié ces versions parce que cela me dérangeait. C'était donc un exemple de la simple prise de conscience, en utilisant le produit, qu'il y avait une très petite possibilité de l'améliorer. Et nous avons pris ça.

Leslie: Mais nous avons également d'autres exemples. Probablement un peu plus percutant. La première est que nous avons en quelque sorte ajouté cette fonctionnalité de détection de formulaire. Donc, un peu de contexte, si vous n'êtes pas familier, les formulaires Netlify sont une fonctionnalité de Netlify qui vous permet de créer un formulaire frontal. Et Netlify fait en quelque sorte tout le travail backend de gestion des soumissions. C'est un peu comme votre base de données pour votre formulaire que vous avez créée sur votre frontend. Cela signifie que vous n’avez pas besoin d’écrire de code côté serveur ou beaucoup de JavaScript supplémentaire pour gérer les soumissions de formulaires. Vraiment tous les sites que vous avez déployés sur Netlify, au fur et à mesure que votre build se déroule, nos robots de build analysent le code HTML de votre site au moment du déploiement pour détecter essentiellement si vous avez un formulaire Netlify auquel Netlify doit faire attention et gérer. Et cette détection de formulaire, recherchée par le robot de compilation, est activée par défaut.

Leslie: Mais ce que cela signifie, c'est que, comme vous pouvez l'imaginer, cela consomme un peu de temps de construction car les robots doivent aller chercher cette étape supplémentaire. Donc, l'application Netlify elle-même, en fait, nous n'utilisons pas, nous n'avons aucun formulaire Netlify sur l'application pour le moment. Donc, c'est une étape qui ajoute un peu à notre temps de construction, mais cela ne doit pas nécessairement se produire. Ainsi, Netlify a en fait construit une nouvelle fonctionnalité qui permet à tout utilisateur de désactiver cette détection de formulaire. Cela signifie que vous pouvez désactiver ce paramètre dans les paramètres de votre site, les robots de compilation se rendent compte qu'ils n'ont rien à rechercher, ce qui vous permet d'économiser un peu de temps de traitement supplémentaire dans les versions.

A dessiné: Je suppose que c'est génial en termes de productivité, car les choses se terminent un peu plus vite.

Leslie: Exactement.

A dessiné: Mais aussi, en tant que service avec compteur, vous permet de tirer le meilleur parti du type d’allocations dont vous disposez.

Leslie: Oui. Exactement. Et donc, c'est quelque chose que nous avons également entendu de la part de certains de nos utilisateurs et clients, et c'est quelque chose que nous avons également remarqué. C'était: «Eh bien, nous n'avons pas besoin de cette étape supplémentaire dans notre propre produit. Alors, y a-t-il un moyen, quelque chose que nous pourrions donner à tous nos utilisateurs pour rendre la vie de chacun un peu plus facile, permettre à chacun de construire un peu plus vite s'il n'utilise pas cette fonctionnalité? »

A dessiné: Y a-t-il un danger… Je veux dire, vous dites que vous n'êtes pas votre utilisateur, mais avec Netlify, vous êtes souvent votre utilisateur. Y a-t-il un risque que, avec l'intensité avec laquelle vous utilisez le produit, vous puissiez oublier le type d'utilisateurs qui ne l'utilisent que très légèrement et que tout devienne trop complexe et trop avancé, et que cela devienne simplement très difficile à obtenir commencé avec?

Leslie: C’est une excellente question. Nous avons également vraiment développé notre fonction de recherche d'utilisateurs chez Netlify et notre fonction de science des données, et je pense que dans l'ensemble, nous leur faisons beaucoup plus confiance que mon expérience anecdotique d'utilisation et de déploiement de l'application. Mais je pense que toutes ces données sont réunies pour nous permettre d'avoir une meilleure idée de qui utilise Netlify, de quel type d'utilisateur parlons-nous? Il y a des gens avec différents types de besoins. Nous avons des gens dans nos équipes de démarrage qui gèrent des blogs et des sites personnels, et nous avons également de grandes entreprises, qui lancent de grandes campagnes marketing et de grandes applications Web, pas si différentes de Netlify lui-même. C’est donc passionnant de voir la base d’utilisateurs grandir, de réfléchir à tous ces cas d’utilisation et de comprendre comment nous pouvons répondre à tous ces utilisateurs. Et certainement en utilisant davantage nos fonctionnalités de recherche pour comprendre qui sont ces utilisateurs, pas seulement notre expérience interne.

A dessiné: Parlez-moi, Leslie, du service de capture d'écran que Netlify a mis en place? Parce que j'ai trouvé ça vraiment intéressant.

Leslie: Ouais. Dans l'interface utilisateur, nous avons… lorsque vous déployez un site sur Netlify, dans l'interface utilisateur, nous avons une petite capture d'écran qui vous montre généralement à quoi ressemble la page d'accueil du site que vous ressentez. C'est en fait drôle que nous en ayons parlé, car j'écoutais Chris Coyier son épisode sur Serverless il n'y a pas si longtemps, et il parlait également de la façon dont ils font des captures d'écran dans CodePen, ce qui n'est en fait pas si différent de la façon dont Netlify le fait. Mais fondamentalement, nous exécutons Puppeteer pour capturer cette capture d'écran du site de l'utilisateur, et la façon dont tout est exécuté est qu'il est configuré avec une fonction Netlify. Donc, c'est encore une fois, un exemple de nous en dogfood notre propre produit. Donc, nous utilisons essentiellement ce point de terminaison qui est une fonction Netlify dans notre propre application pour renvoyer l'URL de cette image de la capture d'écran, que nous pouvons ensuite servir dans l'application.

A dessiné: So Netlify functions are Netlify’s implementation of a Serverless function, aren’t they? Where you basically just drop a JavaScript file into a designated folder as part of your source, and then that becomes available to be executed as a cloud function.

Leslie: Yes, exactly.

Drew: Super smart, isn’t it?

Leslie: Ouais. It’s brilliant. This is one of those areas where it really pushes me as a frontend engineer to really be more of this JavaScript or Serverless engineer, and think a little bit more about how you’re basically writing like an internal API end point for yourself when you create one of these Serverless functions. So, it’s exciting because there’s so much you can do, but that can make it a little intimidating also because there’s so much you can do.

Drew: I sort of find it funny how it’s like… that’s seemingly a core piece of functionality for Netlify, displaying images alongside your site of what it looks like, yet, it’s just implemented with another Netlify feature. And you wonder how far you go before it all disappears in on itself in a big cloud of smoke.

Leslie: Ouais. Ouais.

Drew: This sounds like a really nice way to be working, and a very modern way to we’re working, but it can’t be without its challenges, can it?

Leslie: Absolutely not. I think I’ve spoken a little bit about what it means sort of as a frontend engineer pushing into sort of some new areas just for me to be thinking about in terms of Serverless and how can we leverage this in the product? I think for me, mastering that sort of back of the frontend side has been an exciting challenge, but certainly there’s a lot to learn there. An example of that in our app right now, is that we use Cypress for end-to-end testing of some of the critical flows in our app, and right now we have that set up so that the Cypress end-to-end tests are running on our Deploy Previews in Pull Requests using a GitHub action. So, we use the GitHub action to run those Cyprus tests against the Deploy Previews of the app.

Leslie: Which is really cool, but there’s probably a better way to do this than actually using a GitHub action. I actually think that we could use a Netlify Serverless function because those can be triggered on certain events, like a deploy succeeded event. So, there’s an opportunity there for us to actually leverage again, Netlify, a little bit more, instead of relying on some of these other tools that maybe we’re more familiar with or more comfortable using. So, in terms of challenges, I think it’s opening our minds to what this sort of new model of development allows us to do and trying to leverage it.

Drew: Yes, there’s so many different ways on there to… with the tooling that’s available, to be able to attack a particular problem. At Smashing, we probably shouldn’t say there’s more than one way to skin a cat.

Leslie: Yikes.

Drew: What’s interesting about the workflow as well, is that it’s really intensively Git based, which I think suits… it’s really developer friendly, isn’t it? As a frontend engineer, something that’s Git based kind of just feels like home. So, is that all great or are there any problems that come in with that?

Leslie: I think as a developer Git is wonderful. I think in general it solves big, big problems and I’m very happy to have it. But, because we rely on it so heavily and as our internal team has grown as well, you end up having the same problems that Git has when you’re talking about Netlify in this workflow, right? So, you end up with a bug on your main branch, yes, it’s really easy to roll back the app itself, we talked through what that looks like, and then go in the code and fix it. But what if someone else on your team is working from a broken version of that main branch? Everyone’s going to have to rebase, everyone’s going to have to communicate, or at least be aware of what happened. And so, it’s not so much a Jamstack problem or a Netlify problem, but more of just the age old, how do you coordinate on a team of human beings and how do you use the technology to do that properly?

Drew: And of course, as you add more tools and infrastructure in around what you’re doing, then you’ve got the problem of everything taking a long time to run. I mean, you mentioned Cypress is one thing. I know Cypress is a real headache with the amount of time those end-to-end tests can take to run. Is there other challenges around that growing build time?

Leslie: Yeah, I think that’s one of the other things that Jamstack… You’re introducing this build time, which for developers is not great. I always try and think about it as what I sort of eat up in that build time, my users are saving in the performance of what they’re getting. So, I always try to keep that in mind when I’m frustrated about how long something is taking to build, but certainly I think that’s an area of opportunity and a challenge, is figuring out how to keep those build times fast, how to make sure that we can deploy as quickly as possible. Some of it is this sort of tension between wanting to run all your tests, wanting to make sure that you don’t deploy a build if a test fails, but at the same time, then you’ve got to run all those tests.

Leslie: So, it’s this constant sort of back and forth between wanting to keep the build times fast, while also making sure that you feel like you’re doing your due diligence before you actually deploy something. And we’re playing around with some ideas here as well about potentially moving our Cypress tests to be running against production and having some alerting setup that would let us know after the fact, if something had failed. Which is sort of an interesting model, too. So yeah, stay tuned.

Drew: I certainly know that, yes, the dangers of growing build times, just from a developer point of view, from productivity point of view, that if something takes too long to run, you context switch, you start working on something else, and then it just… you lose all the momentum, and maybe you forget to go back and find out whether the build succeeded because you’re then so far into the next task.

Leslie: Yeah, definitely.

Drew: So, I guess this isn’t the ultimate workflow as it stands at the moment. There must be further we can take it. What sort of opportunities might lie ahead for this way of working?

Leslie: Ouais. So, I think for me, and Netlify in particular, is sort of the thought of collaboration for larger teams. I mean, I know a lot of developers are sort of… have used Netlify for side projects and other things that they’re working on, on their own, but thinking about how it can be leveraged on larger teams, like mine. As we get larger and we’re growing, more of us are in the app, more of us are using Netlify to deploy our own services, and so everything from even more robust audit logs so that you can go and see who changed this site setting, or who was the last person to deploy something. I think having the ability to organize your sites within your Netlify dashboard, even knowing… assigning someone to a build is sort of an interesting idea to me. Could that be helpful if I knew that my teammate had worked on this build, but then I realized they had to roll it back? And maybe I’m just aware of who’s managing that process could be a really useful thing within Netlify itself.

Leslie: And one thing that I’ve seen sort of thrown around a little bit is perhaps the ability to link to a specific log line in build log. So, for debugging, if you have your build log of your Deploy Preview, and there’s an error that got thrown, either from Netlify or from your own code, it’d be nice to be able to link directly to that log line. So, that’s sort of a fun, small improvement that I’ve been thinking about a bit. And that’s not even to say we have some new features at Netlify as well, that are pretty exciting. Edge handlers and background functions. I’m still trying to wrap my head around what they all do and exactly how they work, but I know that edge handlers are going to give us the opportunity to do some things with localized content, which could be… have some interesting implications for features we could build in the Netlify app as well.

Drew: Yeah, it’s really exciting. I think there are all sorts of people within the Jamstack community who are pushing this the whole thing forward. But I think Netlify, as a service, is one that is really behind it and doing exciting things. And, as I say, I didn’t want this to be a big ad for Netlify, but I think you and I both really love the service, so it is exciting to talk about isn’t it? If listeners want to get more engaged with learning how to build Jamstack sites or want to get more into this ecosystem, is there a good place to go to learn this stuff?

Leslie: I feel like it’s exploding right now. I would certainly point you to the Netlify blog. We try and post some tips and tricks there and announce new features as well. I would give a shout out too, to Learn With Jason. My coworker, Jason Lengstorf does sort of a live stream show, and he does cover… he covers a range of topics, but does some Jamstack specific ones as well. And it’s a fun hour of live coding and picking that out. Twitter, I think, is huge, too. So check out Jamstack hashtag.

Drew: Good advice. So, we’ve been learning all about how Netlify builds Netlify on Netlify. What have you been learning about, Leslie?

Leslie: Oh, that’s always a big question. I mentioned Cypress before, we’ve been working through some of our processes around exactly how we want to run our end-to-end tests, and so I would say that, in general, I’ve been thinking a lot about that workflow. So, less about the technology itself, but more about what workflows exist for end-to-end testing on the frontend, and what makes sense sort of in this Jamstack model. So, that’s been a fun sort of side tangent. And then, on the CSS side of things, we talked a bit about CSS architecture, and I’m starting to get my hands dirty with Tailwind, which has been a fun and exciting and lots to learn and lots of class names to memorize and… Yeah.

Drew: That’s exciting stuff. If you, dear listener, would like to hear more from Leslie, you can find her on Twitter where she’s @lesliecdubs, and her personal site is leslie.dev. Thanks for joining us today, Leslie, did you have any parting words?

Leslie: Have a great day?

Smashing Editorial(il)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *