Gestion des tickets Jira automatisés pour les nouvelles découvertes de schémas EventBridge

Permettez-moi de commencer par le début. Dans mon rôle d'ingénieur cloud AWS chez l'un de mes précédents clients, une architecture basée sur les événements était utilisée dans laquelle des tiers envoyaient constamment de nombreux événements à notre environnement AWS via EventBridge. Pour chaque tiers, nous avons fourni un bus événementiel avec différentes règles EventBridge.

Le défi ici était de garder une trace de la structure de l'événement et de la manière dont il était organisé. Les événements étaient fréquemment mis à jour, donnant lieu à de nombreuses réunions pour clarifier les choses.

Fin 2019, une grande partie de notre problème a été résolue grâce à EventBridge Schema Discovery. En activant cela sur les bus d'événements, les schémas ont été automatiquement générés en fonction des événements reçus. Cela nous a permis de générer des liaisons de code à partir de ces schémas, ce qui s'est avéré d'une grande aide dans notre environnement orienté objet.

Ci-dessous, vous pouvez voir un exemple d'événement très basique d'un tiers.

{ "version": "0", "id": "ef21d5fc-a5ba-e2c6-fc4b-a8807455c64d", "detail-type": "orderType", "source": "com.company.A", "account": "xxx", "time": "2024-08-22T08:04:26Z", "region": "eu-west-1", "resources": [], "detail": { "orderId": 123456789, "customer": { "customerId": "C001", "name": "John Doe" }, "orderDate": "2024-08-22" } }

AWS a découvert un schéma pour ces types d'événements :

En utilisant AWS Toolkit for Visual Studio Code, nous pourrions facilement représenter nos événements sous forme d'objets fortement typés dans notre code.

Vous trouverez ci-dessous un exemple très basique de la façon dont nous avons utilisé les liaisons de code.

Sortie :

123456789 C001  

Cela a amélioré notre façon de travailler, mais nous avons quand même rencontré un problème. De temps en temps, des tiers ajoutaient de nouveaux attributs à leurs événements. EventBridge découvrait ces changements, mais les développeurs oubliaient souvent de mettre à jour les liaisons de code pour le nouveau schéma. Bien que notre implémentation ait été suffisamment robuste pour éviter les ruptures lorsque de nouveaux attributs étaient ajoutés, elle a abouti à de nouvelles données que nous n'utilisions pas. Nous avons dû compter sur les développeurs pour penser à mettre à jour leurs liaisons de code de temps en temps, et aucun processus clair n'était en place pour gérer cela.

Parfois, une liaison de code n'était pas mise à jour pendant des mois, et parfois, deux développeurs la mettaient à jour simultanément, ce qui entraînait des conflits ou des duplications de travail.

Pour mieux gérer cela, nous avons décidé de créer une solution qui crée automatiquement un ticket Jira chaque fois qu'un tiers met à jour son événement et qu'un nouveau schéma est découvert.

La solution est disponible dans CloudFormation sur mon GitHub. Vérifiez le README.

La première étape consistait à créer une règle EventBridge sur notre bus par défaut qui se déclencherait chaque fois qu'un nouveau schéma ou une mise à jour de version de schéma était découvert. Cet événement a ensuite été envoyé à une file d'attente SQS pour servir d'entrée à un canal EventBridge. Ici, nous pourrions ajouter un filtrage supplémentaire (facultatif dans cet exemple) et enrichir notre événement à l'aide d'une fonction Lambda.

Pour l'enrichissement, nous avons utilisé lescribe_schema en utilisant boto3.

data = event[0]["input"]["detail"] try: response = client.describe_schema( RegistryName=data["RegistryName"], SchemaName=data["SchemaName"], SchemaVersion=data["Version"], ) except ClientError as e: raise e return_data = { "SchemaName": response["SchemaName"], "SchemaVersion": response["SchemaVersion"], "SchemaArn": response["SchemaArn"], "Content": json.loads(response["Content"]), }

