MLflow with Azure Machine Learning

I'm an Australian Cloud Developer Advocate specializing in DevOps. I'm currently based in Toronto, Canada, but will be moving back to Australia - the land of the dangerous creatures and beautiful beaches - in 2018.
Formerly a dev at Octopus Deploy and a Microsoft MVP, I have a background in software development and consulting in a broad range of industries. In Australia, I co-organised the Brisbane .Net User Group, and launched the now annual DDD Brisbane conference. I regularly speak at conferences, User Groups, and other events around the world, and I've been an occasional guest on various podcasts like .NET Rocks and Hanselminutes.
Most of the time you'll find me talking to developers and IT Pros to help them get the most out of their DevOps strategies.
Follow me on Twitter at https://twitter.com/damovisa
Comments
What parts of an ML project should be in source control? | One Dev Question
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.
Real World Scenario Testing using Azure DevOps and automated UI tests
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).
Deploying to On-Premises Servers with VSTS
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
Verifying your Database Deployment with Azure DevOps
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.
Verifying your Database Deployment with Azure DevOps
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
Running your First Docker Container in Azure
@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 :)
Deploying Database changes alongside your code with SSDT projects and VSTS
@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.
Deploying Database changes alongside your code with SSDT projects and VSTS
@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
DevOps for Data Science
@Martin Thornalley:Ah, those are just the internal editors of the show rather than who's in it :)
Deploying to On-Premises Servers with VSTS
@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:
Unit Testing your Database Changes
@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.
Deploying to On-Premises Servers with VSTS
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.