Every software project or product requires a set of tasks or disciplines in order to be successful. You need to plan, prioritize, and track the work that needs to be done. You need to safely store and version the source code. You also need to build, integrate, validate, test, package, release, and deploy the software. Azure DevOps does ALL of that.
But DevOps hasn’t always been so accessible: Over the past 25-to-30 years, we’ve moved from error-prone, heavyweight manual processes, through several process and tooling changes, where we had focused and tailored toolsets for each different discipline above. With the increased adoption of cloud-driven Software as a Service (SaaS), however, we’ve moved away from having to self-host most of those tools. Now there are a handful of vendors offering a complete suite of services to address all your software development lifecycle needs. Microsoft’s Azure DevOps is one of the market leaders, and we use it frequently on client projects.
One thing that Azure DevOps does best is to help teams organize their work and reliably store and version the source code. These tasks are critical to a successful project because they provide great insight into the workstream, allowing you to manage your teams’ productivity, identify bottlenecks in your processes as well as track, trace, and correlate work items to source code changes.
Azure has a host of different services that address all aspects of the DevOps process, and we’ll dive into those in separate blogs. Here, I want to look specifically at the two services that give teams a solid foundation to complete their work systematically and successfully: Azure Boards and Azure Repos. We’ll dig into the functionality of these services and see some real-world examples of how you can use them to set your teams up for success.
Azure Boards is the service focused on project management, tracking, and planning. Out of the box, it comes with four predefined process templates: Basic (default), Agile, Scrum, and CMMI. The main difference between these processes are with the work item types as well as the workflow states. If one of the pre-defined templates is not exactly what you need, you can use it to create an Inherited Process and customize it to your needs.
With a process defined, you can then proceed to define your portfolio management strategy. Here, you can create a portfolio backlog focused on higher-level epics, for example. You can include separate feature-level backlogs that can be assigned to the teams that own that feature. The ability to create different teams under a single project and then define a hierarchical structure—where project areas are assigned to specific teams—while maintaining cross-team visibility is really useful when you have a larger project with multiple teams or squads. This is often the case of larger microservices-based systems, with separate teams owning one or a subset of individual services. With Azure Boards, they can all be part of the same overall project while retaining the independence to manage their own work items.
For day-to-day tasks, you can use kanban boards to visualize the current state of the workstream and use:
You can use sprints to plan your iteration capacity, scope of work, and take it a bit further using one of the many different Azure DevOps extensions like Delivery Plans.
While independent, the different Azure DevOps services are fully integrated, from an Azure Board Work Item view, you can view the pipeline releases related to that work item, create an Azure Repo Branch, and then view the pull requests and commits associated with the work item. You can also add links to establish relationships between work items, such as parent/child links and others. This is great when you need to keep traceability from work items to source code and releases.
Each Azure DevOps project has an overview section where you can create different dashboards from a set of available widgets that can display different visualizations of the Azure Boards data. For example, you can create a dashboard to track lead and cycle time or a CFD to help with flow management:
Azure Repos is the version control offering for source control management in Azure DevOps. While Azure Pipelines can integrate through Webhooks with other source code repositories such as GitHub and Bitbucket Cloud, Azure DevOps also has its own offering: Repos. It has all the features you’d come to expect from a source control system. It supports Git and uses Pull Requests to perform code reviews and merge new features into the main branch.
When configuring Azure Repos you can define custom branch policies to ensure, for example, that no one can push directly to the main branch. The only way to get your code merged into the main is through a pull request. You can also add additional gating criteria to the pull request, such as: Only complete a pull request that has a passing build, that has been approved by N number of people, that is linked to a work item, etc. All this can be used as quality gates and to ensure compliance with your established software engineering practices. There are several different rules and criteria you can specify when defining their branch policies, such as:
- Require a minimum number of reviewers
- Warning or requiring that an Azure DevOps work item is linked to a given pull request
- Enforcing that all comments be resolved before a pull request can be completed
- Limiting how a branch can be merged (no fast-forwarding, rebasing, squashing, etc.)
If branch policies don’t give you the fine-grained control and quality gates that you need, you can specify status policies, which gives you the flexibility of integrating third-party services into your Pull Request flow.
An Azure DevOps Repos feature that I personally like is the ability to create a Draft Pull Request. This allows me to share that early on with my teammates without having to resort to workarounds such as using DO NOT MERGE as the title.
When reviewing pull requests, one helpful trait is the ease at which you can switch, compare, and pick out the changes that happened to the pull request code since it was initially created. When dealing with pull requests that go through several review cycles, being able to go back and forth between the different versions of the pull request that were reviewed is invaluable to me as a reviewer.
Moving forward with Azure DevOps
Setting the foundation for a transparent and collaborative process is critical to any project. We’ve seen how Azure Boards can help your project management needs (e.g., work item tracking, work status visualization, traceability). It also enhances your software engineering and quality assurance processes by enabling extensive customization of a development team workflow. The many options for quality gates and processes can help you directly address regulatory or quality requirements. Azure Repos includes key features that allow you to enforce rules and processes. It’s also intended to help you maintain your mainline source code repository with a higher degree of quality, in addition to functionalities designed to increase the effectiveness and productivity of some of your software development process tasks such as code reviews.
Now that we’ve taken through Boards and Repos, you have a good springboard for launching your DevOps cloud strategy. The next step might be setting up your modern, robust delivery pipeline. For more on Azure Pipelines, check out our Chief Architect Jimmy Bogard’s in-depth demonstration: Azure Pipelines from Scratch: Putting modern CI/CD practices into action.