Azure DevOps Projects

Overview

An organization can have multiple projects and it’s key to look at the project structure. Asking questions like:

  • Do we need one project per Team?
  • Do we need one project per Business Area?
  • Do we need one project per product?
  • How do we collaborate across teams and projects?
  • How much organizational structure change do we expect?

The questions above start to build out a picture that informs the Azure DevOps project and also can impact the organization design. As if there’s a lot of organizational structure change. How would you make sure the Azure DevOps design can handle it without a lot of redesign and moving projects and teams around?

Some examples:

  • By creating a project per Business Process Area (e.g. Payments) if the names and structure of the organization changes the Payments BPA project should still be valid including the team membership.

Project

Below shows some of the key steps that need to be followed to setup an ADO Project for an Organization.

Projects

Teams

  • Each project gets a default team created.
  • Optional, create any additional teams required for the project an/or identified in the planning your organization structure section above.
  • Define process for Access, Roles and Permissions at Team level (tbc - build out more info)
    • Roles and Responsibilities (tbc)
  • Manage and configure team tools

Boards

Azure Boards is a web-based service that enables teams to plan, track, and discuss work across the entire development process, while it supports agile methodologies, including Scrum and Kanban. Azure Boards provides a customizable platform for managing work items, allowing teams to collaborate effectively and streamline their workflow. Sign up, customize, and experience the benefits of using Azure Boards.

Below shows some of the configuration steps to follow to get Boards setup in a Project:

  • Review process’s setup in the Organization.
  • Configure the Team configuration for Backlogs, working days, bugs, iterations, areas and templates.
  • Optional, setup GitHub connection for linking Boards to a GitHub repo.
  • Config the Teams Board for their ways of working (e.g. workflow, swim-lanes, styles and fields)

Repositories

A project can have one or many repositories. It’s key to look at your working patterns and go with what would work for your project team. The trend is to drive agility and quicker smaller changes into Production. So, this needs to be taken into account with the repository strategy for the project.

Below are a few tasks to go through when settings up a repository of an ADO Project:

  • Define and branching strategy for the Team when working with a repo.
  • Set default branch name (e.g. main)
  • Apply policies to the repo.
  • Review and apply security groups and roles to repo.
  • Developer team to agree approach to repo’s for their applications:
    • One vs. many
    • Shared vs. Forked
  • Define process for Access, Roles and Permissions at repo level based on above requirements.
  • Create Repo

Pipelines

Pipelines

Best practice is to move to YAML pipelines for both build and release pipelines. This allows for managing the pipelines as code and storing them in repos to drive consistency and audibility linked to builds and releases.

Pipelines run on Agent Pools, so when creating a pipeline an agent pool needs to be available to execute the pipeline. For security and scalability its recommended to use self-hosted agents for pipelines, but Microsoft Hosted-Agents can be used, but can’t deploy into private environments.

Create first pipeline using the agent pool created above and start to expand by creating more agent pools and pipelines to meet your business needs.