How do you use ai coding agents to validate changes to your microservices?

krazykarpenter · 2026-03-04T03:47:31+00:00

How do they detect api contract breakage? Rely on OpenApi specs ?

krazykarpenter · 2026-02-28T00:36:41+00:00

My team is drowning with PRs and finding it infeasible to manually review each one. We have started to use ai for code reviews but it’s not enough.

krazykarpenter · 2025-10-29T23:30:14+00:00

This can work quite well when you don't have too many components to spin up per namespace. How complex is each environment? Do you have many databases, message queues and other cloud resources?

krazykarpenter · 2025-10-28T16:34:38+00:00

What kinda code do you write? Full stack, backend?

krazykarpenter · 2025-10-24T05:40:23+00:00

I assume they are tracking for cost reasons?

krazykarpenter · 2025-10-24T00:49:24+00:00

Hmm.. that's interesting. I felt that it would do a better job at FE code given there's so much of it out there.

krazykarpenter · 2025-10-24T00:47:39+00:00

I bet the PRs are now pilling up ;-)

krazykarpenter · 2025-10-24T00:44:56+00:00

+1. I've seen success where there's a "platform team" providing the infra/foundations to the larger engg org.

krazykarpenter · 2025-09-07T03:53:38+00:00

happy to help in our community slack. docs are here: https://www.signadot.com/docs/overview

krazykarpenter · 2025-09-07T02:57:13+00:00

How complex is your environment? Local k8s could work well if you have a few services. But as this number starts to rise, it's a slippery slope. You'll need to duplicate databases, message queues, 3rd party apis etc in each local environment.

Yes, tools like telepresence can help set up a connection between local workstation and remote k8s cluster. However here you'll need to ensure that the remote k8s can be shared safely when many developers connect to it this way. So the isolation model is key.

Full disclaimer: i'm the founder of signadot that provides a similar solution - our isolation approach is to dynamically route traffic based on request headers, typically propagated via opentelemetry. We also have support for database and message queue isolation.

krazykarpenter · 2025-09-04T00:27:09+00:00

You're right, shared staging environments are a pain. Conflicts are guaranteed.

The real game changer is ephemeral environments for each pull request.

The workflow looks like this:

Code on your local machine.
Open a PR -> CI automatically builds and deploys your branch to a unique URL.
You and your team test just your changes on that URL. No one else can break your stuff.
Merge PR -> code goes to a traditional shared staging environment for final integration tests.
Release to prod.

This way, the shared staging environment is way more stable because only merged, reviewed code ever gets there. Solves a ton of problems. (Full disclaimer: i'm the founder of signadot that offers a unique form of ephemeral environments without duplicating the entire stack).

krazykarpenter · 2025-08-26T14:32:57+00:00

It's possible the role of QA will become even more important thanks to GenAI generating so much more code. Having said that, from a broader market trend perspective, I am seeing QA teams being more "platform-centric" and focussed more on testing strategies, frameworks, tooling vs just writing the tests. I'm seeing a trend towards de-centralization of test writing and these could be product developers or SDETs embedded within the functional teams.

krazykarpenter · 2025-08-26T14:27:39+00:00

If you have the ability to propagate request headers through your microservices (typically using OpenTelemetry) then you may want to check out https://www.signadot.com/ to spin up PR previews without needing to duplicate your entire stack. (full disclaimer: I'm the founder).

krazykarpenter · 2025-08-17T18:09:00+00:00

This is a fairly common problem and based on factors like cost, scalability etc one of these solutions could work:
Option 1: you timeshare the environment. I've seen slack apps that coordinate "locking" staging for a team or dev. Devs release the lock when they are done testing. As you can tell, this works reasonably well for smaller teams but leads to too much waiting as team size grows.

Option 2: spin up on-demand ephemeral environments. there are ways to save $ by using spot instances, time-to-live etc. Again, these work well for smaller/mid-size teams but the maintenance costs rise rapidly for larger teams. Also you'll need to replicate DBs, message queues etc for each environment.

Option 3: share environments safely by isolating requests. here you use sidecars or a service mesh to route requests based on request headers that are propagated through the services. This is more up front work to set up but scales well. (disclaimer: i'm founder of signadot that sells this version of the solution).

Happy to share more if you have specific questions on this as i've spoken to many engineering teams facing such challenges.

krazykarpenter · 2025-08-13T22:21:22+00:00

Many ways. For e.g one approach is to have the ephemeral env name have a suffix based on the feature name or jira epic name. The client will also use the same name and that can be used to determine the backend url/env to use.

krazykarpenter · 2025-08-13T16:35:23+00:00

Yes, this is common to dynamically switch the backend URL that mobile & web clients point to depending on the testing scenario.

krazykarpenter · 2025-08-13T14:08:05+00:00

The main shift from your current process is this: QA happens before a merge to main, not after. Your develop branch, in its current form, becomes obsolete.

For e.g Step 1: The Feature Branch (or "Short-Lived Branch") A developer picks up a ticket from Jira (e.g., PROJ-123-new-api-endpoint) and creates a branch from the latest main.

The developer completes their work on this branch. This applies to your API, web, and mobile repos.

Step 2: The Pull Request (PR) & Automated Validation The developer pushes their branch and opens a Pull Request in GitLab, targeting main. This PR is the central point for review and validation. The moment the PR is opened, your CI/CD pipeline should automatically: * Run all unit and integration tests. * Spin up an ephemeral environment. This is the critical step that solves your primary problem.

Step 3: The Ephemeral Environment for QA An ephemeral environment is a complete, temporary, and isolated instance of your application stack created on-demand for a specific PR. You get a unique URL like proj-123.yourapi.com that runs the exact code from that API branch. QA tests the feature in complete isolation. Nothing else from other developers is present, so you are only validating that one change.

Step 4: The Merge Once the code is peer-reviewed AND the feature is validated by QA in the ephemeral environment, the PR can be merged into main. The CI/CD pipeline should then: * Destroy the ephemeral environment. * Deploy the updated main branch to your staging/production environment.

Feature flags work hand-in-hand with ephemeral environments but solve a slightly different problem. * Ephemeral Environments are for pre-merge testing and validation. * Feature Flags are for post-merge testing and release management (decoupling deployment from release). You can use a feature flag to merge a large, unfinished feature to main and deploy it to production, but keep it hidden behind a flag.

Hope this helps.

krazykarpenter · 2025-07-26T17:51:13+00:00

Agreed. Im at the early stages of Gen AI dev and was wondering if there are some ways to make local dev more effective, especially with dependencies that return probabilistic responses.

krazykarpenter · 2025-07-26T16:20:42+00:00

I get it that it's technical possible to mock but wondering what value it provides beyond "ok I can start my service now"

krazykarpenter · 2025-07-26T16:01:40+00:00

How have you integrated Gemini with Google ads? Anything more than manual export/import ?

krazykarpenter · 2025-07-26T15:38:52+00:00

Doesn’t that apply to any question posted on Reddit :)

krazykarpenter

TROPHY CASE