Make your life easier with Group Rules in Azure DevOps Services

This is something that comes in very handy - licence management isn't the simplest thing to implement and police. There is always someone who is going to try and sneak around the process in place, in order to quickly get access.

Group rules make this really simple. It's basically a templating model applied to the Azure DevOps licensing system:

In the example above, I created a rule for a fictitious Workshop - all my users will have a Basic licence (as they might not be Visual Studio subscribers) but they will be automatically added to the Project Administrators group.

This might feel simplicistic, but you can add as many projects as you like in a rule. Which means that creating these will help shape the organisation's management, especially in large companies - you can have Visual Studio subscribers automatically added to all projects, and Basic subscribers (which might be contractors for example) scoped to business unit (where costs are usually accounted for and split) for example.

If you are an Organisation Administrator, this will save you plenty of time 😁

Do you want to move to YAML pipelines? Here is how I would do it.

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.