A testing environment is a separate operational context for testing infrastructure changes before production. It isolates changes, supports dynamic testing against live resources, and provides a safer place to identify, fix, or revert broken configurations. section 6.1.3 section 6.1.2
A useful infrastructure testing environment should:
- Match production as closely as practical so test behavior provides an accurate view of production behavior. section 6.1.3
- Remain separate from application development environments and persist rather than being recreated for every test. section 6.1.3
- Capture important production dependencies and complexities without requiring every production resource to be recreated for each test. section 6.4.2
- Support infrastructure module isolation, integration tests, end-to-end tests, and security or compliance checks. section 6.1.3 section 13.1.2
A typical infrastructure delivery cycle keeps static analysis, applies the change to testing, and runs dynamic, integration, or end-to-end tests there. After successful tests and review, the change moves to production, where end-to-end or dynamic tests can be rerun. Continuous delivery automates this promotion path and can pause at a manual approval gate. section 6.1.3 section 7.1.2
Testing a DNS change
An integration test for a DNS A record should run against a persistent testing environment when the record depends on an existing server IP. Update the record through infrastructure as code, verify that testing DNS matches the expected configuration, and promote it only after the test passes. Creating and destroying the server and record for every test could take too long or affect applications. section 6.4.2
Testing environments also expose operational trade-offs. Differences from production can let a change pass testing and fail after promotion, so troubleshooting should check drift, dependencies, and environment discrepancies. Persistent environments improve fidelity but cost money to maintain; infrequently used performance environments may instead be created from production configuration on demand and removed afterward. section 11.2.3 section 12.3.1
Figure 6.5 You can run a static and dynamic analysis of infrastructure in a testing environment before applying the changes to production.
Shows static and dynamic infrastructure analysis in a testing environment before production promotion. section 6.1.3
Figure 6.11 You can run integration tests against a testing environment with long-lived resources to isolate the changes from production and reduce the dependencies you need to create for the test.
Illustrates integration testing against long-lived resources while isolating changes from production. section 6.4.2
Figure 11.7 Check for differences between testing and production to reconcile any tested changes that fail.
Supports diagnosis when tested changes fail in production by comparing the two environments. section 11.2.3
