Deploying your tests to multiple environments

If you have multiple environments such as dev, staging and production, it's likely that you want to run the same tests in each environment. Although you could do it in the same project by duplicating your tests, Magic Inspector provides a better way to manage this: creating one project per environment.

Why use projects?

When you work with multiple environments, such as dev, staging and production, you most likely want to make sure that each environment is isolated from the others.

• The variables and secrets used by one environment are different from the ones used by another environment
• You can run a test in dev for a new feature that is not yet deployed to staging or production
• You can program a test to run in dev, staging or production but with different schedules since they have different requirements in terms of load, traffic and criticality
• You can create alerting rules to notify you of test failures in each environment (e.g. a test failing in production will be more urgent than a test failing in dev)

For all these reasons, projects are the best way to manage tests related to a specific environment in Magic Inspector since they match all the requirements mentioned above.

How to deploy your tests from one project to another

A typical workflow would be to push your tests from dev to staging and then to production.

To do this, you can use the Deploy to project button in your test list view.

Once you click on the button, you'll be able to select the project you want to deploy your tests to.

Case 1: The test has never been deployed to the target project

Here the blue alert indicates that the tests was never deployed to the selected project, so we have no conflict to worry about.

We can continue our deployment process and our test will be duplicated in the selected project.

There are couple of things to keep in mind here:

• The test will be duplicated but both tests will be linked. Which means later if you make changes to the test in dev, these changes will also be reflected in staging when you redeploy the test.
• All the variables, secrets, settings and other resources used by the test won't be duplicated. This means that if the test uses a variable, secret, you will have to recreate them in the target project manually.
• By default, the test wil be duplicated with the same name and URL. You can change the name and URL in the target project if needed and choose whether they will be re-overridden when you deploy the test again or not.

Case 2: The test has already been deployed to the target project

Later on, if you redeploy the test from dev to staging, Magic Inspector will detect that the test already exists in staging and will let you know if some differences are found between both tests (1).

It will be up to you to decide what to do in this case. You can either:

• Cancel the deployment
• Overwrite the test in staging with the one from dev

Magic Inspector will also show you the differences between the two test URLs (2) and names (3). You will be given the possibility to keep the current name and URL or override them with the ones from dev.