0

I work devops for a fairly large company that is in process of transitioning to microservices. This is a new area for most people involved and some of the governing requests seem like bad practice to me but I don't have the expertise to convince otherwise.

The request is to generate a report before deploying that would list any new api/events (Kafka is our messaging service) in a microservice.

The path that's being recommended is for devs to follow a style guide and then scrape the source code during CI/CD pipeline to generate a report that can be compared to previous reports and identify any new apis.

This seems backwards and unsustainable but I've been unable to find another solution that would satisfy their requests. I've recommended deploying to dev first, then using a tracing tool to identify any api changes, or event subscriptions, but they insist on having the report before deploying.

I'm hoping for any advice on best practice to accomplish this.

4

1 に答える 1

0

バージョンの変更を追跡して検出することは、間違いなくオーバー エンジニアリングです。@zenwraight が述べたように簡単なのは、API をバージョン化することです。サービスをトレースしてさまざまなバージョンとスキーマを探索することは潜在的な解決策になる可能性がありますが、それには前もってより多くの投資が必要であり、それが会社のパンとバターでない場合は、このようなものをサポートする可能性のあるベンダー製品を使用したいと思います.

検出が必要なメカニズムである場合は、Swagger などのツールを使用して内部 API ドキュメントを公開し、使用できる API があるかどうかを検索できるようにすることをお勧めします。

そして最後に、異なるバージョンへの移行をサポートするために、サービスの API オンボーディング プロセスを用意することをお勧めします。これにより、チームは、特定のバージョンを使用している他のチームに、サービスのライフサイクルが終わりに近づいており、新しいバージョンに移行する必要があることを通知できます。もの。

于 2018-10-11T18:13:28.227 に答える