Image of a Release Pipeline Creation on Azure Devops

Azure DevOps, Integration and Project Success

Why communication around DevOps tools can lead you to project success

Speaking honestly, I can’t imagine anyone wanting to do everything on the command line for every server deployment ever again. This is why ‘DevOps’ is regarded as progress in this new age of automation. As my initial certification path comes to a close as a cloud engineer, I pondered on what demo projects to focus on. DevOps was my first thought out of the gate. It brought me equally as quickly to my favourite DevOps tool, “Azure DevOps”.

I started working on Maolte Technical Solution’s very first DevOps project deploying an Azure V-Net along with 2x subnets onto my company’s brand new demo subscription in Azure. I naturally started using Azure DevOps as it's been my go-to when given a choice by former employers who had their Azure DevOps organizations ready to use. So when my ARM-coded deployment failed due to an error around parallelism being enabled, I realised I never created my own Azure DevOps organization before. Azure DevOps disables parallelism by default on free tier subscriptions as an anti-fraud measure, so I wait for a couple of days for Azure support to complete my enablement request. After shelving the project for a few days, I thought about the correctness of my DevOps tool selection. Is Azure DevOps the best tool for deploying an Azure V-Net with subnets via an ARM template implementation? Well, it's Azure, so yes, it's a good choice but coincidence and not design made it so. I guess the old saying ‘be careful what you wish for’ applies to DevOps and tool selection. When thinking about designing a structured approach to your DevOps project, do note that project requirements are key in your choice of DevOps tool. Here are some good questions to consider before you search for your DevOps tool of choice.

  • Am I deploying an application, SDN infrastructure objects like workspaces and/or provisioning infrastructure resources?
  • Is this project a once-off or to be repeated? 
  • Who is handling the build? Where is the handover from the development team?
  • Does the project require performance, integration testing and security testing to be done via integration modules manually or in a release pipeline?
  • Can the pipeline be run manually and if so, why?
  • What kind of deployment is required? Rolling, A/B, etc?
  • Depending on what type of deployment is required, is the Infrastructure As Code (IaC) written and peer-reviewed to manage the deployment behaviour?

I can't say the above is an exhaustive list but it's a great place to start. I find questions like the above in some cases can be met with below-par responses from fellow engineers and managers, when they should be heartily welcomed. It shows enthusiasm, commitment and professional interest in doing the right thing. Clearly setting out the context of what a DevOps engineer should build with the involved stakeholders and resources in existence gives great clarity on what needs to be done. When we are all on the same page, we can write a great book! Stay tuned for more on DevOps in this blog along with articles on other areas of interest in the Writing and Cloud Infrastructure arenas. To not miss out on any updates on my availability, tips on related areas or anything of interest to all, sign up for one of my newsletters in the footer of any page on Maolte. I look forward to us becoming pen pals!

Related Articles

Image of interconnected points and a project startup text for a maolte article

New Business and IT Contracting

Image of Jenkins workflow

CICD and Jenkins

Azure DevOps VNet Topology image on Azure portal.

Azure V-Net Demo