Introduction à Instill-ai
Travailler sur le projet pipeline-backend d'Instill, c'était comme résoudre un puzzle ? puzzle, sauf que certaines pièces changeaient de nom ! Ma mission ? Créer un composant capable de renommer les champs JSON sans créer de conflits. Rejoignez-moi pour partager mon parcours d'apprentissage de Go, d'étude des documents bien organisés d'Instill et de création d'une solution désormais fusionnée et prête à fonctionner ! ?
Instill avait besoin d'un moyen de renommer dynamiquement les champs dans les structures de données JSON. Le rebondissement ? Nous avons dû gérer des cas où un champ renommé pouvait entrer en conflit avec un champ existant. Sans un système de résolution des conflits, le chaos règnerait en maître !
pipeline-backend gère toutes les ressources de pipeline dans Versatile Data Pipeline (VDP) pour rationaliser les données du composant de début, en passant par les composants AI/Données/Application et jusqu'à la fin composant.
Dans ? Instill VDP, un pipeline est un DAG (Directed Acyclic Graph) constitué de plusieurs composants.
flowchart LR
s[Trigger] --> c1[OpenAI Component]
c1 --> c2[Stability AI Component]
c1 --> c3[MySQL Component]
c1 --> e[Response]
c2 --> e
Un Composant sert d'élément de base essentiel au sein d'un Pipeline.
Voir la documentation du package de composants pour en savoir plus détails.
Une recette de pipeline précise comment les composants sont configurés et comment ils sont interconnectés.
Les recettes sont définies en langage YAML :
flowchart LR
s[Trigger] --> c1[OpenAI Component]
c1 --> c2[Stability AI Component]
c1 --> c3[MySQL Component]
c1 --> e[Response]
c2 --> e
Pour être honnête, je commençais à douter de ma capacité à résoudre ce problème, mais ensuite Anni a laissé tomber le message parfait qui m'a permis de continuer.
Une fois que je me suis senti à l'aise, ChunHao, qui avait créé un schéma JSON pour cette tâche, m'a donné le feu vert ? pour commencer à coder. Et c’est ainsi que le voyage a commencé !
Les principales exigences étaient :
Armé de café☕ et de courage ?, je me suis mis au codage. Voici un aperçu de la logique de base :
Tout d'abord, j'ai créé un système de cartographie pour suivre les anciens et les nouveaux noms de champs. C’était la clé pour détecter les conflits.
flowchart LR
s[Trigger] --> c1[OpenAI Component]
c1 --> c2[Stability AI Component]
c1 --> c3[MySQL Component]
c1 --> e[Response]
c2 --> e
Chaque fois qu'un conflit était détecté, la fonction ajoutait "_conflict" au nouveau nom. C'est une astuce simple qui garantit que nos champs JSON restent uniques et, surtout, conviviaux les uns par rapport aux autres ! ✌️
Une fois les mappages de champs mis en place, l'étape suivante consistait à les appliquer à nos données JSON.
variable <span># pipeline input fields</span> output: <span># pipeline output fields</span> component: <component-id>: type: <component-definition-id> task: <task-id> input: <span># values for the input fields</span> condition: <condition> <span># conditional statement to execute or bypass the</span>
Voici la logique qui applique les noms mappés à nos données JSON. Le résultat ? Nos données sont soigneusement renommées, les conflits résolus et la structure intacte. ?
Après avoir créé le composant, j'ai abandonné le brouillon de PR et obtenu un commentaire :
Après m'être familiarisé avec les méthodes de test d'Instill et appris à créer des cas de test efficaces, je suis allé plus loin.
C'est l'heure des tests ! ? J'ai écrit des tests couvrant tout, des simples renommages aux cas extrêmes complexes avec des champs JSON imbriqués. Chaque série de tests a conduit à des améliorations supplémentaires.
func mapFields(fields map[string]string) map[string]string { newFieldMap := make(map[string]string) for oldName, newName := range fields { // Check for conflict if _, exists := newFieldMap[newName]; exists { newName += "_conflict" // Add suffix for conflicts } newFieldMap[oldName] = newName } return newFieldMap }
Voici où j'aimerais partager une réflexion personnelle : Les tests ont été la partie la plus difficile de ce projet ??. Il y a eu des moments où je me suis demandé : « Est-ce que ce test fait vraiment ce qu'il est censé faire ?
À ce moment-là, j'ai rencontré un problème de peluches—
Il a souligné le problème et a même fourni la solution. Tout ce que j'avais à faire était de l'implémenter, mais cela me rappelait que même les plus petits détails comptent pour que le code fonctionne correctement.
Une fois ces premiers obstacles surmontés, les tests sont devenus mon filet de sécurité. Cela m'a donné la confiance de savoir que mon code fonctionnerait dans différents scénarios ?️♂️. Cela m'a également montré que les tests ne sont pas seulement une étape à cocher : c'est un moyen de garantir que mon code est fiable et résilient.
Après avoir terminé mes tests, j'ai poussé mon code, prêt pour le processus de révision. Cependant, nos contrôles CI (Continuous Integration) n’ont pas réussi. Le commentaire d'Anni m'a rappelé gentiment de revérifier mes cas de test :
« Hé @AkashJana18, pourrais-tu vérifier tes cas de test ? Notre contrôle CI montre qu'il n'a pas réussi ici. Veuillez le tester localement avant de le transmettre au PR. Chaque fois que vous poussez votre commit, nous déclencherons les vérifications afin que vous puissiez détecter tout problème avant que nos ingénieurs n'examinent votre code. Merci ! »
C'est à ce moment-là que j'ai réalisé que je devais exécuter les tests localement avant de soumettre. ChunHao a également ajouté :
"Veuillez l'exécuter et le transmettre avant de demander la révision. Exécutez $ go test ./pkg/component/operator/json/v0/... pour le vérifier localement."
J'ai rapidement exécuté les tests localement, identifié les problèmes et les ai résolus.
Un petit moment de fête ?
Ce processus m'a fait apprécier encore plus l'importance des tests locaux, car il garantissait que tout était solide avant de le soumettre pour examen.
Avant la fusion, ChunHao a effectué une révision finale, apporté quelques modifications, une recette de test QAed et a mis à jour la documentation pour refléter les nouveaux changements. Un grand merci à Anni pour son soutien continu tout au long du processus : cela a fait une énorme différence. ?
L'une des plus grandes leçons que j'ai apprises était de savoir comment la collaboration et le mentorat peuvent faire ou défaire un projet. Les modérateurs d'Instill, Anni et ChunHao, m'ont fourni les conseils dont j'avais besoin lorsque j'étais perdu dans la syntaxe Go ou que j'avais du mal à trouver la bonne approche. En travaillant ensemble, nous avons transformé un problème complexe en une solution propre et fonctionnelle.
Je vais être honnête, il y a eu des moments où j’ai eu l’impression d’avoir mordu plus que je ne pouvais mâcher. Mais les encouragements constants d'Anni, combinés aux instructions claires de ChunHao, m'ont permis de rester sur la bonne voie.
Une autre étape pourrait consister à étendre cette approche à d'autres parties du pipeline qui nécessitent une gestion dynamique des noms de champs, car qui n'aime pas un peu d'automatisation⚙️ ?
Grâce à la documentation solide d'Instill, aux conseils de ChunHao et au soutien moral d'Anni, ce projet est devenu une fantastique expérience d'apprentissage. Je suis passé de ne rien savoir de Go à l'implémentation d'une fonctionnalité entièrement fonctionnelle prête pour la production (et j'ai le PR fusionné pour le prouver ?).
Preuve :
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!