Damian Brady

@Doug: These tasks are now only available for Deployment Groups - i.e. you need an agent on the machine to do the deployment. The advantage is no potentially tricky remote connection issues! You can find info here: 

• https://github.com/Microsoft/vsts-tasks/blob/master/Tasks/SqlDacpacDeploymentOnMachineGroupV0/README.md
• https://github.com/Microsoft/vsts-tasks/blob/master/Tasks/IISWebAppDeploymentOnMachineGroupV0/README.md

@Noe: Good question!

The part we didn't really show (and probably should have) was that all of this testing can run in your pipeline. Just as you should run your code unit tests in your IDE before commiting, you can do the same with database tests.

Are you talking about using Release Management in TFS rather than VSTS? If so - it will work if you're on a recent-enough version (the docs say TFS 2018).

If you're talking about whether you can do this from VSTS/TFS Build (rather than Release), the answer is no. Deployments should really be handled with Release Management (or another tool if you like) rather than Build - separating the creation of an artifact and actually deploying and promoting it between environments is really important in a good DevOps strategy. There's some good information about why on the 12 Factor App page.

@Chris Eelmaa:

Hi Chris,

The version number for the release is tied to the version number of the Nuget Package pushed to Octopus. Using OctoPack means the Nuget Package version (in this case) is given the version of the assembly in the project being compiled.

You can set the Release numbering format in the Project Settings page in Octopus Deploy.

I hope that helps,

Damian Brady