Getting started with Azure DevOps -create a deployment group

This is part 7 of a multipart series on getting started with Azure DevOps. Please refer to the below links to access other notes in this series.
Part 1: Getting started with Azure DevOps
Part 2: Getting started with Azure DevOps -work items
Part 3: Getting started with Azure DevOps -add a repo
Part 4: Getting started with Azure DevOps -create a build agent
Part 5: Getting started with Azure DevOps -create a build pipeline -Part 1 (YAML pipeline)
Part 6: Getting started with Azure DevOps -create a build pipeline -Part 2 (Classic Editor)
Part 7: Getting started with Azure DevOps -create a deployment group (this note)
Part 8: Getting started with Azure DevOps -create a release definition

What is a deployment group?
In simple terms, a deployment group is a collection of machines (e.g. servers) that form a logical unit and can be expected to display identical traits -such as to form an environment. E.g. say you have a product that gets deployed to the following environments -Dev, Test, Stage, and Production. Then these 4 environments can be referred to as 4 deployment groups. Machines in a deployment group are mutually exclusive -one machine can only be in one deployment group.

In a usual setup (think tool agnostic), you’d have a continuous-integration (CI) build definition that creates a package ready to be deployed. A release script or orchestrator can be configured such as to deploy the artifacts of the CI build to an environment (aka list of machines). You can create an orchestration technique via a deployment script that pushes the packages to (say e.g.) 2 machines in the Dev environment. Now, say our product has undergone some change and instead of 2, we now have to deploy our package to 10 machines. The deployment script then has to be updated to accommodate the change.
Now, say you have not 1 but 40 release definitions to manage for various other components of the product. The deployment processes to deploy to 10 machines (belonging to the Dev environment) has to be updated in 40 release definitions. And then the same change would be required for the remaining environments -Test, Stage, and Production. Let me throw in some more variables -Imagine an environment that is dynamic where machines get added and removed to align with the changing needs of the products. In such a situation it becomes cumbersome and stressful to be able to allocate and manage resources without error. In Azure DevOps, we circumvent this issue via the usage of Deployment groups.
Typically a release definition executes a set of instructions (aka jobs) on the following -agent, agentless, or a deployment group; where an agent is a machine that triggers the job/s and a deployment group is where the jobs are executed. For now, let’s keep agentless out of the scope of our discussion.
How do you create a deployment group?
Inside your Azure DevOps project -> Pipelines -> Deployment groups

Give it a name that makes sense and will be easy to identify (considering you will have multiple deployment groups). I like to name them based on the purpose they will be fulfilling.. in this case acting as an environment, so I name the deployment group with the environment they will be serving. Hence names like “Dev”, “Test”, “Stage” and “Prod”.
Click on Add a deployment group and name it as “Dev” and create.
On successful creation, you get to choose what kind of machines will be part of the deployment group -Linux or Windows and the Registration script will be made available accordingly.

This image above is a registration script for a machine running Windows OS.
Copy and paste this registration script on an elevated Powershell command prompt on the target machine -the one that is going to be part of this deployment group. You will be prompted for credentials and tags that you would want to associate with the deployment group. Below is an image of a set of prompts when I added a machine to a deployment group at work (Not this example)

Once a machine is registered (in Window) you will see a new windows service running by the name VSTS Agent.

…and on the Deployment group -> Target, you will see this machine is listed.

Since I am demoing how to create a deployment group, I named the group as DoNotUse (and not as Dev as we had mentioned earlier) just so that no one from the development team starts using this deployment group. In an ideal world, if this was a development environment, I’d name this deployment group as Dev.
Now that we have a deployment group created, how do you link a release definition to a deployment group?
To create a new release definition -> go to Tasks and next to Environment 1 you will see ellipsis which lists three options. We select the add deployment group phase here.

What are the benefits of deployment groups?
According to me, these are the benefits:
-easy to manage environments like adding and removing machines on scale warrants no change to the deployment process
-increases productivity
-high trace-ability -what release definition was applied to what deployment group can be identified with a few clicks on the portal

Next, Part 8: Getting started with Azure DevOps -create a release definition

PS: I will cover adding a deployment group to a release definition and tags in a later note. For now, I am discussing the idea of a deployment group from an Azure DevOps standpoint.