Since I wrote about my ideas for VuGen add-ins, a few people have spoken to me about their need for an add-in that would integrate VuGen with their revision control/source code management system.
The interesting thing is that when I ask what version control features they are missing, they don’t have any specific features in mind (unless you count “backups”, which has nothing to do with version control). Most fall back on “VuGen scripts are source code, and all source code should be managed in a version control tool”.
Well, VuGen 11.50 allows basic version control features (check in/out, version history) when integrated with ALM. Is that good enough, or are there still features missing?
Common features/benefits of Version Control tools:
- It is a central repository of source code.
- It gives you a change history, which shows you what changes have been made, when they were made, and who made them.
- It allows branching and merging (hopefully with atomic commits), so multiple people can work on the same codebase at the same time, or multiple branches of the codebase can be maintained in parallel.
- It gives revision IDs that uniquely identify a version of the source code.
- It provides access control to source code.
Personally, I don’t really need most of these features, or they already have a simple solution (e.g. network share drive and a diff tool). VuGen scripts are generally trivially simple, worked on by a single person, and are throw-away code (due to tight coupling with the application under test).
The feature that I most want is the ability to see exactly what script was run for a specific test, so I can see if there have been script changes that could be the cause of different performance characteristics between tests. A LoadRunner Analysis file includes the name of the scripts used for the test, and their runtime settings, but does not include the script (*.c) files or the parameter files.
Adding version control to VuGen doesn’t help me, because script versions are irrelevant unless they can be directly linked to a test results file. So, for me, the solution is not to add version control into the development tool, but to add audit logging to the LoadRunner Controller, so that a copy of the VuGen script used for the test is stored with the LoadRunner Results/Analysis files.
Related Posts
7 Comments
Comments are closed.
The ALM version control is no good to me because
1. The company I work for does not have ALM
2. I need to use the same version control tool as the dev team
Hi Stuart,
How do you add audit logging to the LoadRunner Controller?
As currently, I am thinking of whether can track which script(.c) is used for different tests.
Currently there is no audit logging feature for the LoadRunner Controller – but it would be great if HP would add it.
Your Analysis file will contain the names of all of the scripts used for the test (along with their runtime settings – look under the File menu item), but the source code for the script is not saved, so it may have changed between tests.
To be honest, once you have architected your scripts and identified what is critical, SVN works quite well. In the environment I am in at the moment however version control built into LR would be a god send as the scripts we use here are long life and are often run in a ‘performance regression’ scenario
Would you find it more useful to have version control built into VuGen (check-in/check-out for scripts), or to have it built into the LoadRunner Controller (so you have a definitive record of exactly which script versions were used for each test)?
Just started with LoadRunner and came across this thread. For our purposes, the tests need to be version controlled with, or at least parallel to the product code. Since we want to run a standard performance suite against each release, we need to check out the scripts regularly, and VuGen seems the place to do that. I agree that the scripts need to be correlated with results, but since results are already correlated with the release, we would get that “for free”. I am looking for a good solution for LR/Accurev. Or at least LR/MSSCI, so I could create my own integration.
This is stupid. The feature you want is provided by version control in combination with an appropriate CI/CD pipeline, and yet you keep saying you don’t want that.