Context So you have a typical project with a backend API and a frontend app built with React or Angular. You want to ensure that every time you push changes to production, they are thoroughly tested and deployed. To achieve this, you set up a CI/CD pipeline that handles the building, testing, and deployment processes automatically. At first, everything works smoothly, but as your project grows, you notice the pipeline is taking longer to complete.

So, you have database changes—either schema or data changes—that need to be implemented and rolled out across various environments. One approach could be to connect directly to each database server and execute scripts. However, you might not—and indeed, probably should not—have direct read/write access to certain environments like beta or production. Additionally, consider if a client posed the following questions; would you be able to easily respond? What is the state of the database in our Production environment?

The end-to-end tests set-up described in my previous post, is a series of docker containers that talk to each other. This set up is nice because, it will run on any machine. This allows you to test your app locally or in CI/CD pipeline. In this short post, I show the set up I used to run end-to-end tests. Docker compose set up In order to spin up containers locally or do so in the CI pipeline, and to run just the “smoke tests” or for all tests, I created multiple docker compose files.

In this post, I will provide a thousand-foot overview of how to run end-to-end tests in your CI/CD pipeline. In future posts, I plan to write up the details, challenges encountered, and solutions. I will show how the end-to-end tests were set up in the CI/CD pipeline. End-to-end tests verify the entire application, including the front-end, back-end APIs, and the database. These components had to be up and running in the build agent and play nicely with each other.