
Azure Static Web Apps avec Wassim Chegham
Durée: 56m42s
Date de sortie: 07/12/2020
Dans cet épisode, nous allons parler du nouveau service de Microsoft avec notre invité, Wassim Chegham. Présenté en mai 2020, Azure static Web Apps permet d'héberger vos projets destinés à être compilés pour générer un site ou une web app statique. Retrouvez toutes les notes et les liens de l'épisode sur cette page : https://double-slash.dev/podcasts/azure-static-web-app/
Bonjour à tous et bienvenue dans ce nouvel épisode de Double Slash.
On est le 2 décembre, on est sur l'épisode numéro 16 et on est avec Patrick.
Salut Patrick ! Salut à tous !
Et aujourd'hui on accueille quelqu'un qui va nous parler de Azure Statik Web App.
Bonjour Wacim.
Bonjour, merci de m'avoir invité.
À la limite ce que je te propose avant de commencer direct dans le vif du sujet, est-ce
que tu peux te présenter rapidement, dire un peu ce que tu as fait, ton background, tout
ça ?
Oui bien sûr.
Du coup moi je m'appelle Wacim Chegam.
Actuellement je travaille chez Microsoft en tant que senior cloud advocate spécialisé
en JavaScript.
Ça veut dire quoi ça ?
Ça veut dire que mon rôle il est de faire le lien entre la communauté JavaScript et
les équipes chez Microsoft qui travaillent sur des produits pour la communauté JavaScript.
Donc ça peut être du compte terme de SDK par exemple, pour Azure ou pour autre.
Ça peut être potentiellement tout ce qui est Edge, potentiellement tout ce qui est Teams
etc.
Mais aussi aussi des services qui sont dédiés en fait à la communauté JS et communauté
fronte, notamment Azure Statik Web Apps dont on va parler aujourd'hui.
Excellent.
Ok, ok.
Et ça fait combien de temps que tu es chez eux ?
A peu près un an et quelques mois.
C'est assez récent.
D'accord.
Ok, super.
Alors on va rentrer direct dans le vif du sujet, est-ce que c'est pour ça que tu viens
ici, nous on est des gros fans de Jamstack et donc de Statik avec Patrick.
Du coup, est-ce que tu peux nous présenter un peu Azure Statik Web App ? Comment ça
marche ?
On va dire la grosse présentation c'est quoi ?
Alors, donc ça sera la présentation technique puisque du coup je n'ai pas de compétence
marketing malheureusement.
Non, non.
Mais désolé si j'en peux des termes un peu trop techniques mais bon on est là pour
ça.
J'imagine.
Exactement.
Alors nous ici on parle tech donc tu peux parler tech et il n'y a pas de problème.
Alors parfait.
Du coup, ce service Azure Statik Web Apps donc c'est un tout nouveau service tout frais
d'ailleurs il est toujours en preview, il n'est pas encore en accès grand public, il le
sera probablement au début d'année prochaine.
En fait, du coup c'est un service qui permet aux développeurs, donc il est adressé aux
développeurs principalement.
En gros, vous connectez votre compte GitHub sur ce service là lorsque vous créez une
instance Azure Statik Web Apps depuis le portail par exemple ou le Ciali ou VS Code
peu importe il y a pas mal d'interface.
Vous allez associer votre compte GitHub, vous allez du coup associer un projet sur lequel
vous travaillez et en fait ce service lui va aller automatiquement se connecter sur
votre projet.
Il va automatiquement générer une GitHub Actions avec une config qui va bien et tout
ça.
Il va aussi surveiller les modifications sur votre repo, donc une branche ou une pôle
réquest par exemple.
Il y a à chaque fois où vous puchez des modifications, lui automatiquement il va exécuter le build
de votre projet, il va du coup faire un déploiement derrière sur Azure en fait, sur une instance
Azure et vous générez une URL en fait.
Donc cette URL là sera l'URL de votre projet.
Voilà, tout simplement.
Donc comme ça vous, en tant que développeur, nous aussi, en tant que développeur aussi,
je l'utilise pas mal, en fait on focalise principalement, on se focus sur le projet,
sur ce qu'on est en train de faire, sur le code etc.
Et puis toute la partie de configuration CI CD en fait sera automatiquement gérée
par ce service là.
Voilà, il y a d'autres fonctionnaires de parler après.
Ok, en fait on vient vraiment déléguer toute la partie build et moi je reste focus
sur mon produit, mon site, sur mon app et je...
En one click et bim ça passe directement.
Et il y a une intégration dans VS Code directement.
Exactement, il y a une extension VS Code comme pas mal de services Azure d'ailleurs.
Et il y a aussi donc une intégration dans le CLI donc Azure CLI qui est en train d'être faite.
Voilà, donc vous avez le choix en fait.
Il y a le portail, il y a le CLI et il y a VS Code.
Donc ça dépend en fait quel type de développeur vous êtes.
Est-ce que si vous êtes plus viail ou vime vous êtes plutôt côté CLI ou alors IDE
et code editor dans VS Code ou du coup si vous êtes dans la partie du coup plutôt ops
côté du coup au portail.
Bien sûr.
Ok, excellent.
Ouais donc ouais c'est un peu le principe classique.
Dès que tu pushes un truc sur ton GitHub, hop ça republie automatiquement.
C'est ça, c'est une série CD en fait qui est automatiquement générée pour toi.
Donc en fait c'est-à-dire qu'il n'y a aucune config d'ailleurs la GitHub Action,
le fichier YAML qui est généré après tu peux le modifier.
Ça c'est une particularité.
Oui justement je te poserai la question après je vais se finir.
Non mais je dois le dire ça.
Tu peux la modifier pour ajouter des variables pour customiser d'autres paramètres.
On pourra en parler d'ailleurs par la suite.
Mais du coup voilà donc en fait c'est généré pour toi avec les tokens qu'il faut,
avec les accès qu'il faut etc.
Et puis en fait à chaque fois qu'il y a un build qui se fait,
qu'il y a un déploiement qui se fait, tu as du coup une URL qui est générée.
Du coup en fait tu as une URL de base pour tout le site.
Par exemple pour ta branch main, pour tes releases.
Mais par contre quand tu fais par exemple des collègues fondés,
comment on appelle ça, des pool requests.
Du coup il y a des builds aussi,
il y a des URL spécifiques par pool requests qui sont générés pour faire du preview éventuellement.
Excellent.
Et tu vois pour les équipes c'est bien.
Après moi je travaille souvent seul et en fait moi je m'en sers pour valider la feature avec mon client.
Exactement.
Et donc ça marche trop bien parce qu'il a vraiment tout son contexte.
Et donc pour une équipe c'est top mais ça marche aussi pour les tout petits.
Parce que moi je suis tout petit.
Et en fait cette fonctionnalité sur l'appli, je fais ça.
Et ça marche super bien.
Et donc c'est top.
C'est transparent pour peu importe la taille de ton équipe ou la complexe du projet.
Il y a un build qui est fait, après le build tu peux le configurer.
Donc tu peux lancer des tests, des lignes de ce que tu veux.
Et puis après il y a un deployement qui est fait aussi.
Et puis le reste peu importe ta URL donc tu accèdes partout.
Et j'utilise d'ailleurs, on l'utilise sur un projet que je vais créer.
Que je maintiens que ça s'appelle Xlayers.
Enfin sans...
Je ne mets pas...
Toute la partie préviaux si tu veux est légérée par static web apps.
Mais par contre du coup pour l'instant pour des raisons historiques.
Parce que du coup on a commencé ce projet super longtemps.
Pour l'instant la prod est l'hébergée sur Firebase.
Mais juste comme ça va être parce que du coup on a commencé par Firebase à l'époque.
Mais pour l'instant on peut effectivement...
Mais ce que je veux dire c'est qu'on peut mélanger plusieurs...
Tu peux être des dos services.
On n'est pas quand vous utilisez static web apps et à jour vous n'êtes pas...
...bloqué avec ce service là.
Ok.
Alors moi j'avais une super question.
Je suis assez impressionné de voir un gros acteur du cloud lancer un service static.
Donc la question c'est pourquoi et est-ce qu'il y a...
Vous avez senti une demande chez Azure au niveau de la jam stack du static.
Qu'est-ce qui vous a poussé à lancer ça en fait ?
Alors tout honnêteté en fait.
Moi je ne pourrais pas deviner la raison politique de la boîte.
Ça me dépasse un peu.
Par contre je sais qu'à notre niveau notre équipe cloud advocacy est précisément JavaScript.
En fait on est pas mal en discussion avec beaucoup de PM sur différents projets, différents produits.
Précisement principalement lié à Azure aussi.
Pour en gros entre guillemets offrir la meilleure expérience développeur pour la communauté JS.
Slash front, slash node, tout ce que vous voulez.
Et en fait du coup voilà on fait...
Je vais le dire.
J'aime pas trop le terme mais on fait beaucoup de lobbying interne.
C'est notre rôle d'advocat aussi en fait.
On est là pour en fait l'intérêt des développeurs, notre communauté.
On vient d'une communauté de développeurs.
Honnêtement on a été ancrités pour ça aussi.
Du coup voilà.
Je ne suis pas le seul.
On est beaucoup en discussion permanente avec pas mal de gens.
Deux fois c'est très compliqué.
Ce n'est pas toujours facile en toute transparence.
Il faut imaginer qu'un gros groupe comme ça ne tue pas de débarque.
Coucou nous on dit qu'il faudrait ça.
Non, ça marche pas comme ça en fait.
Je l'imagine bien.
Il faut créer une relation de confiance etc.
Il faut prouver effectivement qu'il y a un réel intérêt.
Il y a pas mal d'études qui sont faites etc.
Après il y a les PM aussi qui font ce rôle là au sein des équipes produits.
Nous en gros on donne juste notre feedback et un autre sentier.
Est-ce que tel ou tel feature va fonctionner ou va aller en compte d'un workflow classique
d'un développeur front ou GS ?
Du coup on travaille depuis pas mal de temps.
Mes collègues avant que j'arrive ont commencé à ne pas pousser mais suggérer.
Il faut avoir des services qui sont vraiment orientés fronte.
Actuellement on peut toujours faire la même chose avec SatiQabab.
On peut toujours créer une kit of actions à la main.
On peut toujours créer une instance par exemple,
un app services et des points inaudits de cœur dessus.
Tout ce service existe déjà dans Azure.
Mais il n'y avait pas de service qui automatise tout ça.
Il n'y avait pas un service en 2-3 et Tlic.
Tout est pacadié si tu veux.
C'était une raison pour laquelle l'équipe ont décidé de lancer ce produit.
Après est-ce qu'il y a un lien avec le mouvement Jamstack qui s'est créé récemment ?
Moi je ne suis pas très fin du terme Jamstack.
Je ne prends pas juste parce que ça veut dire Jamstack.
Mais je sais, ça a été fait pour certaines types de population
puisqu'on prend ces termes de logilat.
En gros c'est ce qu'on faisait depuis pas mal d'années.
C'est juste qu'il fallait mettre un terme comme serverless,
comme AI, comme pas mal de termes comme ça.
Mais globalement avoir un service qui permet de héberger ton contenu statique.
On pouvait le faire avec Azure Storage à l'époque.
Très compliqué mais c'était possible.
Nous on a pas mal poussé en interne pour qu'on ait une solution différente de Azure.
Je crois que ça s'appelle Website.
On a vu de retour, disons que ça ne fonctionne pas pour nous.
Pour les développeurs qui veulent voter pas une application régulière sur Azure.
C'était compliqué.
Il y avait beaucoup de paramètres à activer et désactiver.
On est super content d'avoir ce service.
Dès que j'ai été sollicité en janvier de l'année dernière
pour rendre au comment on s'est joué avec en interne,
il n'était même pas encore fini le produit.
Il n'y avait pas encore de portail, c'était juste en si à l'ail.
J'ai directement accroché et j'ai dit que ça va être top comme service.
Parce que moi je l'ai trouvé utile pour moi personnellement.
Il y a plein en fait, en étant développeur, et JS à 100%.
J'ai tout de suite entriqué « plan » et « j'ai dans le produit »
et depuis ça prend quand même une grande partie de mon temps chez Microsoft.
Je vous même parlerai après de certains outils que j'ai créés autour de ça.
L'idée politiquement parlant, je ne sais pas.
Mais en tout cas, il y a un intérêt, un réel intérêt pour la communauté JS,
en ce moment même, parce qu'il y a un besoin qui s'est créé
et du coup nous on est là pour répondre à ce besoin-là.
Ça a été lancé quand il y a un mois ?
Officiellement ?
Alors officiellement, non parce qu'il n'est pas encore public.
Par contre, la prévieux était fait en mars, en gros l'été dernier.
D'accord.
Il y a eu un bon accueil.
Oui, en fait, je crois que ça a été lancé lors d'une conférence de Microsoft.
Je ne sais plus ce qui était « build » je ne m'en rappelle plus exactement.
L'équipe avait à peu près tablé sur une centaine d'applications créées.
J'ai plus exactement le chiffre mais on a dépassé les milliers de projets créés.
En gros, les gens ont fait un peu de travail.
Ils ont fait « funmiumusavec » et ils testent.
Ils mettent le produit.
Et puis même pour la prévieux, les fonctions étaient proposées,
c'est quand même assez intéressante.
Nous on a mis le paquet sur la documentation.
J'en ai écrit pas mal d'ailleurs et mes collègues aussi.
Ça a été pas mal, c'était pas très positif le retour qu'on a eu.
Ce qui a encore motivé plus l'équipe qui travaille dessus à plein temps.
Si vous voulez après, on pourra parler des fonctionnalités.
Il n'y a pas que le « hostiné » là.
Justement, c'est ce qu'on a fait carrément.
Est-ce que tu peux développer un peu le package ?
Qu'est-ce qu'il y a dedans et toutes les fonctionnalités qui sont inclus ?
En plus de la partie statique qui est dans le nom du coup,
ce produit là, ce service, te permet aussi de déployer une API.
À travers une Azure Functions,
une solution serverless.
C'est-à-dire que dans ton projet, je vais l'appeler « SWAPS »
parce qu'en interne, on l'appelle « SWAPS ».
Avec SWAPS, quand tu configures un projet GitHub,
étant comme « SWAPS »
tu lui dis où se trouvent tes fichiers source,
ton artefact public qui va être déployé,
par exemple, quand tu fais un build ongular ou un build view,
ce build-là, en fait, il donne un répertoire dist ou build,
j'explique, voilà, pour rien.
Dans la config, tu lui dis où se trouvent ces fichiers source,
et après, éventuellement, et c'est optionnel,
tu peux le dire, on se trouve aussi dans le répertoire API.
Donc, ta partie back-end, le « Azure Functions ».
Et en fait, grâce à cette configuration-là,
pendant le build du confet, le service
s'occupe de builder le front et le back,
et déployer les deux pour toi automatiquement.
C'est-à-dire, il va être déployé du coup le front,
il va être déployé du coup le back en tant que Azure Functions,
et tout ça, en fait, avec la même URL,
même contexte, dans les mêmes, je dirais même,
même containers, en fait.
Tout est balancé en même temps.
Le débat, le tâti, les fonctions, et tout erreur,
à chaque fois.
Comme j'ai dit tout à l'heure, en fait,
actuellement, vous pouvez le faire,
on peut déployer du coup notre partie statique
sur un service statique comme storage ou website.
On peut créer un projet Azure Functions
à côté, et puis après, on discute,
on reste avec les deux,
en configurant éventuellement les courses
côté Functions.
Mais tu dois dégérer les deux,
alors que là, tu gères un seul truc.
Là, tu vas dans ton interface,
t'as tout en fait.
J'ai un petit peu testé,
c'est vrai que c'est vraiment bien fait.
Les autres features,
ils sont aussi,
t'as le SSL gratuit,
HTTPS par défaut,
et gratuitement.
Le certificat est généré,
il renouve l'automatique mot pour toi.
Manipulé, tu peux pluguer un custom domain
à toi.
Par exemple, nous on a
xlayers.dev, on peut pluguer,
configurer en remplaçant
l'URL qui génére automatiquement
par le service.
C'est deux, trois clics
en configurant l'URL.
Je suis dans l'UNS,
tu mets un CNAME et puis...
Exactement, côté registre, tu modifies,
en 15 minutes, ça dépend de la fécité.
15 minutes 24 heures,
tu as un custom domain qui fonctionne en HTTPS.
Et puis, tu as aussi des fonctionnalités
d'authentification et d'autorisation
qui sont offertes, built-in.
C'est à dire que,
imaginons que, dont ton application,
t'as besoin d'offrir un service
de login SSO
avec différents providers comme Github.
D'ailleurs ce qu'on supporte c'est Github,
Twitter,
Github, Twitter,
Google,
Active Directory,
et je crois que j'ai oublié un dernier.
Voilà,
de toute façon, il y a d'autres providers
qui sont proposés par la team.
Microsoft peut-être, peut-être Microsoft, non ?
Du coup c'est Active Directory, c'est Azure.
Active Directory, ok.
Et puis,
simplement,
dans ton front,
tu vas par exemple, si tu veux
permettre à l'utilisateur de se loguer,
tu vas juste lui offrir une URL
qui pointe vers pointauth.login.
Google.github.tw.
Facebook, si, voilà.
Et en fait,
en allant du coup sur cette URL,
derrière,
tu autorises,
ça accéderait à ton email,
comme un SSO
classique.
Et puis derrière, tu as un token
qui est propagé vers toi.
Donc, en retour, après, tu fais ce que tu veux avec le token.
Donc, il y a zéro
config à faire côté service.
Il y a simplement à proposer cette URL
dans ton Ui,
et puis le logout, c'est pareil.
Pointauth.logout et du coup, il clire
ta session.
Et après, tu peux récupérer des infos
quand il est là ?
Après, il n'y a que certaines informations
qui sont propagées.
Moi, d'ailleurs, je fais une app,
parce que je fais, d'ailleurs,
c'est que je vage log
l'utilisateur et le client sont compte GitHub.
Et puis, du coup, en fait, il y a un UID
GitHub qui m'est retourné.
Et après, c'est à moi, en fait, d'aller un ping
en fait GitHub pour récupérer
d'autres impôts.
Avec les fonctions.
Et du coup, est-ce que tu peux
venir surcharger
ton token
avec
des rôles
pour récupérer ?
Exactement. En fait, tu peux le faire
dans la partie autorisation.
Par contre, via le portail
ou via le CLI, tu crées des rôles
pour ton application
avec des vrais personnes
des vrais comptes, entre guillemets.
Du coup, tu peux leur donner le rôle que tu veux.
Et du coup,
ces personnes-là, quand ils
se logent sur ton
projet, c'est ton application,
ils auront les rôles que tu auras défini
dans le portail.
Et donc, c'est directement intégré
dans le token
et comme ça, après, tu peux
faire ce que tu veux avec pour regarder.
Et du coup, en plus, avec des
fixis de config, tu peux rajouter
ton projet. Tu peux venir surcharger
ces rôles-là. Par exemple, tu peux
dire que cette URL-là n'est accessible
uniquement par ces rôles-là
éventuellement.
Ou alors, cette URL-là, elle est
complètement pas disponible.
Par exemple, si tu as un URL sur lequel tu bosses,
mais par contre, tu ne veux pas
la rente publique, tu peux
dire que toutes les personnes qui
accèdent cette URL, je retourne un code
500 par exemple.
Tu peux surcharger les heures,
les costatues,
les...
J'ai une question, comment
tu fais pour attribuer des rôles à des gens?
T'as une liste d'utilisateurs connectés
ou qui se sont connectés?
Non, c'est via le portail. Du coup, tu
choisis un rôle et tu choisis l'adresse mail
d'une personne.
D'accord, c'est ça.
Après, pour être honnête, pour l'instant,
cette partie-là, je n'ai pas encore
vraiment regardé de près.
Ceci dit, on a
la doc, en fait, qui
détruit vraiment comment créer ce rôle.
Il faut lire la doc.
Et après, peut-être que tu peux accéder
tout ça via un API
pour...
J'imagine, en fait, le use case
ou le client, en fait,
qui veut administrer ses users,
peut-être que
via l'API Admin, en fait,
ils pourraient attribuer
tel rôle à tel user.
Potentially.
Pour l'instant,
je ne pense pas qu'il y ait un API
proposé par le service.
Par contre, je pense que tu peux accéder via le portail.
Parce que derrière, c'est
associé à ton compte sur Azure.
Ok.
En tant qu'administrateur, effectivement,
de la console.
Donc, tu as ces informations-là.
Ok. C'est plutôt pas mal.
Donc, le service statique, les fonctions,
le gestion des utilisateurs,
ça fait déjà un peu mal.
Il y a le minimum entre guillemets pour faire
une application correcte.
Et puis, côté API,
derrière, c'est vraiment un
projet Azure Functions
basique. C'est-à-dire que tout ce que tu peux
faire avec une fonction Azure,
tu peux le faire. Du coup, tu peux brancher
une base donnée Cosmos DB,
tu peux brancher...
Je ne sais pas, moi, un...
tu peux communiquer avec tu storage,
tu peux communiquer avec...
Ouais, derrière, c'est que tu as accès
à tout Azure, les bases de données.
Il n'y a aucune contrainte, il n'y a aucune barrière,
derrière, via
les fonctions.
Ça, c'est top. C'est pas mal.
Et on est encore en prévu,
donc il n'y a encore...
soit des améliorations, soit des nouvelles
fonctionnalités qui seront rajoutées.
Et du coup, est-ce que tu sais un
peu quand est-ce que ça va sortir de la
prévu ou, pour l'instant, c'est encore
trop flou ?
On n'a pas de date officielle,
c'est un peu risqué d'annoncer
les dates, parce que c'est en fonction
de la stabilité, entre guillemets, des
features, etc.
Mais probablement début d'année prochaine,
début 2021,
probablement...
C'est bien dans, quoi.
Mais ceci dit, vous l'avez d'ailleurs testé,
en fait, les personnes qui nous écoutent.
Le produit, en fait, il est disponible
actuellement, qu'il est juste en prévu,
ou c'est-à-dire qu'il n'y a aucun garanti,
aucun SLA, entre guillemets, il y a des
soucis.
Et du coup, Alnit, comment on peut
faire pour si les personnes
qui nous écoutent, ils veulent
tester, ou
qu'est-ce qu'ils font ?
Déjà, vous allez
sur votre console Azure, le portail,
et dans la recherche en haut,
vous cherchez Azure Statics Web App.
Donc, en fait, dans la liste
des produits qui seront retrouvés...
Vous mettez le lien, de toute façon ?
Et on mettra le lien directement
vers le produit en question.
Et derrière, vous choisissez votre
souscription, vous choisissez le nom
de produit, la région.
Pour l'instant, l'ESQU est gratuit.
Actuellement, c'est gratuit.
Vous pouvez aller y tester le.
Le fritier, en fait, sera toujours disponible
même après la release publique.
Mais j'imagine que l'équipe va peut-être
décider de rajouter
quelques options payantes,
comme par exemple, je ne sais pas,
un peu plus de trafic,
un peu plus de bon de passante, ce genre de choses.
Et puis donc,
vous connectez votre compte
GitHub, vous choisissez la branche,
vous choisissez du coup le projet, pardon,
et la branche. Et après,
vous faites Next et vous faites Create.
Par contre,
j'ai quand même oublié une petite étape qui a été rajoutée
récemment. Lorsque, en fait,
vous connectez votre compte GitHub, et ça c'est un truc,
d'ailleurs, qui n'était pas le cas
dès le départ, mais en fait, on l'a
fortement suggéré à l'équipe
et qui nous a écoutés finalement.
En fait, c'est-à-dire que
au début, quand on a commencé,
via le portail, en fait,
lorsqu'on connecte notre compte GitHub,
le paramétrage, en fait,
de la GitHub Action se faisait juste par des chances,
c'est-à-dire que, où se trouvent
l'Epi, ben vous mettez
le nom du répertoire, donc l'Epi,
où se trouvent par exemple
les sources statiques
de votre front, donc là, vous mettez par exemple
sur Angular, c'est DIST
slash, Angular app
par exemple, et puis
vous faites NEXT, et après, il faut
confirmer, donc, la GitHub Action s'est créée.
Donc, on aurait dit en fait, à l'équipe,
ce serait quand même pas mal d'avoir
des suggestions, parce qu'en fait,
quand on fait de l'angular, on sait où se trouvent
les DIST, parce qu'on fait du React, du Vue, etc.
On sait en fait, par défaut, par convention,
on sait où se trouvent les build
du confète, l'équipe a maintenant
des presets, donc on a des presets
lorsque vous choisissez, vous vous dites
ok, ben moi mon projet c'est un projet Angular.
Donc là, par défaut, on va venir pré-remplir
des champs, maintenant, vous bien sûr, de configurer
ça, parce que je sais que, moi souvent,
j'aspecte jamais du coup les trucs par défaut,
parce que j'ai des use cases
assez spécifiques, donc là c'est tout à fait possible.
Et puis après, si vous avez un truc custom,
donc vous choisissez custom, vous mettez
là les, comme avant en fait, vous mettez où se
trouvez exactement vos artefacts
et votre API.
C'est assez
guide, en fait, le wizard est assez bien
fait et on pourrait,
et éventuellement, je pense qu'il
y a possibilité de la meilleure encore plus,
mais ça, on y travaille
de l'auto-détection de
exactement, c'est exactement
ce qu'on est en train de regarder.
Ouais, c'est du next, du next,
ou get big, n'importe quoi.
Le but du jeu, c'est que le developer,
lorsqu'il crée son instance via le portail,
il faut que ce soit le plus rapide possible
et le plus simple possible pour lui.
Il n'y a pas besoin de deviner en fait,
même si le fichier Yamel qui est généré,
on peut le toujours le modifier par la suite.
Il est en fait, il est dans votre projet,
il vous appartient.
Mais cette première expérience, c'est quand même pas mal en fait,
si il y a juste moyen de mettre,
de lui choisir le ripot et dire, ah, on a
détecté un projet
enculard, bah par défaut, fait on pré-remplit
les champs. Sauf,
dans le cas où vous êtes dans un mono-ripot, là,
c'est un peu plus compliqué.
Mais on a réfléchi à ce cas-là aussi,
donc on est en train de regarder ce qu'on peut faire.
OK.
Et après, vous créez
vos trucs, vous branchez,
vous attendez le temps du build
et dans 2-3 minutes, en fonction de la
durée de votre build, vous avez du coup
votre site qui est live.
Et c'est tout. Voilà.
Excellent, excellent. Et quel est
l'extension
qui est générée ? On va dire par défaut,
je vais pouvoir modifier
le sous-domaine,
mais par contre le non-domaine
par défaut, c'est quoi ?
Alors en fait, le non-domaine
qui est généré, tu ne peux pas le modifier,
c'est automatiquement généré par le service,
donc c'est des non-aliatoires
points Azure Web Apps,
Azure sites, je ne sais plus, je ne m'en rappelle plus.
OK. C'est à changer de fois.
Mais c'est un non-aliatoire
qui est associé, qui sont cette unique,
qui est associée du coup à ton projet.
Après, ton custom domain, donc là,
tu achètes un non-domaine où tu veux,
et après, tu le plug comme tu veux.
Oui, bien sûr. OK.
Donc ça, on peut le partager
super rapidement.
OK.
OK, OK.
Moi, je voulais poser la question,
alors ça fait juste, ça date,
quand même déjà un peu,
le fait que GitHub et Microsoft
se sont rapprochés
et ont fusionné et tout ça.
Est-ce que, justement,
est-ce qu'il y a une expérience
de GitHub
qui bénéficie, en fait,
à tous ces services-là
pour, justement, faciliter
la vie du développeur et, en fait,
est-ce que l'intégration entre
GitHub et Azure
se passe...
Alors, je vais reformer la question.
Moi, rien. Exactement.
En fait, est-ce que,
en interne,
est-ce que vous faites tout pour réduire
la fracture entre GitHub
et Azure, quoi ?
Parce que moi, c'est un peu le sentiment
que j'ai, c'est que, depuis que
GitHub s'est fait racheter,
tout est fait, en fait,
pour compresser
la difficulté, quoi.
Et j'ai l'impression que ce service,
il arrive en plein là-dedans,
quoi. Et est-ce que
c'est que sur ce service-là,
ou c'est aussi
sur tous les services entre Microsoft
et GitHub, quoi ?
Alors, moi,
j'ai connaissance que ce service-là,
parce que je suis dit, du coup,
en fait, c'est...
ça fait presque un an que je bosse uniquement
dessus. Je n'ai vraiment pas de vision,
en fait, sur ce qui se passe à côté. Par contre, je suis quasiment
sûr, effectivement, qu'il y a d'autres initiatives
du même style. Je vous aiderai, par contre,
juste préciser un truc, et ça, c'est quelque chose qui n'est
pas...
pas, entre-qu'il m'est compris,
par les gens qui sont existaires à Microsoft.
Moi, le premier à vendre aujourd'hui Microsoft.
Certes, en fait, Microsoft a racheté
GitHub. Et tout ce que je veux dire,
c'est mon avis personnel. Mais en fait,
GitHub reste une boîte autonome.
C'est-à-dire que nous, quand on se dit
de nous, c'est-à-dire les salariés Microsoft,
si on veut, par exemple,
c'est-à-dire que moi,
par exemple, pour avoir accès
à... pour bénéficier du code
Spaces, vous savez, le VS Code, la online
qui est qui vous fait apparaître. En fait, j'ai dû
rejoindre la beta liste, enfin la waiting liste
qui nous arrive. On n'a aucun privilège.
D'accord.
T'as pris ton ticket comme tout le monde.
Non, non, non, clairement, en fait,
c'est une boîte qui est toujours
autonome avec son CEO, etc. Ils ont leur
politique, leur roadmap, leurs priorités.
Des fois, nous, on peut suggérer des trucs,
eux, ça ne les intéresse pas, non, ça ne nous intéresse pas,
clairement.
On a tourné autour du pot. Et là,
pour le coup, il s'avère qu'apparemment,
c'était intéressant pour avoir ce truc-là. Donc, j'imagine,
ça s'est fait.
Mais par contre, je sais que nous,
dans notre équipe, en tout cas, moi, je peux parler
de notre équipe, claires d'advocacy,
en fait, on a intégré GitHub, si tu veux,
dans les...
dans les choses qu'on est censés
regarder pour essayer d'améliorer
éventuellement, parce que GitHub, voilà, c'est
l'appelation des développeurs. Nous, notre audience,
c'est les développeurs. Donc, nous,
en fait, on va où se trouvent les développeurs. Ils se trouvent
que, principalement, la majorité des développeurs
utilisent GitHub.
Bah, du coup, voilà. Donc, on
essaye de rendre entre guillemets
l'expérience la plus simple possible
pour ceux qui utilisent GitHub.
Mais par contre, je sais qu'il y a
d'autres personnes qui utilisent DevOps aussi. Donc,
là, pour le coup, il y a d'autres personnes qui travaillent
dessus. Ils se trouvent que c'est pas moi.
Mais j'ai des collègues qui foussent, principalement,
sur DevOps. Et, voilà, on a
intégré CodeSpaces aussi dans l'expérience.
En fait, il n'y a pas vraiment que...
il n'y a pas que... enfin, que soit.
Typiquement, CodeSpaces, c'est aussi un autre
exemple. Donc, CodeSpaces a été
intégré dans GitHub. Donc, pour le coup, la GitHub
va travailler en collaboration avec des équipes
Microsoft pour, voilà,
proposer ce service-là.
Qu'est-ce que je peux dire ? Ok, mais ça
reste bien deux boîtes différentes.
Oui, il y a un nique, comment on en rend ?
C'est deux identités. Ok, peut-être
que la communication est un peu plus fluide
et un peu plus...
parce que tout en haut,
ils se sont serrés la main. Mais ça reste
quand même deux boîtes différents. Ok.
Après, pour la petite anecdote,
moi sur GitHub,
j'ai un abonnement pro sur GitHub,
je le paye de ma poche.
C'est important de dire, voilà,
c'est pas parce que je suis partie de
Microsoft, c'est que du coup, j'ai un truc gratifié
pro. Non, non, je paye comme tout le monde
en fait, mon abonnement pro.
Quand mes builds dépassent,
j'ai pas d'extension, d'horreur, etc.
sur mes... sans moins SKU.
Non, non, je le paye en tout cas.
C'est sûr, hein. Ok.
Mais voilà, c'est ça quelque chose qui...
Je suis déçu, je suis déçu parce que
j'avais demandé un accès pour un code
spaitis, mais je vois que tu peux pas, donc...
J'ai attendu une semaine et demie pour avoir l'accès.
Moi, j'ai pas encore eu, je suis inscrit depuis...
En fait, moi j'ai fait au début, c'est pour ça qu'il y avait
moins de monde. Je pense que là, ça tue
un peu trop.
Mais soyez passion, soyez passion.
Ça va bientôt.
En fait, nous, on attend que ça.
C'est d'avoir...
de recevoir le mail, tu vois, pour faire
un épisode dessus, pour qu'on puisse en discuter
et pour tester tout ça.
Mais ça va être...
C'est où ce que tu es ? Je voudrais bien,
mais je vous rendrai à vous ce jour-là.
Mais du coup, on le fera.
On le fera, mais on reste persuadés
que ça va arriver et on get.
On get.
Et du coup, parce que
ce que je voulais en parler un peu,
ça utilise les GitHub Action, en fait,
pour le build, en fait.
Et c'est à ma connaissance, c'est le seul service
qui utilise ce process, pour...
ou pas, enfin.
Le service, c'est-à-dire ?
De service qui fait du statique comme ça,
de la publication automatique via GitHub, en fait.
C'est la première fois que j'utilise un service
qui me génère un dossier GitHub Action.
Chez Azure, oui, je pensais le premier.
Chez les autres, je ne sais pas.
Et tu sais pourquoi ce choix,
c'est plus flexible, c'est plus...
fait, je sais pas.
Justement, en fait, c'était pour vraiment...
enfin, simplifier le workflow au maximum.
C'est-à-dire qu'on aurait pu demander à le visateur
de créer la GitHub Action, et puis lui-même,
en fait, et configurer les tokens et tout.
Sauf que, du coup,
il suffit de connecter tant qu'en GitHub,
en fait, et on automatise tout le process.
C'est quelque chose qui est 100% automatisable,
donc, en fait, l'équipe décide de faire ça comme ça.
Donc voilà, c'est votre petit déjeuner.
Dans un but de simplifier, en fait, le process.
Ouais, parce que du coup, le build,
il est fait chez GitHub, du coup.
Ah oui, il est fait.
Il est fait sur ton instance
GitHub Actions, au côté GitHub, ouais.
D'accord, et moi, je le trouve super bien.
C'est que, ok, ça te génère
ton GitHub Action
avec toutes les paramètres
qui va bien, mais si tu veux le
surcharger, tu peux aussi, quoi.
C'est ça.
Moi, je trouve, c'est...
Je fais ta permanence, hein.
Ouais, carrément, carrément.
Et je trouve ça trop bien, parce que
t'as le côté classique en mode out of the box,
et du coup,
ça marche. Par contre,
je veux utiliser
ou je veux surcharger et faire un truc un peu plus chiavé.
Bah j'ai la main.
Donc en fait, j'ai les deux meilleurs démons,
enfin, j'ai le côté...
Exactement.
J'ai fait
une question qui s'appelle 4Cifi.app
En gros, c'est un générateur de nom de chat, en fait.
C'est pour ceux qui est bien les chats.
Mais la fronte, c'est de l'ongulard,
notre classique. Donc là, le déploiement se fait,
voilà, vous buildez, vous déployez.
Par contre, le back, en fait, j'étais un peu plus
un peu plus agressif,
c'est-à-dire que
c'est un projet... De toute façon, on n'a pas le choix.
Le back, c'est toujours en fait un projet other functions.
Le runtime, j'ai utilisé c'est note.js.
Mais par contre, la logique,
qui génère
les noms aléatoires, en fait,
je l'ai écrite en Rust.
Et du coup, en fait, on reste compilé
web assembly.
Et du coup, je charge via Node.js.
Pour l'instant,
en fait,
comment on appelle ça ? Sur Soi,
en fait, il ne peut pas builder du Rust.
Il ne sait pas builder du Rust. Parce que le build system
qui intègre, ça s'appelle orx, or yx,
il génère du Python, du Node.js, du .NET,
etc., enfin, etc.,
quelques plateformes, mais pas du Rust.
Donc ce que j'ai dû faire, en fait,
c'est que moi, dans ma configuration qui était générée par Soi,
j'ai été modifié à la partie
qui builde l'IPI.
Et en fait, je builde du coup,
mon projet en dehors de Soi,
donc dans un container,
à part sur GitHub Actions, avec un
container qui contient du coup la toolchain Rust,
cargo et compagnie.
Et du coup, ça me génère un répertoire.
En fait, c'est ce répertoire-là, d'ailleurs, que je donne
après, en fait, à Soi.
Et comme ça, voilà. Donc le build a été fait en dehors
pour la partie IPI.
Mais par contre, le déploiement suffit toujours comme il faut.
Donc voilà, ça, il serait assez
un peu, on peut dire, complexe, complexe.
Vous pouvez du coup, on peut
entreguimer,
faire un switch off
d'un build front, au back,
ou voir les deux si vous voulez.
Et donc n'utilisez que la partie
déploiement de Soi.
Mais vous pouvez désactiver la partie build si vous voulez.
Donc ça mène une grande
flexibilité, quoi. Exactement.
Donc on pourrait aller sur la partie vraiment. Alors si simple,
tout se builde bien, il y a 0 config.fr
jusqu'à, on va dire, désactiver certains builds.
Et alors,
là sur la partie action, tout ça c'est
assez clair.
On va dire un truc classique
pour les personnes qui utilisent VS Code.
Est-ce que
c'est intégré directement dans VS Code,
c'est-à-dire je fais mon, je fais mon,
alors t'as peut-être répondu déjà à ça,
mais je suis dans mon interface.
Et est-ce que je peux
cliquer sur un bouton,
et j'ai pas besoin de me connecter
à la console, j'ai juste fait mes paramètres
et je clique, BIM,
deploy, c'est parti. Exactement.
Tout se fait via VS Code.
Si tu choisis l'expérience VS Code, du coup
tu télécharges, et l'extension a téléchargé.
Donc c'est pas dans VS Code, mais du coup
il y a une extension à part, qui fait partie du
package Azure Global, mais elle est installable
séparément. Et en fait, tout se fait
du coup, via le workflow VS Code.
Vous choisissez
la subscription, vous choisissez
le nom de l'application,
vous connectez vendre Kitab, mais je pense qu'il y a,
si vous êtes déjà connecté sur Kitab via VS Code,
je pense qu'il prend la session.
Et après, en fait,
lui derrière, il est pareil, toujours généré
la Kitab Action sur votre repo
remote.
Et du coup, lorsque tout ça
est terminé, vous avez
dans les logs de la console,
vous avez du coup la réponse. Et après,
dans l'extension, vous pouvez
naviguer dans les paramètres. Donc par exemple,
vous avez fait un clic droit sur le nom du projet
qui sera listé, et vous faites
visit site. Donc là, il vous ouvre
votre Chrome Edge
pour visiter du coup du URL qui était généré.
Donc vraiment, tout se fait vraiment
mais littéralement, depuis VS Code.
J'ai fait l'expérience il y a pas longtemps.
J'ai pas du tout fait, j'ai pas fait un tour
sur le portail.
Pour vraiment valider l'expérience.
Superfluide, quoi. Super, superfluide.
Il y a, éventuellement,
pour le coup, il y a un truc que j'ai remonté d'ailleurs
à l'équipe, ce qui m'en crée, c'est l'accé
au log, en fait. Actuellement, il y a pas de log, d'ailleurs.
Il y a même pas de log sur le portail.
Mais je sais pas, c'est un choix
de l'équipe.
Quand je parle de log, c'est-à-dire
que accéder au log des fonctions
ou voir le log en fait du proxy, etc.
qui gère la partie frontale.
C'est un feedback
que j'ai fait, on verra si ils acceptent
ou pas d'ouvrir les logs.
Moi, en tant que développeur, j'aime bien lire les logs, comme tout le monde.
C'est pratique pour les fonctions
qui tournent toute seule, comme ça.
Après donc, pour les fonctions, je pense qu'il y a moyen
d'étourner ça, parce qu'on peut brancher
un app inside, donc une solution d'analytique, etc.
que vous pouvez brancher. Mais c'est vrai que la partie frontale
est un peu plus compliquée si on n'a pas...
Bon après, j'imagine qu'en toute façon,
si tu es un 404,
tu n'arrêtes pas, je pense qu'il y a un problème quelque part
dans le log.
Mais voilà, donc éventuellement, c'est le seul truc
qui pourrait manquer pour la suite.
Mais pour l'instant,
honnêtement, de toute façon,
ça, je n'ai pas eu vraiment
de retour sur les logs, donc ça ne m'inquiète pas.
Et est-ce que
tu étais au courant
un peu de la roadmap
et des features qui vont arriver
ou pour l'instant, vous continuez
à rester focus sur
ce qui est déjà en prévu, ou pour vraiment
la stabiliser et passer en voie de symique.
Il y a des choses sans prévu.
Je ne sais pas jusqu'où, en fait, c'est ce que je peux
dire publiquement, donc je préfère ne rien dire.
Au cas où, en fait,
une des fonctionnalités ne voit pas le jour,
donc il ne faut pas que ce soit déçu.
En tout cas, voilà, il y a quand même
je dirais, à ma connaissance,
après je ne suis pas dans toutes les boucles,
mais à ma connaissance, il y a déjà
peut-être quatre, cinq nouvelles features
en fait, ou améliorations qui seront proposées.
Avant,
pour l'HGJ,
pour la version de l'HGJ.
Ok, super.
Donc je pense que c'est pas mal.
Je pense que les gens vont être bon.
Parfait. Et donc,
à limite, c'est
par rapport à ce que tu disais,
ces premiers trimestres
2021, quoi.
C'est la dernière date qu'on a eu.
Maintenant, c'est vraiment pas nous qui décident
de la réaliser, c'est-à-dire l'équipe,
quand ils ont
décidé que c'est fini,
que c'est stable, etc.
Et puis surtout, qu'ils sont...
Qu'ils sont vraiment satisfaits
du produit.
C'est ça. En fait, on ne réalise pas,
parce qu'on doit réaliser, on réalise une fois que tout est vraiment
stable et que, comme tu disais,
l'équipe
est satisfait du produit.
Tout le monde en va être satisfait du produit.
Ok, super.
Tout le monde soit satisfait.
Bien sûr.
Après, je pense que ça doit être
la culture aussi dans des grosses boîtes comme ça.
Je pense que vous avez des moyens
pour faire des produits top.
Et donc, vous êtes peut-être
moins dans la contrainte de temps.
Non, on ne se complique pas.
Et donc ça,
c'est vraiment bien.
Et puis en même temps, c'est à double tranchant,
parce que vous êtes gros,
donc vous êtes aussi attendus.
C'est-à-dire que si vous présentez
un produit qui n'est pas top,
ça peut vous discréditer aussi.
C'est exactement bon.
Bien sûr.
Ok. Et pour la preview,
c'est gratuit en ce moment, c'est ça.
Là, oui, actuellement, c'est gratuit.
En fait, le forfait gratuit sera
toujours disponible même après la
sortie officielle.
Je disais qu'il y aura potentiellement
d'autres forfaits payants
pour augmenter un peu plus la puissance,
j'imagine. Mais ça, encore une fois,
on n'a pas encore...
Personnellement, je n'ai pas les...
La grille tarifée. Apparemment, je sais, effectivement,
que en tout cas, nous, on remonte pas mal
de feedback sur ce qui se fait
dans le marché en termes de terrification
par rapport à des produits similaires.
Et voilà.
Croyez-moi, on défend les développeurs,
même si du coup, le commerce
n'est pas content.
On est pauvres et développeurs, on est pauvres.
Non, non, mais...
Franchement, il y a même... En fait, le truc, c'est que
il y a même dans certains pays, en fait,
j'allais dire, on s'est rendu compte, mais moi,
je me suis rendu compte que
il y a certains pays qui n'utilisent même pas de carte bancaire.
Ils n'ont pas cette culture de carte bancaire, en fait.
Par contre, nous, actuellement, on oblige
l'utilisation, malheureusement.
Oui, à création du compte, toi, tu es obligé
de mettre en place un compte.
Donc ça, juste pour te dire, si jusqu'au bout,
on va dans la réflexion qu'on est en train
d'entamer, etc., pour vraiment essayer
de suivre pas mal de...
de personnes, en fait.
Bien sûr. Et en fait, pas une blague,
quand on dit Microsoft est très
sérieux, surtout ce qui est diversité,
inclusion, etc., ça, on fait partie, ça, en fait.
Ça, on fait partie. Les gens qui n'ont pas de carte bancaire,
en fait, ils sont exclus, du coup.
Ben ouais, ouais, c'est clair.
Donc, pour la partie
gratuite, oui, on en aura toujours.
C'est pas grave.
C'est que la partie statique, après,
les fonctions, tout ça, c'est...
On la demande, en fait, aux appels, non? C'est un truc
comme ça. Alors, en fait,
dans le forfait gratuit, si tu veux,
alors, je me semble que...
Fond l'équipe, en fait, en gros, réfléchit
au paquet de gratuite, ce que ça
couvre, etc. Et il me semble, oui,
en fait, ça couvre
une partie du trafic, si je puis dire.
Ouais, il y a un quota. Voilà, il y a un quota, on ne pas
dépasser. Si tu le dépasses, du coup, tu passes dans une...
Bien sûr. Alors, si tu le dépasses,
ça veut dire que... Ben, que ton site marre.
Ça veut dire que tu as fait une application
successeful, du coup, qui ramène peut-être
éventuellement du... du gamin.
Ouais. Donc, tu as un bon problème.
C'est ça. Normalement,
tu as un bon problème.
Il y a un truc qu'on n'a pas évoqué, d'ailleurs.
C'est l'expérience
développeur locale.
Et ça, je pense que... Voilà. Donc, en fait,
c'est à dire qu'il n'y a pas de...
Quand le produit a été lancé,
en fait, tu fais ton dev local,
tu push, en fait, tu vas du coup
sur le site qui a été généré
pour voir tes modifications.
Mais, par exemple, si tu veux débugger
ta Azure Functions
localement, si tu ne peux pas le faire,
en fait, tu le fais, du coup, mais on dort de
SatiQuapabs. Donc ça, c'est un peu
donc l'immulateur.
Et oui, excellent. Et oui, on a pas
du tout parlé ça. La NCLI Azure
que tu peux avoir en local pour lancer
des fonctions, tout ça. Non. En fait, le NCLI
te permet juste pour l'instant de
créer l'instance, de
configurer le tout, etc. et de déployer. Il
permet pas de lancer localement, en fait.
Quand je parle du NCLI, je parle du NCLI
SatiQuapabs. Le NCLI Azure
Functions, ça, tu peux effectivement
l'utiliser. Mais encore une fois, je veux dire
tu n'auras pas
cette expérience SatiQuapabs localement,
c'est-à-dire avec le proxy qui sert
ton frontend,
qui sert ton backend, qui donne l'authentification
et ainsi de suite.
Du coup, ça, c'est un problème
auquel j'ai réfléchi à partir
de février de cette année.
Et en fait, du coup, je me suis
penché sur un problème.
Et donc, j'ai
créé un immulateur local
pour l'expérience développeur.
Donc ça a commencé
avec moi dans mon coin,
j'ai bidouillé, etc. pour faire vraiment
reproduire, pour vous dire,
j'ai même été obligé de reverse engineer
comment l'équipe faisait l'authentification
le process d'USFO, etc.
J'ai passé des
jours en aides-suits avec des breakpoints
et tout sur Chrome pour faire toutes les redirections,
les cookies qui sont générées et ainsi de suite
pour essayer de reproduire
fidèlement, en fait, le process localement
parce que l'immulateur, s'il n'est pas fidèle,
ça sert à rien.
Ah oui, je l'ai dit, oui.
Du coup, donc là,
il a pas mal avancé sur
l'ADV, etc.
Et en fait, récemment,
il y a 2-3 semaines,
j'ai eu un
message du coup de l'équipe,
de PM en fait, de l'équipe, ça dit quoi, BAPS,
en me disant, et en fait,
ton immulateur, là, on l'aime bien,
est-ce que ça t'intéresse quand l'intégrer officiellement ?
J'ai dit, ben oui, bon co,
moi, ça me va.
Du coup, ça, je peux le dire, parce que
c'est moi qui m'en occupe, il y aura effectivement
un immulateur,
il faut juste que je travaille vite
pour la sortie,
pour en va dire, voilà,
avoir en fait,
une expérience STATIC WE BAPS
locale de développement,
qui vous permettra de débuguer
votre front, votre bac, avant
d'envoyer votre push.
Ouais, d'avoir vraiment tout l'univers
sur ta machine, quoi.
C'est ça, voilà, effectivement.
Et donc, on est en train de travailler
avec l'équipe qui gère l'extension VS Code,
pour éventuellement intégrer des bouts de l'immulateur dedans,
comme ça, en fait, on garde
cette expérience vraiment full VS Code,
full CLA et séparé,
mais entre les deux, on va y voir
le même CLA et immulateur qui seront, on va dire,
séparés pour l'instant.
Et du coup, ouais, et j'ai
encore une question sur
au niveau du build, en fait, est-ce que
tu peux
injecter, est-ce que tu as des hooks
en fait, sur lesquels que tu peux
remonter ton build, en fait,
tu peux injecter
des hooks, est-ce qu'on a accès à des hooks
au niveau de ton build, par exemple,
pour lancer un process sur des images,
lancer un process sur,
je sais pas quoi, tu vois,
est-ce que au niveau de ton build, on a accès
à ce niveau de granularité
de précision, ou encore peut-être...
En fait, actuellement, actuellement, donc,
dans les propriétés qui sont générées
dans la GitHub Actions, donc
tu en as...
tu en as du coup, tu as deux paramètres,
tu as deux propriétés pour tes fichiers,
back and front end, et en fait,
tu as deux autres commandes, une qui build
front et une qui build back.
Par défaut, en fait, le
build, le système de build
orix dont j'ai parlé tout à l'heure,
en fait, par défaut, quand il détecte que c'est un progeno.js,
il va aller automatiquement chercher
des scripts npm à exécuter,
le premier, en fait, étant
npm run build.
Donc, si vous avez ce script-là dans votre package
JSON, il va l'exécuter. Donc, je dirais,
en fait, si tu veux des
hooks, en fait, c'est à la... c'est dans ce
package JSON que tu peux mettre un pré-build
et un post-build, éventuellement.
Par contre, soit, lui, effectivement, on
peut pas descendre à ce niveau-là,
parce qu'il faut qu'il reste le plus générique
possible.
Par contre, il y a, en gros,
déjà de un, cette commande
l'exappelle... je crois que ça s'appelle...
je ne me rappelle plus...
Custom build, quelque chose.
Et c'est sûrement pas ça, en fait,
parce que je crois que j'ai inventé le terme,
mais en gros, c'est une commande dans le YAML
qui est généré. En fait,
tu... en tout cas, tu mets une chaine
de caractère vide, du coup, en fait, tu désactives
le build en faisant ça.
Et en fait, quand tu fais ça, est-ce que j'ai dit
là pour mon projet Rust ? En fait, du coup,
tu filtes ton build à part, dans une
step build séparée, si tu veux.
Dans un autre monde, ok. Et comme ça,
après, tu... en fait,
tu as accès,
mais aujourd'hui,
c'est à toi de faire ta config.
Oui, on rentre dans la partie
un peu advanced, effectivement.
Oui, bien sûr.
Parce que, soit tu as la possibilité de complètement désactiver
le build et de faire toi-même en haut,
enfin, en dehors,
puis de la step en question,
soit tu gardes le build qui se fait automatiquement.
Par contre, dans ton package ZONE,
tu viens, du coup, modifier
et rajouter un pré-build, post-build,
ou éventuellement.
Oui, et c'est toi où tu mets ton petit script
custom
avant. Ok, super.
Exactement. Je peux donner un autre exemple aussi
où j'ai du build du coup un website en Scali.
Donc Scali, c'est un site généré
en partant angulaire, en fait, qui nécessite
du coup d'avoir...
j'oublie le...
L'équivalent d'un...
Un peu petit, voilà. Un peu petit, en fait.
Pour du coup, générer...
tes pages statiques côté node.
Pour le coup, en fait, je pouvais le faire
avec Static Web Apps. Donc, j'ai dû faire
un script shell à part, en fait, qui s'exécute
avant le build
de Static Web Apps, et qui, en fait,
installe des dépendances
supplémentaires, en fait, pour que
lorsque l'on soit... commence à builder,
il a, du coup, toutes les dépendances qu'il faut.
Ok. Ok.
Pas mal, pas mal.
On a pour l'instant que ce type
de customisation.
Après, encore une fois, pour les personnes
qui nous écoutent, si vous avez des use-race, etc.,
n'hésitez pas à me pinger sur Twitter.
Mon boulot, c'est ça, en fait, c'est vraiment
d'avoir, en fait, vos use-case,
et du coup, de les remonter aux différents équipes.
Parce qu'encore une fois, l'équipe qui fait le build, qui s'occupe
d'Orex, n'est pas la même qui j'y arsoie.
Donc, c'est rare.
Moi, je vais dispatcher l'information.
Ouais, tu vois, pis...
Et puis, ce qui est super intéressant, c'est que toi, tu connais
à qui l'envoyer, quoi.
Tu connais...
On va dire que tu as tout l'organigramme
et tu sais que, ok, celles feature,
elles pourraient intéresser tel mec,
et du coup, c'est toi un peu
le get-keeper.
Donc, c'est top.
En fait, le plus souvent, c'est ça, si je connais les personnes
et souvent, je ne connais pas du coup les personnes,
parce que du coup, ça bouge et ça change.
Donc, en ce cas-là, je vais sur Teams. En fait, du coup, on a un outil
qui permet, du coup, de trouver qui fait quoi, etc.,
sur Teams.
Et du coup, je peux le solliciter.
Mais bon, t'es quand même en interne, quoi.
Enfin, c'est...
T'es dans l'équipe, donc...
Comme je disais au début, c'est le boulot
d'un developer advocate. Ça se fait vraiment faire le lien, en fait.
Moi, je fais le lien entre les développeurs,
ma communauté,
et les ingénieurs et les piens,
mais les Microsoft manière générale en interne.
Vous,
vous me remontez juste vos infos.
Frustration, vos features request.
Le feature request, c'est plus compliqué,
mais bon, ça peut se discuter des fois.
Mais si vraiment,
d'ailleurs, je crois qu'on a...
On le mettra peut-être dans les liens.
On a en fait un guitar public
pour remonter les bugs.
Donc là, c'est principalement pour les bugs,
en fait. Du coup, pour les gens qui disent déjà
le service.
Comme ça, on peut tracer les fonctionnalités.
Soit, au niveau de la DOG, si vous voulez l'ISO,
vous trouvez qu'il y a un truc pas cohérent,
vous le mettez là-bas, sur le guitar bon question,
ou vraiment des bugs techniques, en fait,
qu'on pourrait, du coup, nous, traiter par la suite.
OK.
On a fait le tour.
Je sais pas si on a des choses encore à rajouter,
sur...
Toi, Wacim ou pas ?
Non, à part du coup, vraiment,
essayer le, tester le au maximum,
essayer éventuellement de...
Enfin, si vous le testez dans le but de vraiment le tester,
essayer un...
Des use cases un peu différentes, un peu complexes,
vraiment pour pousser le truc
au maximum, et vraiment
remonter des...
des bugs encore une fois, des fonctionnalités qui manquent.
Donc pour ça, n'hésitez pas à me pinger.
Et puis après, même si vous êtes satisfait,
dites le moi aussi, parce que,
du coup, je pense qu'il va être content de savoir
que ça plaît aux gens, en fait.
Et puis aussi, pour l'émulateur,
donc...
L'émulateur est déjà open source, donc vous pouvez le tester.
Il y a potentiellement des trucs qui...
qui marchent pas bien. Donc,
n'hésitez pas à le tester. D'ailleurs,
l'émulateur, je l'ai pas dit, mais en fait,
vous pouvez donc l'utiliser en local, bien sûr.
Et en fait, vous pouvez aussi l'utiliser
sur...
Toutes les... tous les roundtimes
supportées par Azure Functions, et non pas
simplement Node.js, mais ça marche aussi avec
.NET, avec Python, avec JavaScript, vous voulez.
Donc, il y a pas de limitation.
On va mettre à le lien de façon du repo.
Voilà, ouais, c'est ça. Et puis voilà, donc...
Je pense que c'est...
Je pense qu'on a fait le tour, effectivement.
OK. Et du coup, où est-ce qu'on peut
te retrouver sur Twitter, je ne sais pas, t'en as d'un ?
Je n'ai pas dit... Je suis
Manikineko sur Twitter, donc pour
ceux qui parlent japonais, enfin Manikineko.
Mais c'est le chat du...
Enfin, le culture asiatique, d'ailleurs,
je ne sais pas que japonais. C'est le petit chat
porte-bonheur, en fait, qui bouge le bras. Ça s'appelle
Manikineko. Et qui rapport de l'argent,
ou celui qui rapport... De l'argent, enfin,
de... de...
de la chance.
Et Manikineko, le Neko, c'est avec 2
cas. Du coup, Neko, normalement,
c'est un seul cas, mais bon. OK.
Neko avec un cas sur Google, vous avez tant
beucut du sourd et chat. Mais tout ça,
je pense que... Sinon, vous tapez Weissime
chez K. Oui, on m'en mettra ton lien, tout ça.
Tout ça.
Pareil sur ton GitHub, ton...
Gu... Gu...
Oui, GitHub, sinon, Weissime.dev.
Simplement. Donc là, vous allez tomber
sur ma page GitHub, ou en gros, si ma...
ma page principale, j'ai pas le temps de faire un blog
ou une landing page.
Euh, donc voilà, vous allez trouver sur le...
d'ailleurs, vous allez tomber sur tous les projets que je fais.
Je ne sais pas que ça, d'ailleurs, à côté. Je fais pas mal
de trucs open source. Et liés à
la IoT, par exemple, en Angular,
JavaScript, pas mal de trucs...
rigolo.
Si vous voulez d'ailleurs participer
ou faire mes muses avec ça.
Vous faites des paires.
Oui, pour ceux qui sont motivés, ça sera avec plaisir.
Euh... Et puis...
puis voilà, quoi d'autre. Sinon,
j'ai une page...
j'ai une page chez Ecology.
En fait, c'est un service qui...
c'est unablement, en fait. Tu crées un compte chez eux.
Et en fait, tous les mois, en fait,
tu contribues à planter des arbres dans le monde entier.
Dans pas mal de forêts, en fait.
Donc voilà. Donc si vous voulez
m'aider à planter des arbres
et à garder notre planète un peu saine.
Donc je vous remercie d'avance.
C'est quoi, c'est Ecology?
Ecology.
Ecology.
C O G I Y, je crois.
G I Y.
Ok.
On le mettra le lien aussi.
On le mettra tous les liens, en fait.
Ça va marcher.
Parfait.
Bonne équipe.
Et bah, écoutez,
moi je vous remercie tous les 3
et à la limite,
pour toutes les personnes qui sont arrivées
à la fin de cet épisode,
bah on vous remercie
d'avoir écouté, de nous avoir écouté
jusqu'au bout.
Et pensez,
pensez vraiment à nous mettre un petit,
un petit star,
un petit like,
un petit commentaire sur votre plateforme préférée.
Nous, ça nous aide vraiment
à sortir du lot tout ça.
Donc on compte sur vous.
Un grand merci Patrick.
Bah, merci à toi. Merci à Oassim.
Bah vraiment, merci à vous.
Merci à vous de me faire,
pardon, de parler de tous ces services
qui me tiennent beaucoup à la cœur.
Merci vraiment.
C'est cool.
Merci.
Ciao ciao, merci à vous.
Ciao.
A plus, ciao.
Salut.
On va pas trouver double slash
sur le plateforme de podcast préféré.
Et sur le site internet du podcast,
www.flash-podcast.fr
Sur le site, vous allez retrouver
tous les liens de l'épisode,
des références,
des bouquets durant l'émission.
Merci.
Episode suivant:
Les infos glanées
DoubleSlashPodcast
Double Slash, un podcast sur le développement web. Retrouvez-nous régulièrement pour parler de sujets variés tels que la JAMStack, l’accessibilité, l’écoconception, React.js, Vue.js, Next.js, Nuxt.js, le CSS et des retours d’expériences sur des implémentations.
Tags
Card title
[{'term': 'Technology', 'label': None, 'scheme': None}, {'term': 'Technology', 'label': None, 'scheme': 'http://www.itunes.com/'}]
Go somewhere
Snipcart avec François Lanthier Nadeau