Service Virtualization

  • 1.  What needs installing for the CLI to work?

    Posted 09-24-2015 05:02 AM

    I want to start automating deployments. We store our virtual services in Stash (front-end for git) and use Jenkins for automation (Stash will notify a Jenkins job upon commit to our master branch). I think I'd need to get the VSEManager CLI command installed on the Jenkins server - but does it have any requirements? Do I need the full LISA install to be done on the server, or can I copy only the VSEManager exe file and that will work? Do any environment variables need setting?

     

    Is there a difference between the "deploy" and "redeploy" switches? I don't want to have to run commands to see if the virtual service is already published so that I know to run "--redeploy" instead of "--deploy", I'd rather just do "--deploy" and have it automatically replace if it already exists.

     

    Also, if you have any helpful hints from when you integrated using the CLI for automated deployment, that would be appreciated.



  • 2.  Re: What needs installing for the CLI to work?
    Best Answer

    Posted 10-01-2015 06:37 AM

    Here's what I found. I'm using v7.52 of LISA.

     

    VSEManager needs to run in a full LISA environment, you can't just copy the executable to another server.

     

    Using Powershell you can remotely invoke VSEManager using:

    Invoke-Command -ComputerName $myVSEserver -ScriptBlock $sb

    where my scriptblock is the normal command line (e.g. "VSEManager.exe --registry http://myreg --vse http://myvse --username=user --password=pass --deploy c:\tempDeploy\myvs.mar"), and I copy the mar file to the VSE server filesystem before I run the invoke. So, you run the VSEManager in the context of the VSE environment, and it works.

     

    If you are redeploying a virtual service which has already been deployed to the VSE, you must use the --redeploy switch: you need to query the VSE first to get a list of deployed virtual services, parse this and determine if the virtual service has already been deployed. If you use --redeploy on a new virtual service, it won't deploy and you will get an error. If it's a new service you must use --deploy: using --redeploy will cause an error.

     

    I'd like to only use a "--deploy" command because I don't want to have to send a call to the VSE server just to find out if an old version of the virtual service has already been deployed - it's unnecessary because I don't care if it's already been deployed, I'm either going to deploy it or redeploy it to replace the old version anyway. Issuing a --deploy command and then trying a --redeploy command if the --deploy fails isn't right. Attempting to delete the virtual service from the VSE prior to a deploy also isn't right.

     

    The Invoke REST API works simply by deploying a virtual service whether it has already been deployed or not, which is more efficient behaviour. It would be better if VSEManager mirrored this behaviour - is there any benefit to having separate --deploy and --redeploy commands, where only one will work in any situation? The user's intention in both cases is to deploy a virtual service to the VSE - who does it matter to if it was a new or existing service that you replaced?