Our codebase has around 12 Python microservices. Several services generate clients from OpenAPI specifications, publish those clients as packages, and then consume them elsewhere. Almost every service also depends on shared utility packages containing configuration models, enums, authentication helpers, and other common code.
This works until a shared package changes. For example, I can update service A, generate and publish a new client, and verify that service A works. A few days later, I update service B and discover that the newer client breaks it. I then have to modify service A again to produce a client compatible with both services. Similar problems occur when changing the shared utilities.
I would like to catch these compatibility problems in CI before anything reaches the test environment, rather than discovering them later or, worse, in production. Unfortunately, the codebase currently has no automated tests, and there is some resistance to introducing them. I work with an Angular monorepo elsewhere, where affected-project detection, automated tests, and pipeline checks catch many similar issues.
What are common approaches for a setup like this? Should we introduce contract or integration tests, test downstream consumers whenever a shared package changes, move to a monorepo, or use a particular Python tool?
4 Answers
A monorepo could make this easier because the services, shared packages, and generated clients can be changed and tested together. Tools such as Nx, Turborepo, or Python-oriented workspace tooling can help track dependencies and run only the affected projects in CI. An architecture such as Polylith is another option for organizing shared components and applications.
However, migrating repositories will not solve compatibility by itself. If changing the repository structure is politically or operationally difficult, start with dependency tracking, versioned packages, affected-only CI, and contract tests. Those provide much of the benefit without requiring an immediate migration.
Make the dependency graph explicit first. Document which services consume each generated client and shared package, then configure CI to identify affected projects and run their builds and tests before merging. When service A publishes a candidate client, run the relevant consumer suites against that candidate instead of waiting for service B to upgrade it later.
For API compatibility, version the API or introduce a new endpoint when making a breaking change. Consumer-driven contract testing, including Pact-style approaches, can verify that the provider still satisfies what each consumer expects without always starting every service.
I would start with a small set of high-level integration tests that exercise the services through their public APIs. Ideally CI can start the whole stack using containers or a similar setup, then run a few realistic API scenarios. Even a simple script using HTTP requests is a useful first step; you do not need a sophisticated test framework immediately.
This will not pinpoint every failure, but it can cover the important service-to-service paths and give you a safety net while more focused tests are added.
The lack of tests is the main problem, not whether the code is in one repository. A practical way to get started in a resistant legacy codebase is with characterization tests: record what the current code does, whether or not it is ideal, and use those tests to prevent accidental changes.
Focus first on the shared utilities and generated clients, since those are where your failures originate. Once those seams have coverage, add tests for the most important consumers. This is usually easier to justify than a large redesign because the initial goal is simply to preserve existing behavior.
Related Questions
How To: Running Codex CLI on Windows with Azure OpenAI
Set Wordpress Featured Image Using Javascript
How To Fix PHP Random Being The Same
Why no WebP Support with Wordpress
Replace Wordpress Cron With Linux Cron
Customize Yoast Canonical URL Programmatically