Continuous Integration Testing: Fully Test your Microservices Application, Early and Often
summary
Shows a concrete pipeline: it builds container images, tags them with a test-run ID, deploys the artifacts and runs a simple shell check across four environments — docker compose on a self-destructing VM (4h), a shared staging cluster using Kubernetes namespaces, a single-node k3s VM, and full per-test GKE clusters — then either tears down resources or snapshots failed workers for debugging; uses Jenkins to orchestrate provisioning, deployment, and cleanup, and balances fidelity, isolation, speed, ephemerality, and cost.
AI-written summary · about
chapters (23)
- 0:00Intro
- 0:30Shift Left
- 2:05Shifting left is good for your business
- 2:34Ideal test pyramid
- 3:03Actual test pyramid
- 3:22Integration testing is hard
- 4:01Why bother?
- 6:57We can still do integration testing
- 7:33Maximum Fidelity?
- 7:57Isolation
- 8:56Speed
- 9:10Scalability
- 9:56Ephemerality
- 11:06An example
- 12:39Integration test flow
- 13:51Self-Destructing VM?
- 14:35Technique 1: Docker Compose
- 15:40K8s Staging Cluster
- 17:23Single-node "K8s"
- 18:35K8s cluster per test
- 22:50Integration testing techniques
- 24:35But Dave, what about...
- 27:36Yes, we can (still) do integration testing
related talks
26mContinuous Integration Testing
31mContinuous Integration Testing
42mUse Docker to test microservices
01h 06mContinuous Integration/Continuous Delivery for Microservices: Rule them all
40mMicroservice Continuous Delivery
27mMicroservices Are ‘Easy’, Dependencies Are Hard
24mOrchestrating automation tests for Continuous testing
53mMicroservices Lifecycle Through Docker an CD