Hi @sandy311 ,

Testing on production is generally not recommended. The ideal approach is to have separate environments, such as Dev, PreProd, and Prod, which allow for thorough testing before any changes are deployed to production.

Assuming you are deploying your pull request to a "target" environment (which could be production or another environment), here are two strategies you can use:

Strategy 1: Use a "Pre-Target" Environment for Testing

1. Create a Pre-Target Environment: Set up a testing environment (PreProd) that closely mirrors your target environment (Prod or another critical environment).
2. Deploy the Pull Request to Pre-Target: Deploy changes from the pull request to the Pre-Target environment.
3. Run Tests: Execute your job tests in the Pre-Target environment to ensure that the changes work as expected.
4. Deploy to Target if Tests Pass: If the tests are successful, proceed to deploy the changes to the target environment.

Strategy 2: Use a Rollback Mechanism in the Target Environment

1. Deploy to Target: Deploy the changes directly to the target environment.
2. Run Tests on Target: Execute job tests in the target environment.
3. Handle Results:
- If Tests Pass: Keep the deployed changes.
- If Tests Fail: Roll back to the last known good configuration (e.g., main branch, previous release).

These strategies help maintain stability in your production-like environment while ensuring your new code is tested thoroughly before any critical deployment. 

In summary you do not want to keep multiple versions of the same job (stable-old and untested-new) on the same environment. The best practice here is to have a separate environment to test your pull request.