MetalBear launches mirrord for CI to improve testing process for cloud native apps


MetalBear is launching a new tool that allows development teams to run CI tests against Kubernetes environments without needing to deploy code to it or spin up test environments.

According to MetalBear, testing cloud native applications can be difficult because a change made to a single service requires other services to be tested to see how it behaves. This is typically accomplished by spinning up new cloud environments or using local Kubernetes tools, but spinning up new environments can take 20-30 minutes, increase cloud costs, and add ongoing maintenance, and using local tools also has its drawbacks because local clusters don’t always behave like real ones.

Mirrord for CI aims to address these concerns by securely connecting a runner to an existing Kubernetes cluster, and then running a test suite with real services, dependencies, and traffic, enabling development teams to test against real conditions.

“Your code, i.e. the microservice in the branch you want to merge, runs in the CI runner, but mirrord proxies incoming and outgoing traffic, environment variables, and files back and forth between it and the cluster,” Arsh Sharma, senior DevRel engineer at MetalBear, wrote in a blog post.

It provides isolation within the shared cluster for each run, and features like HTTP traffic filtering, database branching, and queue splitting are used to ensure that the runner’s traffic and data are isolated.

Mirrord Policies can also be implemented to prevent unsafe operations from being executed on the shared cluster.

Mirrord for CI is available now for all mirrord users on the Enterprise plan, and it works with major CI providers, such as GitHub Actions, GitLab CI, CircleCI.

“Traditional CI pipelines force teams into slow, expensive workflows that still fall short of realism. mirrord for CI fixes this problem by running the PR code inside your CI runner while connecting it to an existing Kubernetes environment. This way you get fast feedback, realistic tests, and no extra infrastructure to manage. No ephemeral environments to spin up, no images to build and deploy, and no special CI-only setups to maintain,” Sharma wrote.

Latest articles

spot_imgspot_img

Related articles

Leave a reply

Please enter your comment!
Please enter your name here

spot_imgspot_img