The last scene in which we will run the E2E tests is after we deploy the build to the staging environment. Instead of using a Maven command, we will use the npm run test:staging-e2e command to start the E2E testing.

Since the staging environment is close to the production environment, when a test fails on staging, it will most likely fail on production too. In practice, we will keep the staging environment up and running, so that when there is a test failure, we can investigate it by going into the servers to find out what went wrong.

One drawback of using the staging environment as the E2E test environment is that we cannot have multiple builds running at the same time, otherwise, they will overwrite each other when they deploy the build to the staging environment. Everybody else has to wait until the current build finishes.

To solve this, instead of deploying a build to the staging environment for E2E testing, we can spin up an isolated refresh E2E test environment and shut down that environment when the E2E testing is done. In case there is a failure during the test, we will keep the environment up for the investigation of the issue and shut it down manually after locating the root cause. With this approach, we would still need the staging environment for other purposes, such as verifying an integration with a third party before rolling it out to the production environment. 

Our recommendation is to start by performing the E2E test on the staging environment. When you have so many builds in parallel that using the staging environment for the E2E test is no longer applicable, then switch to isolated E2E test environments.

The following screenshot shows the commit record of the refactoring of the Maven build process: