Skip to main content

How it works

Introduction

Signadot is installed in an end-to-end Kubernetes cluster that has the latest main version of all the services running. To test a new version of a Service, you "fork" the corresponding main version and customize it using artifacts from a development branch. Forking clones a workload under a new name within the same namespace.

For example, in the diagram below, Signadot is installed in a Kubernetes cluster that has the latest versions of all Services, represented by the blue boxes. Route Service v1.1-dev is a forked version of Route Service v1 and can be customized with a docker image and configuration from a development branch. Route Service v1.1-dev has access to all dependencies (e.g Driver Service v1 and Database) in the cluster.

Under the hood

Signadot provides Endpoint URLs to access forked versions of Services in Sandboxes. You use these URLs within automated tests or with API testing tools like curl.

Signadot Sandbox

The definition of which workloads to fork and associated configuration changes to be applied to the forked versions are stored in a resource called "Sandbox". An instance of a Sandbox is a set of forked workloads (e.g from private branches) running within a Kubernetes cluster where the baseline version (e.g from main branch) of the application is running.

Under the hood

Moreover as Sandboxes only fork the workloads that have changed, they are quick to spin up and consume low cluster resources. This enables you to test every commit for every Service and get a high quality testing signal.

Sandbox Isolation

For automated tests to run reliably, it's critical that the execution environment provide the isolation needed for concurrent tests to run. One way to provide such isolation is to copy the entire environment for every test tenant. However this introduces significant maintenance and cost overhead for a Microservices-based application.

Instead of stamping out copies of the entire environment, Signadot Sandboxes share most of the services, only fork the Services that have changed and provide isolation at the request level. i.e API requests to Sandboxes are guaranteed be isolated from each other. This way, your API test requests to your Sandbox are isolated from other developers' Sandboxes.