Podcast Episode 29 avec Leslie CohnWein

Dans cet épisode, nous 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

Drew McLellan: Elle est une récompense spécialiste du frontend gagnant 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 allez-vous?

Leslie Cohn-Wein: Je fracasse.

Drew: Je voulais vous parler aujourd'hui de la façon dont Netlify mange sa propre nourriture pour chien, pour utiliser ce charmant expression, lorsqu'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: Oui, 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 l'essayons vraiment et repoussons les limites de ce qui est possible.

Drew: 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 souhaitez envoyer un formulaire à une adresse e-mail et que vous pouvez simplement faire quelque chose de simple comme ça, mais vous pouvez éventuellement créer une application Web entière qui façon. Mais tu fais ça, n'est-ce pas?

Leslie: Oui, 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. Donc, nous avons 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.

Drew: Donc, quand il y a un processus backend impliqué, et il y a toujours être 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 en quelque sorte construit comme une série d'API qui peuvent ensuite être consommées par le

Leslie: Oui, il y a donc quelques modèles différents de la façon dont vous pouvez faire ce travail. 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, quand nous parlons de certaines des données les plus dynamiques, nous utiliserons cette récupération côté client afin de nous assurer que nous tirons les données les plus récentes.

Drew: Je pense m'a surpris, lorsque j'ai commencé à travailler sur l'application, à quel point ce qui est réalisé 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 davantage 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é à devenir un meilleur développeur.

Drew: Être un développeur frontend ne connaît pas 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.

Drew: Donc, tout est littéralement fait, comme vous le dites, vous servez un shell

Leslie: Exactement.

Drew: 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.

Drew: N'est-ce pas tout? Donc, vous construisez l'application dans React et ensuite 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 mis en place est que nous avons en fait quelques sites Netlify différents qui tirent 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 de contes de l'application et vers ce profil d'application pour que nous puissions les consulter. votre environnement de mise en scène, 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.

Drew: Et je suppose, en tant qu'organisation, si votre aperçu de déploiement ne correspond pas à ce qui est mis en ligne, alors c'est un problème de service que Netlify veut 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: Donc, parce que Netlify exécute tout notre déploiement continu, essentiellement nous avons tout branché de sorte 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 compilation 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 que tout ce que vous venez de déployer devrait être mis à jour dans l'application.

Drew: Et disons que vous décelez un problème une fois qu'il est mis 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 aussi soudainement ses relations publiques, nous n'allons pas réintroduire le bogue, 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. Donc, dès que vous démarrez ces déploiements automatiques, vous êtes de retour dans les affaires.

Drew: Donc, j'ai repéré un problème ici.

Leslie: Oh oh. [19659009] Drew: 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.

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

Leslie: Ouais.

Drew: Mais c'est totalement récupérable, ça en a l'air.

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, cela prend une seconde pour le faire reculer, ce qui correspond très bien au type de mouvement rapide et de sortie du modèle.

Drew: Certainement. 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: Oui, 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, que ce n'était peut-être pas le plus simple. 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 ne verrez pas cette nouvelle interface utilisateur.

Drew: 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.

Drew: 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: Ouais, je pense que c'est… quiconque utilise des indicateurs de fonctionnalité est probablement habitué à ce genre de bataille pour savoir quand nettoyer 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 que vous nettoyez votre drapeau dans le code. »

Leslie: Donc, nous essayons de le nettoyer assez rapidement, mais il est, entre les deux, il c'est bien 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.

Drew: 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, vous avez besoin un moyen de s'assurer qu'il est activé pour les bonnes personnes et désactivé pour les bonnes personnes. Et je suppose que c'est là qu'intervient un service comme LaunchDarkly, parce qu'il faut ça… Je veux dire, il faut fondamentalement ce qui allume et éteint 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. Donc, cela vous permet beaucoup plus de contrôle sur les destinataires.

Drew: 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.

Drew: J'imagine que l'utilisation de 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.

Drew: Donc, cette approche vous permet de consacrer essentiellement de petites fonctionnalités à la production, mais elles sont simplement cachées derrière le drapeau. Et puis, quand tout est prêt, vous pouvez simplement retourner le drapeau et vous pouvez le retourner rapidement si quelque chose ne va pas.

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 lancez un appel Zoom, vous cliquez sur un bouton et c'est en direct.

Drew: 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é.

Drew: Et c'était fini en quelques minutes et c'était vraiment anticlimactic.

Leslie: Ouais, c'est un peu triste.

Drew: 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 avez 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é.

Drew: 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 faire fonctionner tout cela.

