Mengendalikan Tiket Jira Automatik untuk Penemuan Skema EventBridge Baharu

Biar saya mulakan dari awal. Dalam peranan saya sebagai Jurutera Awan AWS di salah satu pelanggan saya sebelum ini, seni bina dipacu peristiwa telah digunakan di mana pihak ketiga sentiasa menghantar banyak acara ke persekitaran AWS kami melalui EventBridge. Untuk setiap pihak ketiga, kami menyediakan bas acara dengan pelbagai peraturan EventBridge.

Cabaran di sini ialah menjejaki struktur acara—cara ia dianjurkan. Acara kerap dikemas kini, membawa kepada banyak mesyuarat untuk menjelaskan perkara.

Pada penghujung tahun 2019, sebahagian besar masalah kami telah diselesaikan berkat Penemuan Skema EventBridge. Dengan mendayakan ini pada bas acara, skema dijana secara automatik berdasarkan acara yang diterima. Ini membolehkan kami menjana pengikatan kod daripada skema ini, yang merupakan bantuan besar dalam persekitaran berorientasikan objek kami.

Di bawah anda boleh melihat contoh acara pihak ketiga yang sangat asas.

{ "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 menemui skema untuk jenis acara ini:

Dengan menggunakan Kit Alat AWS untuk Kod Visual Studio, kami boleh dengan mudah mewakili acara kami sebagai objek yang ditaip kuat dalam kod kami.

Di bawah ialah contoh yang sangat asas tentang cara kami menggunakan pengikatan kod.

Keluaran:

123456789 C001  

Ini menambah baik cara kami bekerja, tetapi kami masih menghadapi masalah. Dari semasa ke semasa, pihak ketiga akan menambah atribut baharu pada acara mereka. EventBridge akan menemui perubahan ini, tetapi pembangun sering terlupa untuk mengemas kini pengikatan kod untuk skema baharu. Walaupun pelaksanaan kami cukup teguh untuk mengelakkan kerosakan apabila atribut baharu ditambahkan, ia menghasilkan data baharu yang tidak kami gunakan. Kami terpaksa bergantung pada pembangun untuk ingat untuk mengemas kini pengikatan kod mereka sekali-sekala, dan tiada proses yang jelas disediakan untuk mengurus perkara ini.

Kadangkala pengikatan kod tidak dikemas kini selama berbulan-bulan dan kadangkala, dua pembangun akan mengemas kininya serentak, yang membawa kepada konflik atau kerja pendua.

Untuk menangani perkara ini dengan lebih baik, kami memutuskan untuk membina penyelesaian yang mencipta tiket Jira secara automatik apabila pihak ketiga mengemas kini acara mereka dan skema baharu ditemui.

Penyelesaian tersedia dalam CloudFormation pada GitHub saya. Semak README.

Langkah pertama ialah membuat peraturan EventBridge pada bas lalai kami yang akan mencetuskan apabila skema baharu atau kemas kini versi skema ditemui. Acara ini kemudiannya dihantar ke baris gilir SQS untuk berfungsi sebagai input untuk EventBridge Pipe. Di sini, kami boleh menambah penapisan tambahan (pilihan dalam contoh ini) dan memperkayakan acara kami menggunakan fungsi Lambda.

Untuk pengayaan, kami menggunakan describe_schema menggunakan 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"]), }

Selepas memperkaya data kami, kami menghantarnya ke aliran kerja Fungsi Langkah. Aliran kerja ini, seterusnya, mencetuskan AWS-CreateJiraIssue SSM Automation yang disediakan oleh AWS, yang mencipta tiket Jira secara automatik.

Tiket termasuk butiran seperti nama skema, versi skema baharu dan ARN skema. (Kandungan tambahan dari acara juga boleh ditambah jika diperlukan.)

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

Jom demo penyelesaian ini. Di sini anda melihat acara yang dikemas kini, berdasarkan yang asal. Status atribut adalah baharu.

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

Skema baharu akan ditemui. Ini akan mencetuskan keseluruhan penyelesaian. Selepas Lambda memperkayakan acara kami, acara yang dikemas kini itu akan digunakan sebagai input untuk Fungsi Langkah kami.

Acara input Fungsi Langkah kami diperkaya dan kelihatan seperti ini.

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

Aliran kerja Fungsi Langkah akan, seterusnya, mencetuskan automasi SSM dan mencipta Tiket Jira.

Untuk kemudahan, saya ringkaskan kandungan tiket. Walau bagaimanapun, memandangkan Kandungan juga dihantar sebagai input kepada Fungsi Langkah, ia juga boleh dimasukkan ke dalam tiket. Dengan cara itu, anda boleh menyebut secara langsung atribut baharu atau perubahan pada skema dalam tiket anda.

이 솔루션은 완전히 새로운 이벤트가 발견된 경우에도 트리거됩니다. 새 이벤트의 버전 1을 생성하여 EventBridge 규칙이 실행되기 때문입니다.

이러한 방식으로 우리는 업데이트에 대한 정보를 얻었고 이를 스프린트에 예약할 수 있었습니다. 이로 인해 개발 주기가 가속화됩니다.

이것은 상당히 구체적인 사례라는 것을 알고 있지만 EventBridge 규칙을 설정하여 원하는 이벤트를 트리거한 다음 강화 및 Step Functions를 SSM과 함께 사용하여 추가 자동화를 생성함으로써 유사한 솔루션을 구축할 수 있습니다.

Atas ialah kandungan terperinci Mengendalikan Tiket Jira Automatik untuk Penemuan Skema EventBridge Baharu. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!