YAML pipelines can be daunty, no question about this - especially if you come from a background where you come from a nice UI like the one for Build Pipelines to a plain text file describing the Pipeline itself.
Well, I feel it is daunty anyway :-)
But in a process of continuous improvement I am prone to leave the comfort zone to experiment, and this is how I feel after approaching YAML pipeline. It's a bit like Git, if you like...
So, first of all don't try to mix and match the two - always start afresh. It is double the effort to try to apply something like this in a brownfield situation. Be confident with it first, and then apply it to something else.
Once you remember that the file needs to be named azure-pipelines.yml...my best friend in this process is the YAML schema reference, it contains lots of useful examples to help you structure the pipeline and it contains the references to Bash, Script and PowerShell so you are not completely lost when you approach the task catalogue.
The documentation is now YAML-first, so it is going to be easy to follow. Start by replicating a simple .NET Framework build from the UI with YAML. Then try again with a small variation. You will quickly get the grip with it.
But it is long and tedious and time consuming. Which is why Microsoft decided to create the YAML assistant, a brilliant feature that merges YAML pipelines and the old UI-based designed.
If you need to add a task and you are not sure on what to do, show the assistant and select the task from there:
And you will be able to fill all the parameters like you would in a UI-based pipeline:
Once this is done, add it to the pipeline and you are done with it:
This is a very smart way of handling this, and over time you will find yourself going more and more to it.
Well, I feel it is daunty anyway :-)
But in a process of continuous improvement I am prone to leave the comfort zone to experiment, and this is how I feel after approaching YAML pipeline. It's a bit like Git, if you like...
So, first of all don't try to mix and match the two - always start afresh. It is double the effort to try to apply something like this in a brownfield situation. Be confident with it first, and then apply it to something else.
Once you remember that the file needs to be named azure-pipelines.yml...my best friend in this process is the YAML schema reference, it contains lots of useful examples to help you structure the pipeline and it contains the references to Bash, Script and PowerShell so you are not completely lost when you approach the task catalogue.
The documentation is now YAML-first, so it is going to be easy to follow. Start by replicating a simple .NET Framework build from the UI with YAML. Then try again with a small variation. You will quickly get the grip with it.
But it is long and tedious and time consuming. Which is why Microsoft decided to create the YAML assistant, a brilliant feature that merges YAML pipelines and the old UI-based designed.
If you need to add a task and you are not sure on what to do, show the assistant and select the task from there:
And you will be able to fill all the parameters like you would in a UI-based pipeline:
Once this is done, add it to the pipeline and you are done with it:
This is a very smart way of handling this, and over time you will find yourself going more and more to it.