Skip to main content

Overview

Introduction​

Signadot is a Kubernetes-native platform that enables shift-left testing for microservices-based applications. It is used by engineering teams to test changes in a high-fidelity Kubernetes environment early in the development lifecycle. This helps in distributing testing responsibilities across the organization and empowers teams to ship fast while improving quality of releases.

Signadot Shifts Integration Testing Left

Signadot can be used at several stages of the development lifecycle. Some of the common use-cases are detailed below:

  1. Pull Request Previews: Developers and/or QA engineers can use Signadot to create pull request previews of the changes they have made. This allows them to catch any issues or bugs by testing against real dependencies and data as code gets reviewed.
  2. Automated testing: Teams can use Signadot for running automated tests on each microservice in each pull request before it is merged. It enables several categories of testing such as:
    • API tests
    • Contract Testing
    • Integration Testing with real dependencies
    • End-to-End flows on each Pull Request Signadot runs tests with real data and dependencies in your pre-production environment to improve release quality.
  3. Local Previews: Developers can use Signadot to create end-to-end previews of their changes directly from their workstations. They can set up just the service under test locally and use dependencies and data from a shared environment. This enables rapid experimentation without the need to set up infrastructure, build Docker images, or push code.

Signadot installs into your Kubernetes cluster as shown in the architecture section and connects to a remote control plane. Test workloads are created and automated tests are run within your Kubernetes cluster.

Unlike other approaches to creating environments for testing that rely on duplicating infrastructure or deploying separate collections of microservices into a Kubernetes namespace/cluster, Signadot creates multiple "sandboxes" in the same shared cluster. For isolating these sandboxes from one another, it uses request routing and context propagation by leveraging standard components like Kubernetes networking, OpenTelemetry and optionally a Service Mesh as well. You can read more in detail about how this works here.

Some systems that resemble Signadot's approach of using a shared environment with request-level isolation include SLATE built at Uber and Staging Overrides built at Lyft.

Why Signadot?​

  1. Shift-Left Testing: With Signadot, you can set up tests to be run on each pull request finding API-level breakages, E2E issues, integration bugs, etc before merging code. This responsibility can be decentralized across the entire engineering team to detect issues sooner, provide feedback quicker and reduce burden on acceptance testing & QA.
  2. Stability of Pre-production Environment: Signadot ensures that no instability creeps into the staging environment which tends to happen when people test disruptively in the shared environment. Instead, everyone's changes are tested in isolation, thereby ensuring stability of the staging/pre-production environment, which in turn ensures high quality releases.
  3. High Quality Data, Real Dependencies, and No Mocking: With Signadot, developers and automated tests can access a testing environment that provides high quality data, real dependencies, and 3rd party APIs. This eliminates the need to maintain mocks as well as providing high quality testing signal.
  4. Unified Testing: Signadot is designed with the developer experience in mind. It provides a single platform for automated testing, previews and local testing. All of this is done within a shared pre-production Kubernetes cluster, eliminating the need for different tooling for each testing type which makes it easy to roll out across engineering teams.
  5. Lightweight and Fast: Test environments in Signadot are lightweight and quick to spin up, typically taking seconds to become ready. Additionally the test workloads and the tests are run resource efficiently within Kubernetes with minimal operational burden and infrastructure cost.