Après avoir enrichi nos données, nous les avons envoyées vers un workflow Step Function. Ce flux de travail, à son tour, a déclenché l'automatisation SSM AWS-CreateJiraIssue fournie par AWS, qui a automatiquement créé un ticket Jira.

Le ticket comprenait des détails tels que le nom du schéma, la nouvelle version du schéma et l'ARN du schéma. (Du contenu supplémentaire de l'événement peut également être ajouté si nécessaire.)

+----------------+ +--------+ +-------------------------+ +----------------+ +-------------------------+ | EventBridge | ---> | SQS | ---> | EventBridge Pipe | ---> | Step Function | ---> | SSM Automation Document | | Rule | | | | (Filtering & Enrichment)| | | | | +----------------+ +--------+ +-------------------------+ +----------------+ +-------------------------+

Faisons une démonstration de cette solution. Ici, vous voyez un événement mis à jour, basé sur l'original. Le statut de l'attribut est nouveau.

{ "version": "0", "id": "dffbd38b-9258-d028-21f3-da0ba3c9e314", "detail-type": "orderType", "source": "com.company.A", "account": "xxx", "time": "2024-08-22T08:04:26Z", "region": "eu-west-1", "resources": [], "detail": { "orderId": 123456789, "status": "Completed", "customer": { "customerId": "C001", "name": "John Doe" }, "orderDate": "2024-08-22" } }

Un nouveau schéma sera découvert. Cela déclenchera toute la solution. Une fois que Lambda a enrichi notre événement, cet événement mis à jour sera utilisé comme entrée pour notre fonction Step.

L'événement d'entrée de notre Step Function est enrichi et ressemble à ceci.

[ { "statusCode": 200, "data": { "SchemaName": "com.company.A@OrderType", "SchemaVersion": "2", "SchemaArn": "arn:aws:schemas:eu-west-1:xxx:schema/discovered-schemas/com.company.A@OrderType", "Content": { "openapi": "3.0.0", "info": { "version": "1.0.0", "title": "OrderType" }, "paths": {}, "components": { "schemas": { "AWSEvent": { "type": "object", "required": [ "detail-type", "resources", "detail", "id", "source", "time", "region", "version", "account" ], "x-amazon-events-detail-type": "orderType", "x-amazon-events-source": "com.company.A", "properties": { "detail": { "$ref": "#/components/schemas/OrderType" }, "account": { "type": "string" }, "detail-type": { "type": "string" }, "id": { "type": "string" }, "region": { "type": "string" }, "resources": { "type": "array", "items": { "type": "object" } }, "source": { "type": "string" }, "time": { "type": "string", "format": "date-time" }, "version": { "type": "string" } } }, "OrderType": { "type": "object", "required": [ "orderId", "orderDate", "customer", "status" ], "properties": { "customer": { "$ref": "#/components/schemas/Customer" }, "orderDate": { "type": "string", "format": "date" }, "orderId": { "type": "number" }, "status": { "type": "string" } } }, "Customer": { "type": "object", "required": [ "customerId", "name" ], "properties": { "customerId": { "type": "string" }, "name": { "type": "string" } } } } } } } } ]

Le workflow Step Function déclenchera, à son tour, l'automatisation SSM et créera un ticket Jira.

Pour plus de commodité, j'ai gardé le contenu du ticket bref. Cependant, étant donné que le contenu est également envoyé en entrée à la fonction Step, il pourrait également être inclus dans le ticket. De cette façon, vous pouvez mentionner directement les nouveaux attributs ou les modifications apportées au schéma dans votre ticket.

Cette solution sera également déclenchée lorsqu'un événement complètement nouvel est découvert, car elle créera une version 1 du nouvel événement, provoquant le déclenchement de la règle EventBridge.

De cette façon, nous étions informés des mises à jour et pouvions les programmer dans notre sprint. Cela conduit à une accélération de notre cycle de développement.

Je suis conscient qu'il s'agit d'un cas assez spécifique, mais des solutions similaires peuvent être créées en configurant des règles EventBridge pour se déclencher sur les événements souhaités, puis en utilisant l'enrichissement et les fonctions Step en combinaison avec SSM pour créer d'autres automatisations.

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!