This article is based on concepts originally published on TechGenix. It has been independently rewritten and expanded for a DevOps engineering audience.
Why Infrastructure Teams Should Take Azure DevOps Seriously
Azure DevOps is often thought of as a developer tool — a place to store code, run pipelines, and manage releases. Infrastructure professionals, however, frequently overlook it as a management layer for Microsoft Azure environments. That’s a missed opportunity. Azure DevOps can serve as a single pane of glass for planning, tracking, version-controlling, and deploying your entire Azure infrastructure using Infrastructure-as-Code (IaC) practices.
When structured correctly, a single Azure DevOps organization with purpose-built projects can replace a patchwork of spreadsheets, ticketing systems, and ad-hoc scripts. The result is a reproducible, auditable, and collaborative infrastructure management workflow built on tooling you may already be paying for.
The Core Architecture: One Organization, One Project, Many Repos
A practical starting point for infrastructure teams is to create a single Azure DevOps organization and a single project dedicated to infrastructure management. Within that project, create one Git repository per application, service, or workload — mirroring your Azure resource group structure. This 1:1 mapping between repos and resource groups makes it easy to trace every deployed resource back to a specific codebase and a specific change history.
ARM templates, Bicep files, Terraform configurations, and PowerShell or Bash scripts all live in these repos. Pipelines defined in YAML then consume those artifacts to deploy, update, or tear down infrastructure consistently across subscriptions.
Choosing the Right Process for Azure Boards
When you create a new project in Azure DevOps, you choose a process template for Azure Boards. The available options are:
- Basic — Work items: Epic, Issue, Task. Ideal for small teams or straightforward workflows.
- Agile — Work items: Epic, Feature, User Story, Task, Bug, Issue. Suited to teams running Agile ceremonies.
- Scrum — Work items: Epic, Feature, Product Backlog Item, Task, Bug, Impediment. Best for teams running formal Scrum.
- CMMI — Adds Change Request, Review, and Risk item types for regulated or process-heavy environments.
For infrastructure teams managing Azure environments, the Basic process is often the right choice to start. It provides a clean three-level hierarchy — Epic → Issue → Task — that maps well to infrastructure projects: an Epic for a major deployment milestone, Issues for discrete infrastructure units (e.g., network, compute, firewall), and Tasks for the granular work items within each.
Structuring Work Items for Infrastructure Projects
Using the Basic process, a typical infrastructure project might be structured as follows:
- Epic: Hub-CoreNetwork Deployment
- Epic: App6 Deployment
- Epic: Firewall Deployment
Each Epic then contains Issues representing logical sub-units of work. For example, the Hub-CoreNetwork Deployment Epic might include Issues such as:
- CoreNetwork: Design Session with Team
- CoreNetwork: ARM Template Authoring
- CoreNetwork: Pipeline Configuration
- CoreNetwork: Update Documentation/Wiki
Prefixing Issue names with the parent Epic name (e.g., CoreNetwork:) is a useful convention. It makes hierarchy visible at a glance without having to drill into each item’s properties — especially valuable when you have dozens of issues across multiple Epics.
Each Issue can then have multiple Tasks. Tasks are where you assign owners, estimate effort, track activity type, and link to pull requests or pipeline runs.
Working with Azure Boards: Kanban View
The Boards view provides a Kanban-style interface. By default you get columns such as To Do, Doing, and Done. You can drag and drop Issues between columns to update their state automatically.
Two customizations worth implementing early:
- Custom columns — For example, a Vendor column to track Issues being handled by third-party suppliers. Configure this under Settings → Columns.
- Swimlanes — Swimlanes allow you to group Issues by priority, team, or any other dimension you define. Configure them under Settings → Swimlanes. Common lanes for infrastructure teams include Critical, Standard, and Planned.
When you open an Issue in the Boards view, the Related Work section automatically shows the parent Epic and any child Tasks — giving you the full hierarchy context without navigating away.
Planning Work with Backlogs and Sprints
The Backlog view lists all Issues not yet assigned to a Sprint. This is where you triage and prioritize work before committing it to a time-boxed Sprint. You can toggle between Issue-level and Epic-level views, and enabling the Parents option in View Options reveals the full Epic → Issue → Task hierarchy in a single scrollable list — essential once you have dozens of items.
To move work into a Sprint:
- Navigate to Boards → Backlogs.
- View the Sprint list on the right-hand panel. Create new Sprints with defined start and end dates as needed.
- Drag Issues (along with their child Tasks) from the Backlog into the target Sprint.
Once an Issue moves to a Sprint, it disappears from the Backlog view and appears only within that Sprint — keeping the Backlog clean and focused on unscheduled work.
Tracking Progress with the Taskboard and Burndown
Inside a Sprint, the Taskboard gives you a card-based view of all Issues and their child Tasks. Tasks move across the To Do → Doing → Done columns as work progresses.
When Tasks are properly configured with assigned owners, estimated effort, and activity types, the Work Details panel (enabled via View Options) shows how effort is distributed across team members for the current Sprint. The Burndown Trend chart provides a graphical view of remaining work over time, helping you identify whether the Sprint is on track or needs scope adjustment.
These visualizations are particularly useful for infrastructure Sprints where work can stall unexpectedly due to approval gates, vendor dependencies, or environment access issues.
Connecting Boards to Repos and Pipelines
Azure DevOps shines as an IaC platform because all its services are natively integrated. Work items link directly to:
- Repos — Commit messages that reference a work item ID (e.g.,
#42) automatically link the commit to that Task or Issue, creating a full audit trail from planned work to deployed code. - Pipelines — Pipeline runs reference the triggering commit, which in turn references the work item. You can see exactly which infrastructure change a pipeline run corresponds to.
- Wiki — Documentation stored in the project Wiki can be linked from work items, keeping runbooks and architecture decisions close to the work they describe.
Key Takeaways for Infrastructure Teams
- A single Azure DevOps organization with one project per environment (or per team) provides a clean, scalable structure for managing Azure infrastructure as code.
- Align repos with resource groups for clear traceability between code and deployed resources.
- The Basic process template is a practical starting point; it can be migrated to Agile or Scrum later if your team’s maturity and ceremony needs evolve.
- Consistent naming conventions for Epics and Issues pay dividends as the project scales beyond a handful of work items.
- Custom columns and swimlanes on the Kanban board reflect real infrastructure team dynamics — vendor dependencies, priority tiers, and approval workflows.
- Enabling the Parents view in Backlogs and linking commits to work items turns Azure DevOps into a genuine audit trail for infrastructure changes.
Azure DevOps covers far more ground than this article addresses — including pipeline authoring for ARM/Bicep/Terraform deployments, branch policies, environment approvals, and test plans. The planning and tracking layer described here is the foundation. Once your team is comfortable managing work in Boards and structuring code in Repos, layering in automated deployment pipelines becomes a natural next step.