Drew: Netlify, en tant que service, est en quelque sorte adapté à chantiers de cette manière. Le travail que vous et votre équipe faites en utilisant le produit a-t-il en fait influencé le développement du produit?

Leslie: Je dirais que oui. 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? » Donc, c'est en quelque sorte une position unique, mais c'est amusant de voir comment la feuille de route du produit est développée.

Drew: Je suppose qu'il y a probablement peu de gens qui utilisent Netlify aussi intensément que Netlify le fait 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 le connais assez bien.

Drew: Et puis le week-end, vous travaillez sur un projet parallèle et vous trouvez de retour dans Netlify.

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

Drew: Avez-vous des exemples de la façon dont la direction du produit a été influencée par le travail de 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 tout build 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 build… 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 cela.

Leslie: Mais nous avons aussi 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, que le robot de compilation recherche, 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 compilation parce que les bots 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 construction se rendent compte qu'ils n'ont rien à rechercher, ce qui vous fait gagner un peu de temps de traitement supplémentaire dans les versions.

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

Leslie: Exactement.

Drew: Mais aussi, en tant que service mesuré, vous permet d'en tirer plus du genre d'allocations que vous avez.

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, pour que chacun construise un peu plus vite s'il n'utilise pas cette fonctionnalité? »

Drew: Y at-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.

Drew: 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, essentiellement, nous utilisons 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.

Drew: Les fonctions Netlify sont l'implémentation par Netlify d'une fonction Serverless, n'est-ce pas? Là où vous déposez simplement un fichier JavaScript dans un dossier désigné dans le cadre de votre source, puis qui devient disponible pour être exécuté en tant que fonction cloud.

Leslie: Oui, exactement.

Drew: ] Super intelligent, n'est-ce pas?

Leslie: Ouais. C'est brilliant. C'est l'un de ces domaines où cela me pousse vraiment en tant qu'ingénieur frontend à vraiment être plus cet ingénieur JavaScript ou Serverless, et à réfléchir un peu plus à la façon dont vous écrivez fondamentalement comme un point final d'API interne pour vous-même lorsque vous créez l'une de ces fonctions sans serveur. Donc, c'est excitant parce qu'il y a tellement de choses que vous pouvez faire, mais cela peut le rendre un peu intimidant aussi parce qu'il y a tellement de choses que vous pouvez faire.

Drew: Je trouve ça drôle comme c'est comme … c'est apparemment un élément de base de la fonctionnalité de Netlify, affichant des images à côté de votre site de ce à quoi il ressemble, mais il vient d'être implémenté avec une autre fonctionnalité de Netlify. Et vous vous demandez jusqu'où vous allez avant que tout ne disparaisse sur lui-même dans un gros nuage de fumée.

Leslie: Ouais. Ouais.

Drew: Cela semble être une très belle façon de travailler, et une façon très moderne de travailler, mais cela ne peut pas se passer de défis, n'est-ce pas?

Leslie: Absolument pas. Je pense avoir parlé un peu de ce que cela signifie en tant qu'ingénieur frontend qui pousse dans une sorte de nouveaux domaines juste pour que je pense en termes de Serverless et comment pouvons-nous en tirer parti dans le produit? Je pense que pour moi, maîtriser ce genre d’arrière du front-end a été un défi passionnant, mais il y a certainement beaucoup à apprendre là-bas. Un exemple de cela dans notre application en ce moment, est que nous utilisons Cypress pour tester de bout en bout certains des flux critiques de notre application, et pour le moment, nous l'avons configuré pour que les tests de bout en bout de Cypress s'exécutent sur nos Deploy Previews dans Pull Requests à l'aide d'une action GitHub. Donc, nous utilisons l'action GitHub pour exécuter ces tests de Chypre sur les aperçus de déploiement de l'application.

Leslie: Ce qui est vraiment cool, mais il y a probablement une meilleure façon de faire cela que d'utiliser réellement une action GitHub. Je pense en fait que nous pourrions utiliser une fonction Netlify Serverless parce que celles-ci peuvent être déclenchées sur certains événements, comme un événement de déploiement réussi. Il existe donc une opportunité pour nous d'exploiter à nouveau Netlify, un peu plus, au lieu de nous fier à certains de ces autres outils avec lesquels nous sommes peut-être plus familiers ou plus à l'aise. Donc, en termes de défis, je pense que cela nous ouvre l'esprit sur ce que ce type de nouveau modèle de développement nous permet de faire et essaie d'en tirer parti.

