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.
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?