| Conférencier |
Transcription |
| Serkay Olmez |
Bonjour, c'est Serkay et Fred de Seagate et aujourd'hui nous allons parler de la façon dont nous avons construit un écosystème JSL pour gérer nos scripts JSL. |
| |
Nous utilisons donc Git pour gérer les contrôles de code source, le code source de nos scripts JSL, ainsi que pour les distribuer. Ce sera donc le point principal de la présentation d'aujourd'hui. |
| |
Mais en plus de cela, je parlerai également de l'intégration de VBA pour PowerPoint, de la collecte des journaux d'incidents et des tests unitaires. Je vais passer rapidement au plan. |
| |
Je voudrais d'abord parler de notre histoire avec JSL. J'écris des scripts en JSL depuis une dizaine d'années. |
| |
Et nous sommes très heureux de là où nous en sommes maintenant, mais il nous a fallu beaucoup de temps pour en arriver là et je veux parler des étapes importantes de notre expérience, de ce que nous avons fait jusqu'à présent et pourquoi nous l'avons fait. |
| |
Nous aborderons ensuite Git et la façon dont nous l'avons activé pour contrôler le code source de nos scripts JSL et comment il nous a permis de développer d'autres fonctionnalités. Par exemple, une fois Git activé, |
| |
Vous pouvez ajouter des fonctionnalités supplémentaires, comme la surveillance de vos scripts. Ainsi, les développeurs peuvent savoir que leurs scripts sont utilisés et en surveiller l'utilisation. |
| |
Et, plus important encore, ils peuvent également collecter des journaux. Si le script plante, le développeur le sait et peut corriger les bugs. Et vous pouvez… |
| |
Vous pouvez ajouter une fonctionnalité supplémentaire pour aller encore plus loin. Vous pouvez même créer des tickets de bug automatisés si vous savez déjà que votre script a planté. Vous pouvez ainsi créer automatiquement un ticket de bug pour cela. Vous pouvez suivre ces tickets à l'aide d'un logiciel de suivi comme JIRA ou Atlassian. |
| |
Et je terminerai par nos meilleures pratiques et les leçons apprises jusqu’à présent. |
| |
Donc, |
| |
En annexe, j'ai également un manuel pour un script dont je vais parler. Il permet d'insérer des images dans PowerPoint. |
| |
Et j'ai un manuel très détaillé pour cela, et je dois juste vous faire savoir que tout ce dont je parle ici, les données et les scripts seront disponibles. |
| |
Ils sont publiés dans un dépôt public, dans la section Références, et vous pouvez les récupérer si vous le souhaitez. Commençons par |
| |
Voici un bref historique. Je travaille avec JSL depuis une dizaine d'années, et j'ai commencé avec |
| |
très basique et je ne savais pas grand chose sur les scripts JSL. |
| |
Et puis, une fois que vous commencez à faire cela, vous réalisez que vous devez avoir un contrôle de source approprié et que vous avez besoin de moyens appropriés pour distribuer vos scripts. |
| |
L'avantage des scripts JMP, c'est qu'ils sont faciles à utiliser. Vous pouvez donc créer un tracé manuellement, puis récupérer le script. Il est écrit pour vous. |
| |
Et vous pouvez également utiliser la communauté JMP sur JMP.com pour poser des questions et obtenir des réponses. |
| |
Et vous… le script est tellement efficace que vous faites votre travail avec une telle efficacité que les gens le remarqueront. Ils vous demanderont comment vous faites les choses et vous direz : « J'ai un script pour ça. » Et ils le remarqueront. |
| |
Demandez-vous : « Peux-tu partager ça avec moi ? » Et soudain, vous devenez développeur, même si ce n'était pas votre intention. |
| |
Ensuite, il faut gérer la distribution de vos scripts. La première idée qui me vient à l'esprit est de les joindre, ce qui est une idée horrible, et je le fais depuis un bon moment. |
| |
Et c'est assez évident pourquoi ce n'est pas une bonne idée, parce que vous joignez un script, puis vous l'envoyez et puis le lendemain, vous faites un |
| |
Il faut ensuite la réviser, sans même savoir si l'utilisateur acceptera la suivante. Je ne fais qu'illustrer mon propos. |
| |
Récemment, j'ai reçu un e-mail d'un collègue et il faisait référence à un script que j'ai créé en 2017 et je numérotais simplement mes scripts avec ces |
| |
Numéros de version, ce qui n'est pas une bonne idée. On revient donc au bout de trois ou quatre ans et on se rend compte que les gens utilisent encore des scripts vieux de trois ans, faute d'avoir fait la mise à jour. |
| |
Une façon de résoudre ce problème est d'utiliser un lecteur partagé et, en me basant sur l'interaction que j'ai eue avec les gens, |
| |
Discovery Summits, c'est que beaucoup de gens, beaucoup d'entreprises, l'utilisent. Donc, ce que font les développeurs, c'est |
| |
Déposez vos scripts sur un disque partagé et les utilisateurs les extrairont directement depuis ce disque, ce qui résout la moitié du problème de distribution, mais ne résout pas le problème de contrôle de source. Vous ne pouvez pas… vous ne pouvez pas retracer les modifications apportées au code. |
| |
C'est pourquoi nous sommes passés à Git. Ce fut une avancée majeure pour nous et nous a permis d'accéder à de nombreuses fonctionnalités. Avec Git, les développeurs peuvent donc transférer leurs scripts vers un dépôt et |
| |
Les utilisateurs extrairont leurs scripts directement depuis Git. Cela a représenté une amélioration significative pour nous et nous a permis de collecter les journaux de plantage et |
| |
Utilisation des scripts, etc. J'aimerais également aborder quelques points supplémentaires que j'ai appris lors des sommets. Ils m'ont été très utiles pour améliorer mes compétences en scripting. J'ai participé à un sommet en 2018 et j'ai beaucoup appris sur les expressions, etc. |
| |
les gens voudront peut-être revenir en arrière et écouter ces présentations, car elles aident à développer les compétences en matière de script. |
| |
Une autre étape importante pour nous concernait les tests. J'ai été inspiré par une conférence du Summit de l'année dernière, qui portait sur les tests unitaires et leur capacité à tester automatiquement nos scripts avant leur publication. |
| |
Aujourd'hui, je parlerai principalement des tests d'intégration car les tests unitaires sont... les tests unitaires sont nécessaires, mais pas suffisants. |
| |
Grâce aux tests unitaires, vous pouvez tester tous vos modules et ils fonctionnent correctement. Mais une fois assemblés, ils ne fonctionneront plus. Ils planteront, comme illustré ici. Chaque tiroir est probablement testé, mais une fois assemblés, ils ne fonctionneront plus. |
| |
Une fonctionnalité intéressante qui aide beaucoup le développeur concerne la collecte des journaux. |
| |
Il est très utile de savoir si votre script a planté et comment. Pour cela, vous pouvez collecter les journaux des utilisateurs, puis corriger votre script et appliquer les modifications. Les utilisateurs recevront alors immédiatement leur script corrigé. |
| |
La dernière fonctionnalité que nous déployons récemment concerne le signalement automatisé des bugs. Puisque vous disposez déjà du rapport de crash, pourquoi ne pas en tirer parti ? Nous créons donc un rapport automatisé. |
| |
surveillance |
| |
Un système de suivi des plantages et de génération automatique de rapports de bugs permet au développeur de les traiter. De plus, vous pouvez ajouter l'utilisateur comme observateur afin qu'il sache que quelqu'un travaille sur le problème. Voilà qui résout le problème. |
| |
qui résout le fossé d’information entre l’utilisateur et le développeur. |
| |
Cela montre donc la chronologie et je vais passer un peu de temps sur le |
| |
sur les éléments individuels, mais nous commencerons avec Git et je vais construire cela rapidement et laisser Fred en parler. |
| 163084 |
D'accord. |
| |
Donc, |
| |
Git est simplement un système de contrôle de versions, et je n'utilise pas le terme « contrôle de versions ». En fait, je veux dire que Git vous aide en vous offrant, de fait, des possibilités de restauration illimitées, même si vous l'utilisez uniquement sur votre ordinateur local. |
| |
vous donne la possibilité de suivre les révisions de vos fichiers et de revenir aux anciens, au cas où vous décideriez qu'un travail que vous avez effectué au cours des dernières semaines était incorrect et que vous souhaitiez revenir à quelque chose d'il y a plusieurs semaines. |
| |
Git est simplement un logiciel que vous installez sur votre ordinateur local. Il crée un dépôt, qui peut ensuite être publié dans d'autres dépôts. |
| |
Comme GitLab ou GitHub. TortoiseGit est une interface graphique accessible sur votre machine locale qui simplifie les choses. Alors, Serkay, pourriez-vous ouvrir la diapositive suivante ? |
| |
Le modèle que j'ai essayé d'inciter les développeurs à utiliser est celui utilisé sur leur ordinateur local. Ils doivent installer le client Git et démarrer. |
| |
Contrôler la version des fichiers sur leur ordinateur local. Une fois qu'ils auront pris l'habitude de le faire, nous pourrons les connecter à un dépôt distant. |
| |
et Git se connecte à des référentiels distants ou SSH en général ou à d'autres méthodes et ils peuvent pousser |
| |
Copies de leur base de données Git vers le dépôt distant. Une fois installée sur le dépôt distant, elle est disponible pour un serveur web HTTP et peut être partagée avec JMP. |
| |
Nous pouvons ensuite pointer vers les URL et le serveur web HTTP et charger des scripts à partir de celui-ci. Ainsi, au lieu d'utiliser un lecteur partagé, nous utilisons un serveur web HTTP alimenté par un push vers un dépôt Git. |
| |
Et puis les points ci-dessous soulignent simplement les avantages de cela et comment cela fonctionne exactement. |
| |
Nous pouvons passer à la diapositive suivante. |
| Serkay Olmez |
Alors je vais prendre le relais ici, Fred, et je vais vous montrer... montrer une implémentation d'illustration très basique, et les scripts sont disponibles dans les références. |
| |
Donc, |
| |
Ce sera un code très basique. Ce que je montre ici est le code développé par le développeur. C'est le strict minimum. C'est juste une boîte de dialogue qui dit « Bonjour tout le monde ». |
| |
Et supposons que le développeur veuille transmettre ce code aux utilisateurs. Donc, au lieu de fournir ce code, le développeur transmet ce code. |
| |
Voici un lien vers le dépôt. Voici donc le dépôt du script JSL Hello qui s'y trouve… |
| |
dans le dépôt distant. L'utilisateur récupère simplement... |
| |
Script à partir de l'URL. Il s'agit donc d'un code statique. Aucune modification n'est nécessaire ; le développeur peut donc le modifier à tout moment, sans que l'utilisateur n'ait à intervenir. Je vais vous montrer une illustration : je souhaite simplement afficher le plein écran. |
| |
Voici comment cela fonctionne avec une interface graphique particulière : GitHub Desktop. Il suffit d'installer ceci. |
| |
Installez le logiciel sur votre ordinateur et créez un dépôt local, qui conservera la trace de vos modifications. Par exemple, dans ce cas, je viens de créer ce script JSL « hello ». |
| |
Ce logiciel détectera toute modification et la mettra automatiquement en évidence. Pour ce faire, il suffit de la valider dans votre dépôt local. |
| |
Ce qui permet de transférer ces éléments vers votre dépôt local, puis vers le dépôt d'origine, un dépôt distant. Je vais maintenant les transférer vers le dépôt distant, ce qui les rendra accessibles aux utilisateurs. |
| |
Une fois cela fait, les utilisateurs pourront extraire ce nouveau code. Je repasse maintenant au rôle d'utilisateur et exécute le script. Une fois cela fait, la boîte de dialogue apparaît. Vous exécutez donc le script extrait du dépôt. |
| |
Je vais donc illustrer... illustrer un peu mieux cela avec un code plus avancé, qui sera également lié à PowerPoint. |
| |
Les utilisateurs effectuent de nombreuses analyses dans JMP, et beaucoup souhaitent néanmoins, au final, transférer leurs résultats vers PowerPoint. Je sais que JMP offre des fonctionnalités pour les transférer. |
| |
images directement dans PowerPoint, mais nous voulions quelque chose de plus sophistiqué. |
| |
Gérer le modèle PowerPoint. Nous souhaitons effectuer d'autres opérations dans PowerPoint, notamment définir le nombre d'images par diapositive, etc. |
| |
pour ce faire, vous devez d'abord connecter JMP à PowerPoint et vous pouvez le faire très... |
| |
De manière très efficace, vous n'avez même pas besoin de quitter JMP. Vous pouvez donc localiser l'emplacement de votre fichier exécutable PowerPoint, généralement dans « Program Files ». |
| |
Ensuite, vous créez un fichier batch qui déclenchera l'exécutable PowerPoint. Ce dernier récupérera le fichier PowerPoint souhaité et l'exécutera. JMP permet de réaliser toutes ces opérations. En résumé, il recherche le fichier exécutable PowerPoint. |
| |
Une fois localisé, il le regroupe dans ce fichier batch. Il inclut également le chemin d'accès au fichier PowerPoint à exécuter. |
| |
et la macro. PowerPoint aura donc une macro intégrée pour gérer les éléments. Voici comment |
| |
Liez JMP à PowerPoint, et vous devrez même laisser JMP en place pour cela. Mais la question est : comment faire parvenir ce fichier PowerPoint à vos utilisateurs ? Vous pourriez… |
| |
Demandez-lui de le télécharger, ce qui n'est pas idéal, car vous souhaitez gérer cela automatiquement et, en même temps, contrôler la source de votre PowerPoint. Il faut donc que ce soit un bon candidat ; il doit s'intégrer à l'écosystème global. Il ne faut pas le mettre à l'écart. |
| |
Une autre exigence est de ne pas télécharger PowerPoint à chaque exécution du script. Il est donc préférable de télécharger le PowerPoint uniquement s'il a été modifié dans le référentiel d'images ou s'il présente une nouveauté. |
| |
Une façon de procéder est d'utiliser ce petit script JMP, une commande JMP qui indique la date de création. Ce que je fais ici, c'est vérifier |
| |
La date du fichier local. Donc, si le PowerPoint local est plus ancien que celui que j'ai dans le dépôt, je le téléchargerai. |
| |
il ira télécharger le PowerPoint en utilisant une requête HTTP, et il |
| |
Cela ressemble à ceci. Il vous suffit de vérifier votre PowerPoint sur votre ordinateur local. S'il n'existe pas, vous pouvez simplement le récupérer depuis le référentiel via une requête HTTP. S'il existe, vous pouvez vérifier sa date, et s'il est ancien, vous pouvez toujours le consulter. |
| |
En résumé, vous pouvez intégrer PowerPoint de manière transparente à l'environnement JMP, ce qui vous permet d'y transférer vos résultats, y compris les tableaux et les images. Tout cela sans compromettre le contrôle des sources. Je vais vous faire une démonstration ici. |
| |
Voici donc le code que vous fournirez, par exemple, à vos utilisateurs. Encore une fois, il s'agit de code statique. Il ne contient rien d'autre qu'une URL, qui relie le script au dépôt distant. Il récupérera donc le |
| |
Script JMP du référentiel et ces scripts sont à nouveau disponibles et vous pouvez simplement les extraire des références. |
| |
Du côté du développeur, voici le script lui-même. C'est le script que le développeur a développé. |
| |
Il ou elle le pousse vers un dépôt distant. L'avantage de ce script, c'est que je souhaite juste souligner rapidement quelques fonctionnalités. |
| |
Prenons l'exemple d'un script texte autonome : vous n'avez pas besoin de distribuer de fichiers PowerPoint ni de scripts supplémentaires. |
| |
séparément. Ce que vous faites, c'est de les lier dans votre script et ils sont liés dans le dépôt ici, |
| |
y compris le PowerPoint. Ce script gérera toute la distribution. Il récupérera le PowerPoint. |
| |
Il récupérera d'autres fichiers si nécessaire. Tout est donc regroupé dans le script, et il s'occupe de toute la gestion pour vous. Laissez-moi vous montrer cela rapidement. Je vais récupérer ceci. |
| |
et le mettre en plein écran |
| |
Pour que vous puissiez voir clairement. Voici une démonstration du déclenchement automatique de PowerPoint. |
| |
Pour un cas particulier, ce script récupère les chemins d'accès d'une table JMP contenant de nombreux chemins d'accès d'images, qui font référence à ce cas particulier. |
| |
serveur, et il prendra ces chemins et il prendra simplement ceux mis en évidence ici et il les poussera dans PowerPoint. |
| |
Je vais l'exécuter, et ce script est disponible si vous souhaitez l'essayer. C'est un script entièrement fonctionnel et utile. Je l'exécute donc. |
| |
Script ici. Là encore, il fait référence au référentiel. Il ne contient donc pas le script de ligne ; il le récupère simplement du référentiel. Vous l'exécutez, il récupère le code et ouvre une boîte de dialogue. |
| |
Je vais simplement l'exécuter. Je n'entrerai pas dans les détails, et une fois lancé, PowerPoint se lancera automatiquement. |
| |
PowerPoint se lancera et… il commencera… il créera les diapositives. Il extraira 20 images, ce qui prendra 10 à 20 secondes, puis vous aurez PowerPoint. |
| |
C'est fait. Voici donc le PowerPoint que vous obtenez et tout est fait automatiquement et tout a été extrait du référentiel. |
| |
Et maintenant ? Comment réviseriez-vous ce PowerPoint ? Je suppose que vous souhaitez apporter quelques modifications à votre modèle. |
| |
vous pouvez voir plus de détails à ce sujet dans l'annexe, mais ce que je veux montrer, c'est comment vous changez le |
| |
script dans PowerPoint. Et je passe en plein écran, |
| |
Je vais juste exécuter ceci. Ce dont nous partons, c'est de ce qui nous reste dans la diapositive précédente. Vous aviez donc ces images. |
| |
Ce que je veux faire, c'est modifier le modèle de manière triviale, juste pour illustrer le propos. Donc, vous allez à… |
| |
Vous allez dans la macro, vous faites défiler vers le bas et vous trouvez l'élément à modifier. Je vais effectuer une modification simple ici. Je vais changer la couleur de l'en-tête, juste pour illustrer mon propos. Donc, vous modifiez ceci. |
| |
et |
| |
Sauvegardez-le. Et ça se passe en temps réel. |
| |
Vous enregistrez ceci et pouvez supprimer les diapositives afin qu'elles soient envoyées plus rapidement au référentiel, car vous les pousserez vers le référentiel. |
| |
Ensuite, vous le transférez via l'interface graphique Git. Il sera placé dans le dépôt. |
| |
et il le mettra à disposition de vos utilisateurs. Ainsi, tous recevront la modification instantanément. Vous n'aurez donc pas besoin de leur demander de mettre à jour PowerPoint ou quoi que ce soit. |
| |
Cela va simplement vers le référentiel. |
| |
Et je vais revenir à JMP et en mode utilisateur, puis exécuter à nouveau le script, ce qui récupérera le nouveau PowerPoint. |
| |
Et si vous l'exécutez à nouveau, il passera par le |
| |
Diapositives, la diapositive sera créée. Vous remarquerez que les modifications concernent la couleur de l'en-tête. |
| |
Donc, |
| |
Qu'avons-nous d'autre ? |
| |
Surveillance des scripts. Je pense que c'est l'une des meilleures fonctionnalités que nous ayons développées, car elle permet au développeur de voir si |
| |
Leur scénario… le sien, son scénario est apprécié ou pas. D'accord. Alors, est-il diffusé ? Est-ce que quelqu'un le diffuse régulièrement ? |
| |
Voilà donc un avantage. L'autre avantage concerne |
| |
journal… collecte des journaux d'incidents. Ainsi, si le script échoue, vous pouvez capturer l'échec grâce à la fonctionnalité de capture de journaux de JMP. Vous intégrez ainsi vos sous-routines dans la capture de journaux. |
| |
En cas d'échec, le journal de l'échec sera renvoyé dans ce texte de retour de journal. Ensuite, vous devez également |
| |
l'enfermer dans un essai, afin que le script survive encore pour faire le reportage. |
| |
Ensuite, vous vérifiez si le champ est vide. Si c'est le cas, cela signifie qu'il n'y a eu aucun crash et que vos scripts ont survécu. |
| |
Sinon, s'il n'est pas vide, cela signifie qu'un crash s'est produit et que vous l'avez maîtrisé. Vous pouvez récupérer le journal et le signaler. Pour ce faire, utilisez HTTP. |
| |
l'ID utilisateur, le nom du script et la note de connexion, qu'il s'agisse d'un crash... |
| |
Qu'il s'agisse d'un crash ou d'une exécution normale, vous pouvez éventuellement obtenir des indicateurs de performance. En résumé, vous pouvez transmettre certaines métadonnées de votre script au développeur. |
| |
Le serveur les enregistrera et vous disposerez d'un ensemble de fichiers stockés sur le serveur, que vous pourrez surveiller. Voici un exemple. |
| |
Il s'agit d'un journal de plantage, qui comporte… qui comporte un horodatage, un nom de script, donc ce script a échoué à la date |
| |
Ce crash est donc extrêmement utile pour le développeur, car il peut revenir en arrière et corriger le problème. Je vais donc regrouper ceci et cela, et faire une démonstration rapide pour vous montrer comment procéder. |
| |
comment tu |
| |
Indiquez le plantage et la manière dont vous le signalez à l'utilisateur. Je vais donc faire planter une sous-routine. Je vais créer un paramètre indéfini. |
| |
JMP va se plaindre. Il va dire que ce n'est pas défini, donc le script plante. Mais je vais appeler cette sous-routine. |
| |
Dans une fonctionnalité de capture de journal, tout sera intégré dans l'essai. Ainsi, même si le script plante avec la sous-routine, il survivra et pourra signaler un incident. |
| |
Rapport de plantage. Vous envoyez donc une notification bien formatée à l'utilisateur et vous le dites. Les scripts plantent avec cette erreur particulière, nous avons créé un journal et nous y travaillons. Voilà donc la notification que vous envoyez à l'utilisateur. |
| |
L'un des principaux enseignements des Sommets concernait les tests automatisés. Avant, je faisais mes tests manuellement, ce qui était très frustrant. |
| |
Parce que cela prend du temps et qu'il est impossible de capturer chaque détail de votre script. Il est impossible de passer des heures à tester une petite modification. |
| |
J'ai donc commencé à m'intéresser aux tests automatisés, et il est devenu très important de réaliser des tests unitaires. Les tests désignent le test de sous-routines individuelles. Par exemple, vous avez une fonction et vous souhaitez la tester. |
| |
plusieurs fois avant de l'intégrer à votre système global, afin que vous puissiez effectuer ces tests unitaires |
| |
pour des modules individuels, mais ce ne sera pas suffisant. Je peux vous montrer quelques exemples. |
| |
Par exemple, la NASA a perdu son Mars Climate Orbiter pour une raison très étrange... à cause d'une erreur très étrange car il y avait deux équipes de logiciels, une en Europe, |
| |
Un aux États-Unis. L'un d'eux travaillait avec les unités de livres, et celui des États-Unis, et celui de l'Europe. |
| |
Ils utilisaient des Newtons. Ils ont donc bien fait leurs tests unitaires. Mais lorsqu'ils ont compilé leur code, ça n'a pas fonctionné, car l'un attendait des Newtons, tandis que l'autre prenait des kilos. Ils ont donc littéralement perdu la |
| |
Orbiter, simplement parce qu'ils ont oublié de convertir les livres en newtons. Et plus récemment, Boeing a perdu son Starliner, admettant qu'ils auraient pu détecter l'erreur s'ils l'avaient fait. |
| |
un test d'intégration rigoureux. Et au final, ce qui compte, c'est |
| |
test d'intégration car les modules ne vivent pas seuls dans le script, ils communiquent entre eux. |
| |
Et voici une illustration amusante du problème. On peut avoir deux objets testés minutieusement. C'est une fenêtre, n'est-ce pas ? Qu'est-ce qui peut mal se passer avec une fenêtre ? |
| |
Mais si vous en avez deux mis ensemble, ils ne s'ouvriront même pas, vous devez donc faire des tests d'intégration pour voir s'ils sont combinés, s'ils fonctionnent bien ensemble. |
| |
Je voudrais illustrer brièvement mon point de départ en matière de tests automatisés. Je vais me référer à un cas particulier : |
| |
C'est un cas difficile, pour être honnête, car il s'agit de tester une fenêtre modale, et les fenêtres modales ne disparaîtront pas à moins que vous ne cliquiez sur un bouton. Il faut donc |
| |
créer un script JMP qui clique sur un bouton, qui imite en quelque sorte un comportement humain, et ce que je fais ici est d'injecter un testeur dans le |
| |
fenêtre modale ici. L'avantage de cette approche, je pense, c'est qu'on peut toujours distribuer |
| |
cette chose, ce script à vos utilisateurs et les utilisateurs ne se rendront même pas compte qu'il y a en fait une routine de test dedans. |
| |
Il dispose donc des crochets pour un testeur, mais ensuite vous l'exécutez seul, ce qu'il fait, c'est qu'il recherche ce paramètre de mode de test et il n'est pas défini. |
| |
Si ce paramètre n'est pas défini, le script le définira sur zéro, ce qui désactivera tous les hooks de la table. Vous pouvez donc le fournir à vos utilisateurs et les exécuter comme ceci. |
| |
Cependant, si vous souhaitez tester votre script, vous devez créer un code de test par-dessus. Ce code définira le mode de test sur 1 et créera également le testeur. |
| |
L'objet testeur que vous souhaitez injecter dans votre script. Par exemple, dans ce cas précis, il sélectionne une colonne spécifique. |
| |
Ensuite, il lui attribue un rôle en cliquant sur un bouton, puis exécute le script. Cela imite littéralement un comportement humain. |
| |
Ensuite, le script est chargé. Il s'agit d'injecter ces paramètres dans le script à tester. Le script est alors exécuté automatiquement. Le script est alors chargé et exécuté, puis l'interface utilisateur se ferme après avoir cliqué sur tel ou tel bouton. |
| |
Et ensuite, ce que vous faites, c'est que vous l'exécutez à nouveau dans une fonctionnalité de capture de journal, afin de savoir si quelque chose ne va pas, vous capturerez l'échec. |
| |
Vous l'avez également inséré dans la commande « try » afin que le script puisse générer le journal. Si tout se passe bien, le journal sera vide, ce qui signifie que votre script n'a pas échoué. |
| |
Si un problème survient, vous le saurez dans la capture du journal. C'est l'idée. |
| |
Donc, |
| |
Nous avons |
| |
la capacité de surveiller les scripts. Nous avons la capacité de |
| |
Capturer les journaux de plantages. Nous nous sommes donc demandé pourquoi ne pas agir sur ces journaux. Si un journal de plantages indique un problème, et si un script… l'utilisateur le sait déjà, car le script a planté, et le développeur le sait, car les journaux sont |
| |
Stockées sur un serveur, elles sont là pour que vous puissiez agir. Mais il ne s'agit pas encore d'une boucle fermée, car l'utilisateur ignore que le développeur est au courant. Vous pouvez fermer cette boucle en créant des tickets automatisés. Puisque vous disposez déjà de ces informations, vous pouvez |
| |
utilisez un logiciel de suivi des bugs tel que JIRA Atlassian et vous pourrez ensuite utiliser la fonctionnalité REST |
| |
Pour collecter les informations du serveur, créez un ticket, attribuez-le au développeur et assignez-le comme observateur. L'observateur permet de surveiller chaque action du développeur. |
| |
à propos du bug et saisit ces informations dans JIRA, qui seront renvoyées à l'utilisateur afin qu'il soit averti et sache que quelqu'un travaille sur le bug. |
| |
Et il existe plusieurs façons de le faire, en fonction de la version de JIRA que vous possédez, et je vous donne simplement le |
| |
Voici le code de base. Il s'agit d'un code CURL que vous pouvez créer. Vous collectez les métadonnées issues des journaux de plantage et les intégrez dans un fichier JSL. Le tout est ensuite transmis via REST et intégré au |
| |
JIRA, qui le suivra pour vous. Et ensuite, si vous l'avez configuré correctement, JIRA en informera le développeur et éventuellement |
| |
L'utilisateur pour qui le script a planté. Tout est donc lié : le développeur saura qu'il y a un bug sur lequel il doit travailler et l'utilisateur saura que quelqu'un travaillera dessus. |
| |
Bon. Je pense que cela m'amène à mes notes de conclusion. Juste les points à retenir de cette présentation. |
| |
Git a été la pierre angulaire de notre système et il nous a permis de réaliser de nombreuses fonctionnalités intéressantes, et je n'ai même pas mentionné les fonctionnalités de base, qui |
| |
Ce qui est assez évident, car cela permet également de collaborer. Ainsi, si plusieurs personnes travaillent sur le même script, vous pouvez utiliser toutes les fonctionnalités du |
