Set up Tests in CI
Overview
Maintaining service reliability during rapid development requires automated testing infrastructure that can validate changes early in the development cycle. This guide demonstrates how to integrate sandbox testing into your existing CI infrastructure, enabling teams to validate service interactions before changes reach shared environments.
Implementation Steps
1. Set up Sandbox Infrastructure
Before configuring test automation, ensure you have sandbox infrastructure in place following the Pull Request Sandboxes guide. The test infrastructure will integrate with these sandboxes.
2. Configure Sandbox Access
Once a sandbox is created, you'll need to configure access from your CI environment. There are two primary approaches:
Direct Access with Routing Headers
For services that are accessible from your CI environment, you can add routing headers to your test requests. Here's an example using one of the supported headers:
curl -H 'baggage: sd-routing-key=<sandbox-routing-key>' \
http://your-service.example.com/api/...
The exact header to use depends on your service's instrumentation library. By default, Signadot supports OpenTelemetry standard headers, but your services might be using other propagation standards. See our header propagation guide for details on supported headers and configuration.
Most test frameworks provide ways to configure headers for all requests:
- Configure HTTP client interceptors
- Set up default headers in your test configuration
- Use middleware or request wrappers
This ensures all test requests include the necessary routing information to reach your sandbox environment.
Local Proxy for Internal Services
For services not directly accessible from CI, use the Signadot Local Proxy:
# Start proxy for specific sandbox
signadot local proxy --sandbox <sandbox-name> \
--map http://internal-service.namespace.svc:8000@localhost:8001
The proxy will:
- Forward requests to internal services
- Automatically inject routing headers
- Enable access to services inside the cluster
This is useful when:
- Testing services not exposed outside the cluster
- You need to access internal endpoints
- Your tests require direct service communication
3. CI Pipeline Integration
Integrate sandbox testing into your CI workflow:
# Example CI pipeline stage
test_stage:
script:
# 1. Create sandbox
- sandbox_id=$(signadot sandbox apply -f .signadot/sandbox.yaml)
# 2. Export routing information
- export SIGNADOT_ROUTING_KEY=$(signadot sandbox get $sandbox_id -o json | jq -r .routingKey)
# 3. Run tests
- ./run-tests.sh
# 4. Cleanup
- signadot sandbox delete $sandbox_id
For teams requiring sandbox-aware test execution within Kubernetes, refer to our guide on Using Signadot's Test Runner.
Infrastructure Best Practices
Resource Organization
Maintain test infrastructure configurations in version control:
.signadot/
├── sandboxes/
│ ├── pr-sandbox.yaml
│ └── feature-sandbox.yaml
├── testing/
│ ├── config/
│ │ ├── test-env.yaml
│ │ └── routing.yaml
│ └── scripts/
│ └── setup-test-env.sh
Test Environment Strategy
Choose an approach that balances control and maintenance:
-
External Test Execution
- Use existing CI infrastructure
- Maintain full control over test environment
- Leverage existing CI/CD tooling
- Ideal for standardized testing patterns
-
Kubernetes-Native Execution
- Use Signadot's test runner
- Automated resource management
- Built-in sandbox awareness
- Best for specialized testing requirements
Start with external execution for established CI workflows, considering Kubernetes-native execution as testing patterns evolve.
Conclusion
A well-configured test infrastructure enables reliable, automated testing of sandbox environments. This approach provides:
- Integration with existing CI/CD workflows
- Flexible service access patterns
- Standardized testing infrastructure
- Scalable automation capabilities
Focus on establishing standardized patterns that teams can easily adopt and maintain.