Drew: Oui, il y a tellement de façons différentes de le faire. … Avec l'outillage disponible, pour pouvoir attaquer un problème particulier. Chez Smashing, nous ne devrions probablement pas dire qu'il y a plus d'une façon d'écorcher un chat.

Leslie: Yikes.

Drew: Ce qui est intéressant à propos du flux de travail aussi, c'est qu'il est vraiment intensif Basé sur Git, ce qui, je pense, convient… c'est vraiment convivial pour les développeurs, n'est-ce pas? En tant qu'ingénieur frontend, quelque chose qui est basé sur Git se sent comme à la maison. Alors, est-ce que tout est génial ou y a-t-il des problèmes avec ça?

Leslie: Je pense qu'en tant que développeur, Git est merveilleux. Je pense qu'en général, cela résout de gros, gros problèmes et je suis très heureux de l'avoir. Mais, parce que nous comptons tellement dessus et que notre équipe interne a également grandi, vous finissez par avoir les mêmes problèmes que Git lorsque vous parlez de Netlify dans ce flux de travail, n'est-ce pas? Donc, vous vous retrouvez avec un bogue sur votre branche principale, oui, il est vraiment facile de restaurer l'application elle-même, nous avons expliqué à quoi cela ressemble, puis entrez dans le code et corrigez-le. Mais que se passe-t-il si quelqu'un d'autre de votre équipe travaille à partir d'une version cassée de cette branche principale? Tout le monde va devoir rebaser, tout le monde devra communiquer, ou du moins être conscient de ce qui s'est passé. Et donc, ce n'est pas tant un problème Jamstack ou un problème Netlify, mais plutôt un problème séculaire, comment coordonnez-vous une équipe d'êtres humains et comment utilisez-vous la technologie pour le faire correctement?

Drew: Et bien sûr, au fur et à mesure que vous ajoutez plus d'outils et d'infrastructures autour de ce que vous faites, vous avez le problème de tout mettre du temps à fonctionner. Je veux dire, vous avez mentionné que Cypress est une chose. Je sais que Cypress est un vrai casse-tête avec le temps que ces tests de bout en bout peuvent prendre. Y a-t-il d'autres défis autour de ce temps de construction croissant?

Leslie: Oui, je pense que c'est l'une des autres choses que Jamstack… Vous introduisez ce temps de construction, ce qui pour les développeurs n'est pas génial. J'essaie toujours de penser à cela comme à ce que je mange à ce moment-là, mes utilisateurs économisent dans les performances de ce qu'ils obtiennent. Donc, j'essaie toujours de garder cela à l'esprit lorsque je suis frustré par le temps que prend quelque chose à construire, mais je pense certainement que c'est un domaine d'opportunité et un défi, c'est de trouver comment garder ces temps de construction rapides, comment assurez-vous que nous pouvons déployer le plus rapidement possible. C'est en partie ce genre de tension entre vouloir exécuter tous vos tests, vouloir vous assurer de ne pas déployer une compilation si un test échoue, mais en même temps, vous devez exécuter tous ces tests.

Leslie: Donc, c'est ce genre de va-et-vient constant entre vouloir garder les temps de construction rapides, tout en s'assurant que vous avez l'impression de faire votre diligence raisonnable avant de déployer réellement quelque chose. Et nous jouons ici également avec quelques idées sur la possibilité de déplacer nos tests Cypress contre la production et d'avoir une configuration d'alerte qui nous permettrait de savoir après coup, si quelque chose avait échoué. Ce qui est aussi un modèle intéressant. Alors oui, restez à l'écoute.

Drew: Je sais certainement que, oui, les dangers de l'augmentation des temps de construction, juste du point de vue du développeur, du point de vue de la productivité, que si quelque chose prend trop de temps à fonctionner , vous changez de contexte, vous commencez à travailler sur autre chose, et ensuite… vous perdez tout votre élan, et peut-être que vous oubliez de revenir en arrière et de savoir si la construction a réussi parce que vous êtes alors si loin dans la tâche suivante. [19659008] Leslie: Oui, certainement.

Drew: Donc, je suppose que ce n'est pas le flux de travail ultime tel qu'il se présente actuellement. Il faut que nous puissions aller plus loin. Quelle sorte d'opportunités pourrait se présenter pour cette façon de travailler?

