There are so many topics to cover in Azure DevOps that even three articles are not enough to cover all the features that could help our current scenario. Our goal in this article is to add a second environment (in our case, PROD) where we will be updating the virtual network that originated this entire series. We will check how to see the changes on either Azure Portal or Azure DevOps Portal, and our last topic will be the ability to add approvers before moving changes to our higher environments. If you missed any of the series, you can check out part 1 here and part 2 here.
Adding the PROD environment
The first step is to edit the existent pipeline, and underneath the existing DEV, click on Clone. We are going to label the new stage as PROD.
The second step is to introduce new variables that will manage the PROD environment, and we will follow the same naming convention that we have created previously. The result will be like the image being depicted below.
The last step is to edit the Task that updates the resources in the new Stage. We need to change all variables to PROD instead of DEV. When complete, click on Save.
When running a new release, it won’t change the current production because the resource already exists in our production resource group. We can see the deployment of both Stages (in our scenario environments) in the pipeline.
Changing the infrastructure and answering some nagging questions
At this moment, we have a release pipeline that is configured with both environments. Because we exported the configuration of the PROD environment, when we apply the same settings, we can’t see any difference because there are no changes.
We can start introducing a simple change – creating a new Subnet. We will name it as Web and assign the 10.10.20.0/24 IP range to it. Save it and commit to the master branch, and that will trigger a new deployment automatically.
The results? Sweet consistency! At least in infrastructure-as-a-code, we can be fair and square among all subjects of our kingdom. In the image below, the PROD environment has two subnets on its virtual network.
The second change will be the rename of the Servers subnet to App subnet, just the label and not the IP configuration. Save it and commit to the master branch, the results will be the changes applied to both environments and the Servers being renamed to App.
Even a rename from the ARM perspective is a deletion of the existing subnet and the re-creation. The renaming process does not work when the subnet that is being renamed has connected devices to it.
When removing the App subnet, the results will be a virtual network with a single subnet (Web). We must be cautious because it may impact production, and that is an excellent reason to validate and have a second team to double-check all changes and possible effects of any changes.
Auditing the changes
Now that we have a process in place to move from a simple change in an ARM template to a full-blown DEV and PROD. Our next logical step is to understand which tools are available that will support us in understanding the tasks being performed by the pipelines.
The first stop of our journey is the Activity Log feature. Using this feature, we can see the exact changes performed at the resource level, and that gives us an idea about the actions implemented by Azure DevOps.
All changes coming from the Azure DevOps will be authored by a Service Principal identity, which contains the Project Name as a suffix.
In the Activity Log (Item 1) of the virtual network, a list of all activities that happened on the control plane of Microsoft Azure are going to be displayed (Item 2), click on the desired event. We have three tabs (Item 3) where we can see a summary, the actual JSON file, and the Change history, which is in preview but helps a lot explaining what action has occurred, and a comparison between the previous and new values.
The second stop is at the repo level. Azure DevOps keeps track of all commits to the repository files, which includes who committed the changes and their comments, as well as their deployment status. If something goes to production, you can use this area to narrow down who changed the code responsible for updating your resources.
Our third stop is to check the historical data in any given release. A list of all releases will be listed under the Releases. I will play the role of Captain Obvious here, but all information on the release (including variables and tasks settings) is from the time when the release was deployed. You can use that to compare variable changes among different releases for troubleshooting purposes.
We can start validating the given release by checking the History tab, in the new page the status of every stage, who created the release and what action was used to trigger it will be informed.
The next step is going over the Pipeline tab. We can click on any stage (in our case PROD), and a summary of the tasks can be easily seen in a human-readable format. Check the commits and work items. We can dig deeper and check the logs of every single step, and they are accessible using the View logs link.
Controlling the changes in production
Azure DevOps is a fantastic tool from start to finish, and there are several mechanisms that we can implement to control how the code is moved into higher environments. A couple of them are gates and pre-approval.
To configure approvals in our production environment, edit the existing release pipeline, click on the Pipeline tab (Item 1), then on the lightning bolt icon. In the new blade that will appear on the right side, enable Pre-deployment approvals and select a user or a group (that list comes from your Azure Active Directory). Click on Save and trigger a new release (by either hitting Create release or updating the master branch in the repo).
The prod environment will not kick in automatically, but it will stay on Waiting for approval status. The approver will receive an email and logged on to the Azure DevOps portal, go to the release and click on Approve.
Provide the comments and click on Approve. That will trigger the deployment in the production environment.
Azure DevOps: This series is done — but more to do
Are we done? Not even close, there is so much more to explore, but I think it was a good start.
We started with a virtual network deployed manually in Azure Portal to a complete and dynamic Azure DevOps organization, project, repos, and pipelines. The process is simple, and it starts with a simple update to a repo that will create a chain of events to perform the entire environment without a lot of manual intervention.
Moving from an Azure Portal/PowerShell script to a complete Azure DevOps is not an easy task, trust me. However, if you want to achieve more collaboration, agility and use the new tendencies, you need to start somewhere.
You can start simple and adopt a thing or two that we went over in this series to start getting the taste and train people to use the new process (usually the hardest part).