Build on deploy in VSTS
-
So, this is essentially an unsearchable question, because no matter what, you'll get eleventy-billion "deploy on build" results instead.
We have an app that builds, deploys, and releases through VSTS. I have set up a build with some tests that verify things about the current version of the backend. Therefore, it seems like the best time to run them is right after that is deployed. This seems like something that should be obvious, but I can't see a way to do it.
Does anyone know anything about this?
-
At work, we run a couple of selenium tests after Octopus has finished deployment. We have one huge build definition which does a couple of things:
- Build
- Run unit tests
- Package and push to Octopus
- Initiate deployment in Octopus and wait for completion
- Run selenium tests
Depending on your setup you should either change your build definition to include your post-deployment test steps (if your deployment is a build step), or you should add a test step to your release definition in VSTS if release gets triggered after a successful build is created.
-
@alexmedia said in Build on deploy in VSTS:
you should add a test step to your release definition in VSTS if release gets triggered after a successful build is created.
This sounds relevant.
-
Someone on my team found a release task for it!
-
If you're not using a dedicated "Run unit tests step", note that you can also run tests using whatever other VSTS tasks you have including shell scripts and then upload the test results to VSTS for an easy overview. You only need to make sure that the test results are in a JUnit or XUnit compatible XML format.
-
@jbert The problem is that I need to run code that isn't part of a deployment, after that deployment completes.
-
Maybe you can have your test code dropped as a build artifact and then run it from your release definition?
Or else, add a PowerShell step which downloads the code from somewhere else and then run it?
-
@alexmedia A release definition can require multiple artifacts / inputs, and one of the types allows to pull the contents from a source code repository (Git is likely the easiest one). Once you have those files you can still run Maven, MSBuild or whatever you require as part of your release definition.
Note though that I sometimes employ a trick where I download extra files and scripts from a Nuget feed. To do so, I have an inline Powershell script which spits out a package.config, then add a Nuget downloading task which reads that and stores the result in a specific folder.
VSTS does have a nicer way to do it with deep integration with VSTS-hosted feeds, but those features require a separate "Package Management" user license. The trick above can instead pull Nuget packages from any feed AND it doesn't require you to pay for VSTS package management (the latter is a bit of a WTF: you can state that your release def requires a Nuget package as artifact but somebody who has no license for Package Management cannot run that release).
