CA DevTest integration with CI/CD Pipeline
Article ID: 95152
Updated On:
Products
Issue/Introduction
Would like to understand if CA DevTest has any issues or limitations to integrate with the CI/ CD Pipeline.
From a DevTest API testing & SV artifact standpoint, would like to accomplish the following as part of the CI/CD pipeline:
Create a Project Commit and push changes to a repo (say BitBucket) .
Create branches by multiple resources for DevTest Project Make artifact changes against each branch ( VSI, VSM, .tst changes etc ) , commit, push the changes to remote repo.
Resolve any merge conflicts
Environment
All supported DevTest releases.
Resolution
DevTest does not support source control, does not integrate with any source control tools. Any source control would need to be done outside of DevTest where the artifacts are checked in manually.
Feedback from Pre-Sales and Services. Their Comments:
There’s no technical integration required to perform revision control, but there are probably some required practices based on DevTest project/file structure. For example, one possible caveat is that performing a merge of individual tst, vsm, or vsi files could (educated guess) corrupt the files beyond DevTest’s ability to read them – or at least beyond our ability to support the potentially quirky behavior that might result from a merge. It seems like a safe practice to manage all changes to tst, vsm, and vsi files from within DevTest and then to commit all changes within the project folder to the versioning system as a whole (as opposed to selectively committing changes to individual tst, vsm, and vsi files).
Other than the potential risks mentioned above, management of DevTest assets in a version control system (branching, commit, push, etc.) should follow the same basic principles as anything else and would be managed from outside of DevTest using, e.g., Bitbucket, git, Subversion, etc. directly. Automated deployment and management of virtual services on the VSE, can be accomplished via the various RESTful APIs we expose, and which can easily be invoked through any enterprise-grade CI/CD automation tools like CDD and ARA.
DO NOT branch and merge – only fork. No exceptions. DevTest artifacts don’t merge well – resolving conflicts would be a nightmare. However, there are legitimate times when you want to make a new recording and add the new transactions to an existing VSI. Use ServiceImageManager.exe for that.
DO NOT branch / merge VSIs using the source control system. DevTest contains an internal numbering structure that can be corrupted making the SI unreadable. Develop an approach to verify the merged asset after using SI Manager.
Be sure to backup *.rsp files, they contain essential information for design time.
It’s not necessary to version *.mar files – it’s the equivalent of versioning compiled *.class files. They can be quickly regenerated from source, and VCS’s don’t deal well with binary files.
Consider versioning site.properties, local.properties, and dradis.properties on the server (in case a server config needs to be rolled back).
Was not able to get any further information on the below question:
1. As Forking is the recommended option, is merging the fork to master repo a recommended solution or merge is never a recommended solution ?
Refer to section "ServiceImageManager Command - Manage Service Images" in the version of DevTest you are using.
2. Are there any Demos /videos around using ServiceImageManager.exe and invoking ServiceImageManager.exe via command prompt using a syntax to pass two files and auto selecting yes to merge the files.?
I could find no videos.
It is suggested to post these additional question on the DevTest Communities webpage: Welcome to Service Virtualization Community!
Feedback
