March 13th, 2020

Top Stories from the Microsoft DevOps Community – 2020.03.13

Steven Murawski

Principal Cloud Advocate

Hey y’all! Happy Friday the 13th! While there’s lots of discouraging things out on the interwebs lately, we have some great examples of how to continue to deliver software. From build pipelines and shared definitions to custom release notes to caching, there’s a lot of great content this week.

How to Preview and Test a Changing YAML Pipeline on Azure DevOps
Working with a YAML build definition can be frustrating when syntax errors block our progress. Sebastian shares a neat way to use an API in Azure Pipelines to validate the YAML build definition.

pipeline_templates Project
Nick brought my attention to a project where they are gathering useful build definition templates. It’s a nice resource if you are doing Xamarin development.

Build & Release a Container Image from Azure DevOps to Azure Web App for Containers
Steve provides an thorough walkthrough of how to build and deploy a container image from Azure Pipelines to Azure Web App for Containers – and yes, Azure Web App will run your container!

A major new feature for my Cross-platform Release Notes Azure DevOps Pipelines Extension–Handlebars Templating Support
Richard describes a new templating language capability in his release notes extension. Release notes can be an awesome thing and I happen to like the handlebars template syntax.

Caching (not only) NuGet packages on Azure DevOps
I love caching! And I hate caching! Krysztof introduces the Cache@2 task.

If you’ve written an article about Azure DevOps or find some great content about DevOps on Azure, please share it with the #AzureDevOps hashtag on Twitter!

Author

Steven Murawski

Principal Cloud Advocate

Steven Murawski is a Principal Cloud Advocate focused on Cloud Native Open Source. Steven is a founding member of the League of Extraordinary Cloud DevOps Advocates). Steven has worked on both the Dev and Ops sides of the house, most recently as a Principal Engineer at Chef, building tools for operating applications and infrastructure at scale and velocity.

1 comment

Discussion is closed. Login to edit/delete existing comments.

Sort by :

Newest

Newest Popular Oldest

Andrew Stanton March 22, 2020 0

From the first link...

One problem still comes:
Change YAML -> commit -> run -> fail -> Change YAML -> commit -> run -> fail…

The problem is the commit. The new "classic" build system was great in that unlike all the previous systems (XAML, its fatter predecessor XAML, that weird msbuild tfproj thing from 2005/2008) it didn't require checking in code just to package the software differently as it evolved or...
Read more
From the first link…

One problem still comes:
Change YAML -> commit -> run -> fail -> Change YAML -> commit -> run -> fail…

The problem is the commit. The new “classic” build system was great in that unlike all the previous systems (XAML, its fatter predecessor XAML, that weird msbuild tfproj thing from 2005/2008) it didn’t require checking in code just to package the software differently as it evolved or needed to react to some emergency.

This same checkin/commit churn problem still hounds people who think they need to change version control just to bump up a version number.

I dont have to do either of these time wasting churn checkins/commits with the the “new classic build system”. If you wanted portable definitions, you could have spent less time doing that for the new classic than it took to build a crummy, cryptic, structured text based definition system. Shoot, you could have even changed the build definitions backend storage to be YAML instead of JSON and still gave those must-have-everything-in-a-text-file folks the thing they wanted. I’m pretty sure that there are links on the tasks to view the YAML, even. Writing a new build pipeline system thats totally incompatible with the existing one when the existing one was fine is just a repeating one of the more expensive mistakes in software.

When are these top stories going to start telling scary stories that could have happy endings? Like how forcing YAML defintions will put most of your customers in undesirable positions whether they remember it or recognize it now or not, or how the constant unannounced build agent updates randomly start to break builds, or how we need to retain every build indefinitely now for fear of another devops bug that will delete our entire build history and all the version labels those builds had applied to specific changesets in version control? I dont see any of this kind of feedback ever materialize into something that would have directly prevented it. Those are the stories I am keen to hear.

Read less