Azure DevOps Setup: Boards, Repos, Pipelines, Artifacts

Teams moving from Jira + GitHub + Jenkins to Azure DevOps often expect everything to work out of the box. But "all in one place" doesn't mean it configures itself—setting up Boards, Repos, Pipelines, and Artifacts to match your team's processes takes expertise and architectural understanding. Our engineers have 10+ years of DevOps experience and have successfully completed over 50 migration projects to Azure DevOps. We guarantee a smooth transition and optimal configuration for your specific needs.

Structure: Organization, Project, Team

Organization — the top level, analogous to a "company" in Jira. One URL like dev.azure.com/mycompany. Billing, security policies, users—all at the Organization level.

Project — the main working unit. Contains Boards, Repos, Pipelines, Artifacts, and Test Plans. Different products should have separate projects, not all crammed into one. Mixing unrelated teams in a single project is a common mistake difficult to fix later—work items, tasks, and pipelines start interfering.

Team — a subset of a project with its own Boards, Sprint Backlog, and settings. One Project can contain multiple Teams (frontend-team, backend-team, devops-team).

Boards: Agile, Scrum, or CMMI

When creating a project, you choose a process template. For most teams—Scrum (with Sprint Backlogs, Velocity, and Burndown) or Agile (more flexible, with User Stories and Tasks). CMMI is for formal processes with change requests and approval workflows.

Team-specific configuration:

Process → Work Item Types → add custom fields
Board → Column settings → set WIP limits
Sprints → create sprints with dates
Area Paths → structure by component (backend, frontend, infra)
Iteration Paths → sprint hierarchy (Q1 → Sprint 1, Sprint 2)

Area Paths — especially important for filtering: each Team works with its own Area, keeping their Boards separate.

How to Set Up Branch Policies in Azure Repos?

Azure Repos supports Git (and legacy TFVC, which we advise against using). The key configuration is Branch Policies on main:

• Minimum number of reviewers: 2 (for production code)
• Check for linked work items: mandatory association of PR with a task in Boards
• Check for comment resolution: no merge without resolved comments
• Build validation: automatic pipeline trigger on every PR

# Policy via Azure CLI az repos policy approver-count create \
  --allow-downvotes false \
  --blocking true \
  --branch main \
  --creator-vote-counts false \
  --enabled true \
  --minimum-approver-count 2 \
  --project myproject \
  --repository-id <repo-id>

What to Choose: YAML or Classic Pipelines?

Classic pipelines (via UI) are deprecated. For new projects we always use YAML pipelines, stored in the repository as azure-pipelines.yml. This enables code review for pipelines, change history, and template reuse. More about the YAML schema can be found in the official documentation.

Basic YAML structure:

trigger:
  branches:
    include:
      - main
      - develop
pool:
  vmImage: ubuntu-latest
stages:
  - stage: Build
    jobs:
      - job: BuildJob
        steps:
          - task: Docker@2
            inputs:
              command: buildAndPush
              repository: myapp
              containerRegistry: myacr-connection
              tags: |
                $(Build.BuildId)
                latest
  - stage: Deploy
    dependsOn: Build
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
    jobs:
      - deployment: DeployProd
        environment: production
        strategy:
          runOnce:
            deploy:
              steps:
                - task: HelmDeploy@0
                  inputs:
                    command: upgrade
                    chartName: myapp
                    releaseName: myapp-prod

Environments and Approvals in Pipelines

Under Pipelines → Environments, create an environment named production. Configure Approvals and checks:

• Approvals: a list of people, any one of whom must approve the deployment
• Business hours check: deploy allowed only during working hours (e.g., Mon-Fri 09:00-18:00)
• Exclusive lock: only one deployment to this environment at a time

Case: For a fintech client, we replaced a legacy Jenkins pipeline with a multi-stage YAML pipeline, cutting deployment time from 30 minutes to 5 minutes and enabling automated rollback on failure. This was achieved by parallelizing build stages and using deployment slots with immediate swap.

Artifacts: Internal Package Registry

Azure Artifacts creates private feeds for npm, NuGet, Maven, Python, and Universal Packages. Your team publishes internal libraries to Artifacts rather than public npm/PyPI.

---
# Publishing an npm package to an Artifacts feed
- task: Npm@1
  inputs:
    command: publish
    publishRegistry: useFeed
    publishFeed: myorg/myfeed

Upstream sources allow proxying public registries through the Artifacts feed—so npm install goes through the internal proxy, caching packages and controlling access to external dependencies.

Service Connections: Cloud Integrations

To deploy to Azure, AWS, GCP, or Kubernetes, you need Service Connections—a secure storage of credentials accessible to pipelines without hardcoded secrets. Configured in Project Settings → Service Connections.

For Azure Kubernetes Service — a Kubernetes-type Service Connection with kubeconfig or a service account. For Azure Container Registry — an ACR service connection with automatic OAuth. For AWS — an AWS Credentials connection with an IAM role.

What's Included in Azure DevOps Setup?

Timelines

Basic setup of a new project (Boards, Repos with branch policies, one Pipeline) — 1 day. Full configuration of an organization with multiple projects, Artifacts feed, Environments with approvals, and AKS integration — 2-3 days. Migration from Jira + GitHub + Jenkins requires a separate assessment. Cost is calculated individually. Contact us for a consultation and precise timelines for your project. Order Azure DevOps setup from us—we guarantee quality and post-implementation support.