Among the news and announcements from Connect() you surely saw YAML Build Definitions mentioned, and you might wonder – what’s coming? How does this fit into the overall TFS/VSTS product?
Let’s start from the past, from 2011 – this UserVoice request asks for something that enables versioning for Build Definitions.
Being 2011 many things weren’t as available or as robust as of today, and the current Team Build was not remotely on the horizon. Fast-forward six years, and we’ve got YAML Build Definitions.
Didn’t we have a way of tracing Build Definitions without YAML? Really? Six years to implement some kind of traceability? Well…:
There is a built-in Compare Difference feature in both TFS and VSTS, and you can export your Build Definitions in a JSON file. So no, it is not just about traceability.
In the age of Continuous Delivery, Infrastructure as Code is critical. It saves an enormous amount of time and resources, and it is an extremely reliable way of automating the build and release process.
That is where YAML Build Definitions fit into the equation: they represent the concept of Infrastructure as Code pushed to the limit. You are not just treating the deployed infrastructure as code, you are also adding the deployment infrastructure in this definition, where as long as you have the required resources at your disposals (agent queues, build tasks, etc.) you are good to go.
This also does not mean the current Build Definitions are leaving – YAML is just for the Build Definitions, but the underlying technology is still the same. Also, with YAML you don’t get a visual breakdown of the tasks of the Build Definition:
It is a different way of doing the same thing – it might not cater for everybody (I am a big fan of the current Definition UI because it makes it understandable for everybody regardless of the expertise and the role), but it adds options for someone who needs a different experience and has different requirements.
At the end of the day, the more the better
