Damian Brady

@joaofracasso:

I'd hesitate to put them in source control. I'd consider those the equivalent of build artifacts - i.e. the output of a training run.

With that in mind, a location like the @Azure ML model registry or even an artifact repository like GitHub Packages or Azure Artifacts would be a better place.

@kumar: From memory, you can set up multiple schedules. So if you need to run more than once per day, you can do it that way.
If you want to run every 5min though, it may be easier to set up an Azure Function on a timer (https://docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-timer?WT.mc_id=azurefunctions-ch9-dabrady) that hits REST API or uses the SDK to trigger a build (https://docs.microsoft.com/en-us/azure/devops/integrate/get-started/client-libraries/samples?view=azure-devops&WT.mc_id=azuredevops-ch9-dabrady).

@Dev: There are a couple of options.

You could deploy from one machine inside the firewall, however you'd most likely need to build a lot of your own plumbing and scripts, and you wouldn't be using Deployment Groups - simply a self-hosted agent that knows about other machines it needs to run scripts on. You could use network file copying and Powershell remoting or similar to do the actual work. Obviously there's a bit of work there that Deployment Groups manages for you.

However, your cost of $20 per self-hosted agent isn't _quite_ accurate. It's not priced per provisioned agent - rather per parallel job. So you could conceivably deploy all 450 agents, but only pay for 10 parallel jobs if you're happy to deploy 10 at a time. Or even a single parallel job if you are happy to deploy one at a time.

Check out https://docs.microsoft.com/en-us/azure/devops/pipelines/release/deployment-groups/howto-provision-deployment-group-agents?view=azure-devops&WT.mc_id=devopslab-c9-dabrady for more details on provisioning the agents, and https://azure.microsoft.com/en-us/pricing/details/devops/azure-devops-services/?WT.mc_id=devopslab-c9-dabrady for more pricing details.

Also, we're _just about_ to release another series of updated on-prem deployment episodes, so keep an eye out for those! They'll start to drop this week :)

I hope that helps!
Damian

@Liero

The pre and post deployment scripts are really the only way you can manage the process (or "tell it how to handle the migration").

Because it's a bit of a black box, it's going to do whatever it thinks is correct for updating the schema, but you can control things with these pre and post stages. For example, temporarily store data in a table then copy and remove it at the end.

Long story short, if you're not comfortable letting the tool make schema changes for you, then the model-based option is probably not right for you.

Hi @Liero,

SSDT can definitely be used in those scenarios, but it's not a magic bullet - you need to tell it how to handle the migration in cases like this.

SSDT has a data loss safeguard which will fail the deployment in cases where there will be data loss. If turned on, the deployment will fail.

It's generally good practice to run the migrations in earlier environments - you _never_ want the first time you run a migration to be in Production! In fact, that was the point of Houssem's last demo. He pulls down the production database into a pre-prod environment and runs the migration against it (then any tests to verify success), before going to production.

Of course, you can disable the data loss safeguard and provide pre and post deployment scripts to define what should happen to migrate data safely. There's a great article by Dan Nolan from Redgate about this: https://www.red-gate.com/simple-talk/sql/database-delivery/fix-ten-ssdt-deployment-snags-without-readyroll/

I hope that helps!
Damian

@liuning0820:No, you can use Docker Hub if you want!

Azure Container Registry is just a private registry you can run from Azure. A private alternative :)

@aptivadave: Yes, the agent that runs on the machine will run as a specific account. If you start it in interactive mode (i.e. run it manually) it'll be the account you're running as (I think). If you run it as a service, which is more common, you can change the user in Services in Windows directly.

@lestephane,@aptivadave:

Sorry I missed this!

The answer is that the SQL Server DACPAC deployment task is deprecated, but only for an agent deployment. The current guidance is to use Deployment Groups and the new SQL Server Database Deploy task, running it inside a Deployment Group Job.

The reasoning is it's easier (and safer) to run it on the database server itself for an on-premises database.

You can see more details in the links above, as well as here: https://docs.microsoft.com/en-us/azure/devops/pipelines/apps/cd/howto-webdeploy-iis-deploygroups.

Hope that helps!

Damian

@Martin Thornalley:Ah, those are just the internal editors of the show rather than who's in it :)

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