Here is the AUT workflow across environments:

Code moves (and gets stable) from dev > QA > Stage > Prod

Data moves (and gets dirtied) from Prod > Stage > QA > dev

We have Performance Test scripts in LoadRunner (or JMeter) along with Jenkins with the corresponding plugins (HPE Automation Tools and Performance plugin for Jmeter) configured to run against Stage whenever a new build is deployed to Stage.

The run almost always fails due to the fact that scripts would need to get updated for: Front end changes & Data changes. At this point, we fix the scripts immediately and run the test, publish the results - all manually. We feel this defeats the purpose of having the pipeline in place.

I am thinking of a solution in which we can update the scripts based on QA (once the build is deployed here before it gets deployed to stage) and then update the scripts again by running it against Prod (carefully, of course) for data updates and then set it up to be triggered by Stage Job at Jenkins end. This seems like a very cumbersome process.

My question is - are there any alternative solutions to this? Do you see problems (other than touching Prod, which rarely happens in reality) in this approach?

How do you handle CI/CD/CT Using Jenkins (we can also use IBM uDeploy/urbancode as well) and LoadRunner/JMeter in a multi-environment situation like above? Are there any Best Practices documentation out there which we can refer to?

  • I may be missing something in your description but if additional manual changes are needed following the deploy to staging I don't think your biggest problem is how to run performance tests, it's how to create a reliable automated deploy of the app. – Cherree May 31 at 8:28

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.