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

Lassen Sie 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 zur Verfügung.

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 ein sehr einfaches Beispielereignis 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 konnten 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
<class 'schema.com_company_a.ordertype.OrderType.OrderType'>
<class 'dict'>

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. Sehen 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 Schemaversionsaktualisierung 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 hatten, schickten wir sie an einen Step-Function-Workflow. 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 es sich hierbei um einen recht speziellen Fall handelt, aber ähnliche Lösungen können erstellt werden, indem EventBridge-Regeln eingerichtet werden, die auf die gewünschten Ereignisse 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!