If you have not at least evaluated Azure DevOps Projects, it's time to stop hiding under a rock and take them for a spin. But why?

All services | DevOps | DevOps Projects

Early this morning I made a TODO list for a couple of proof-of-concept CI/CD pipelines. I stared at a variation of applications using .NET, .NET Core, App Services, and the WhiteSource Bolt (topic of an upcoming post), and demolish the plumbing once done.

How can I create Azure environments that are compliant with best practices? How can I create the environments consistently, without making a silly error that invalidates an experiment? How do I know which Azure resources to delete once we're done?

Simple! I created six DevOps Projects in Azure, They were assembled behind the scenes, while I was enjoying a quick de-stress walk and a cup of Orange Camomile tea :)

When I returned, I had six VSTS team projects, six CI/CD pipelines, and Azure resources. All compliant with the best practise guidelines from Microsoft and all validated with an automated build and deployment. Wow!

Once the proof-of-concept hypothesis were proven or disproven, I deleted the DevOps projects, which unwound all artifacts behind the scenes. Wow!

To summarise, here are a few great opportunities to consider DevOps Projects:

You need to quickly spin up a few proof-of-concepts in Azure

You need to create projects in Azure, based on best practise guidelines

You would like to explore a variation of Azure projects, for example Web App, Web App for Containers, Service Fabric Cluster, Kubernetes Service, or the good old virtual machine

"Build any Azure application, on any Azure service, in less than five minutes" - Microsoft, https://azure.microsoft.com/features/devops-projects/", based on one of the proof-of-concepts.