Umgang mit automatisierten Jira-Tickets für neue EventBridge-Schema-Entdeckungen

Lass mich am Anfang beginnen. In meiner Rolle als AWS Cloud Engineer bei einem meiner früheren Kunden kam eine ereignisgesteuerte Architektur zum Einsatz, bei der Dritte ständig viele Ereignisse über EventBridge an unsere AWS-Umgebung sendeten. Für jeden Dritten stellten wir einen Eventbus mit verschiedenen EventBridge-Regeln bereit.

Die Herausforderung bestand darin, den Überblick über die Veranstaltungsstruktur zu behalten – wie sie organisiert war. Die Ereignisse wurden häufig aktualisiert, was zu vielen Besprechungen zur Klärung der Dinge führte.

Ende 2019 wurde ein großer Teil unseres Problems dank EventBridge Schema Discovery gelöst. Durch die Aktivierung dieser Funktion auf den Ereignisbussen wurden automatisch Schemata basierend auf den empfangenen Ereignissen generiert. Dadurch konnten wir Codebindungen aus diesen Schemata generieren, was in unserer objektorientierten Umgebung eine große Hilfe war.

Unten sehen Sie eine sehr einfache Beispielveranstaltung eines Drittanbieters.

{ "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 hat ein Schema für diese Art von Ereignissen entdeckt:

Durch die Verwendung des AWS Toolkit for Visual Studio Code können wir unsere Ereignisse problemlos als stark typisierte Objekte in unserem Code darstellen.

Unten finden Sie ein sehr einfaches Beispiel dafür, wie wir die Codebindungen verwendet haben.

Ausgabe:

123456789 C001  

Dies hat unsere Arbeitsweise verbessert, aber wir sind immer noch auf ein Problem gestoßen. Von Zeit zu Zeit fügten Dritte ihren Veranstaltungen neue Attribute hinzu. EventBridge entdeckte diese Änderungen, aber Entwickler vergaßen oft, die Codebindungen für das neue Schema zu aktualisieren. Obwohl unsere Implementierung robust genug war, um Fehler beim Hinzufügen neuer Attribute zu verhindern, führte sie zu neuen Daten, die wir nicht nutzten. Wir mussten uns darauf verlassen, dass die Entwickler daran denken, ihre Codebindungen gelegentlich zu aktualisieren, und es gab keinen klaren Prozess, um dies zu verwalten.

Manchmal wurde eine Codebindung monatelang nicht aktualisiert, und gelegentlich aktualisierten zwei Entwickler sie gleichzeitig, was zu Konflikten oder doppelter Arbeit führte.

Um dies besser zu bewältigen, haben wir uns entschieden, eine Lösung zu entwickeln, die automatisch ein Jira-Ticket erstellt, wenn ein Dritter seine Veranstaltung aktualisiert und ein neues Schema entdeckt wird.

Die Lösung ist in CloudFormation auf meinem GitHub verfügbar. Schauen Sie sich die README-Datei an.

Der erste Schritt bestand darin, eine EventBridge-Regel auf unserem Standardbus zu erstellen, die immer dann ausgelöst wird, wenn ein neues Schema oder eine Aktualisierung der Schemaversion entdeckt wird. Dieses Ereignis wurde dann an eine SQS-Warteschlange gesendet, um als Eingabe für eine EventBridge-Pipe zu dienen. Hier könnten wir zusätzliche Filter hinzufügen (in diesem Beispiel optional) und unser Event mit einer Lambda-Funktion bereichern.

Zur Anreicherung haben wir das beschreibende Schema mit boto3.
verwendet

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"]), }

Nachdem wir unsere Daten angereichert haben, haben wir sie an einen Step-Function-Workflow gesendet. Dieser Workflow löste wiederum die von AWS bereitgestellte AWS-CreateJiraIssue SSM-Automatisierung aus, die automatisch ein Jira-Ticket erstellte.

Das Ticket enthielt Details wie den Schemanamen, die neue Schemaversion und den ARN des Schemas. (Bei Bedarf können auch zusätzliche Inhalte der Veranstaltung hinzugefügt werden.)

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

Lassen Sie uns diese Lösung vorführen. Hier sehen Sie eine aktualisierte Veranstaltung, basierend auf dem Original. Der Attributstatus ist neu.

{ "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" } }

Ein neues Schema wird entdeckt. Dadurch wird die gesamte Lösung ausgelöst. Nachdem das Lambda unser Ereignis bereichert hat, wird dieses aktualisierte Ereignis als Eingabe für unsere Step-Funktion verwendet.

Das Eingabeereignis unserer Step-Funktion ist angereichert und sieht so aus.

[ { "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" } } } } } } } } ]

Der Step-Function-Workflow löst wiederum die SSM-Automatisierung aus und erstellt ein Jira-Ticket.

Der Einfachheit halber habe ich den Inhalt des Tickets kurz gehalten. Da der Inhalt jedoch auch als Eingabe an die Step-Funktion gesendet wird, könnte er auch im Ticket enthalten sein. Auf diese Weise können Sie die neuen Attribute oder Änderungen am Schema direkt in Ihrem Ticket erwähnen.

Diese Lösung wird auch ausgelöst, wenn ein völlig neues Ereignis entdeckt wird, da dadurch eine Version 1 des neuen Ereignisses erstellt wird, wodurch die EventBridge-Regel ausgelöst wird.

Auf diese Weise wurden wir über Updates informiert und konnten diese in unseren Sprint einplanen. Dies führt zu einer Beschleunigung unseres Entwicklungszyklus.

Mir ist bewusst, dass dies ein ziemlich spezieller Fall ist, aber ähnliche Lösungen können erstellt werden, indem EventBridge-Regeln eingerichtet werden, die bei den gewünschten Ereignissen ausgelöst werden, und dann Anreicherungs- und Schrittfunktionen in Kombination mit SSM verwendet werden, um weitere Automatisierungen zu erstellen.

Das obige ist der detaillierte Inhalt vonUmgang mit automatisierten Jira-Tickets für neue EventBridge-Schema-Entdeckungen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!