Skip to main content
Welcome to the second project status meeting! In this session, we’ll investigate how our CI/CD pipeline inadvertently hit the production database and refactor it to use a dedicated test instance.

The Issue: Tests Pointing at Production

After wrapping up the first three tasks, Alice was pulled into an urgent meeting. Monitoring alerts revealed that the production MongoDB cluster had become sluggish and occasionally unresponsive—right after the team enabled GitLab CI/CD pipelines. Reviewing the pipeline, Alice saw two test jobs both connecting directly to the production database via environment variables:
Never run CI tests against your production database. This can lead to performance degradation, data corruption, and security risks.

Why Use a Dedicated Test Database?

Running tests against production can:
  • Introduce load and latency for real users.
  • Accidentally modify or delete critical data.
  • Complicate debugging because of shared state.
Instead, spin up an isolated MongoDB instance or use a mock service.

Using GitLab CI Services

GitLab CI/CD supports services—auxiliary containers that start alongside your job. You can:
  • Launch a database container (e.g., mongo:4.4)
  • Seed it with test data in before_script
  • Point your application to localhost or the service alias
Read more in the GitLab Services documentation.
Services are defined per-job. Each service runs in its own Docker container, linked to the job container.

Refactored Pipeline Configuration

Below is a revised .gitlab-ci.yml that replaces the production connection with a local MongoDB service:

Job Configuration Comparison


Further Reading and References

Watch Video

Practice Lab