Leslie: Ouais. Donc, je pense que pour moi, et Netlify en particulier, c'est une sorte de pensée de collaboration pour des équipes plus importantes. Je veux dire, je sais que beaucoup de développeurs sont en quelque sorte… ont utilisé Netlify pour des projets parallèles et d'autres choses sur lesquels ils travaillent seuls, mais en réfléchissant à la façon dont cela peut être exploité sur des équipes plus importantes, comme la mienne. Au fur et à mesure que nous grandissons et que nous grandissons, nous sommes de plus en plus nombreux dans l'application, nous sommes de plus en plus nombreux à utiliser Netlify pour déployer nos propres services, et donc tout à partir de journaux d'audit encore plus robustes afin que vous puissiez voir qui a changé ce site ou qui a été la dernière personne à déployer quelque chose. Je pense qu'avoir la capacité d'organiser vos sites dans votre tableau de bord Netlify, même en sachant… affecter quelqu'un à une construction est une sorte d'idée intéressante pour moi. Cela pourrait-il être utile si je savais que mon coéquipier avait travaillé sur cette version, mais que je réalisais ensuite qu'ils devaient l'annuler? Et peut-être que je suis juste conscient de qui gère ce processus pourrait être une chose vraiment utile dans Netlify lui-même.

Leslie: Et une chose que j'ai vue un peu en quelque sorte est peut-être la capacité de lien vers une ligne de journal spécifique dans le journal de construction. Donc, pour le débogage, si vous avez votre journal de compilation de votre aperçu de déploiement et qu'une erreur s'est produite, soit à partir de Netlify, soit à partir de votre propre code, ce serait bien de pouvoir établir un lien direct vers cette ligne de journal. C’est donc une petite amélioration amusante à laquelle j’ai un peu réfléchi. Et cela ne veut même pas dire que nous avons également de nouvelles fonctionnalités chez Netlify, qui sont assez intéressantes. Gestionnaires de bord et fonctions d'arrière-plan. J'essaie toujours de comprendre ce qu'ils font tous et comment ils fonctionnent exactement, mais je sais que les gestionnaires de périphérie vont nous donner l'occasion de faire certaines choses avec du contenu localisé, ce qui pourrait … avoir des implications intéressantes pour des fonctionnalités que nous pourrions également intégrer à l'application Netlify.

Drew: Oui, c'est vraiment excitant. Je pense qu'il y a toutes sortes de personnes au sein de la communauté Jamstack qui font avancer tout cela. Mais je pense que Netlify, en tant que service, est vraiment derrière et fait des choses passionnantes. Et, comme je l'ai dit, je ne voulais pas que ce soit une grande publicité pour Netlify, mais je pense que vous et moi aimons vraiment le service, donc c'est excitant d'en parler, n'est-ce pas? Si les auditeurs veulent s'impliquer davantage dans l'apprentissage de la création de sites Jamstack ou veulent s'impliquer davantage dans cet écosystème, y a-t-il un bon endroit pour apprendre ce genre de choses?

Leslie: J'ai l'impression que ça explose en ce moment . Je vous dirigerais certainement vers le blog Netlify. Nous essayons d'y publier quelques trucs et astuces et annonçons également de nouvelles fonctionnalités. Je donnerais aussi un cri, pour apprendre avec Jason. Mon collègue, Jason Lengstorf, fait une sorte de diffusion en direct, et il couvre… il couvre une gamme de sujets, mais en fait aussi certains spécifiques à Jamstack. Et c’est une heure amusante de codage en direct et de sélection. Twitter, je pense, est également énorme. Alors jetez un œil au hashtag Jamstack.

Drew: Bon conseil. Nous avons donc tout appris sur la manière dont Netlify construit Netlify sur Netlify. Qu'est-ce que tu as appris, Leslie?

Leslie: Oh, c'est toujours une grande question. J'ai déjà mentionné Cypress, nous avons travaillé sur certains de nos processus pour déterminer exactement comment nous voulons exécuter nos tests de bout en bout, et je dirais donc qu'en général, j'ai beaucoup réfléchi à ce flux de travail. . Donc, moins sur la technologie elle-même, mais plus sur les flux de travail existants pour les tests de bout en bout sur le frontend, et ce qui a du sens dans ce modèle Jamstack. Donc, c’est une sorte de tangente latérale amusante. Et puis, du côté CSS des choses, nous avons parlé un peu de l'architecture CSS, et je commence à me salir les mains avec Tailwind, qui a été amusant et excitant et beaucoup à apprendre et beaucoup de noms de classes à mémoriser et … Ouais.

Drew: C'est des trucs excitants. Si vous, cher auditeur, souhaitez en savoir plus sur Leslie, vous pouvez la trouver sur Twitter où elle est @lesliecdubs, et son site personnel est leslie.dev. Merci de vous joindre à nous aujourd'hui, Leslie, avez-vous des mots de fin?

Leslie: Passez une bonne journée?

(il)