AZURE DEVOPS · PRACTICAL GUIDE

Which build is deployed in each environment?

By Steven Ryssaert, the developer of Worre · 1 November 2026

Start with the deployment record for the application and environment you care about. A green build can be newer than the version in production. A run waiting for approval can be newer still.

This guide covers YAML pipelines in Azure DevOps Services. The examples below are illustrative; the sample pipeline records a demonstration deployment without deploying an application.

1. Open the environment’s deployment history

In your project, open Pipelines → Environments, choose an environment, and open Deployments. Follow a deployment back to its run to inspect the application, artifact and result.

For a useful history, your YAML must target that environment from a deployment job. A normal build job named “Deploy” does not establish that environment relationship by its name alone. See Microsoft’s environment setup documentation.

Treat this as recorded deployment history. A manual change outside the pipeline can make the running system differ from the last recorded deployment. If your process allows that, verify the application’s running version too.

2. Separate the three states

Azure DevOps can pause a stage at resource checks before its jobs run. An environment approval is one such check; approval does not itself mean deployment has completed. Microsoft explains this in approvals and checks.

3. Try a minimal deployment record

Create an empty environment named worre-demo-only under Pipelines → Environments, then use this YAML in a separate demonstration pipeline. Authorize that pipeline to use the environment if Azure DevOps asks.

trigger: none

pool:
  vmImage: ubuntu-latest

stages:
- stage: Demo
  displayName: Record a sample deployment
  jobs:
  - deployment: RecordSample
    environment: worre-demo-only
    strategy:
      runOnce:
        deploy:
          steps:
          - checkout: none
          - script: |
              echo "Sample record only; no application deployed."
            displayName: Write a demonstration message

Running this uses an agent job and records a sample deployment. It does not change a running application or provision infrastructure. The record demonstrates the environment relationship, not a real software release.

For a real pipeline, point the deployment job at the correct target and replace the demonstration step with your deployment work. If several applications share an environment, check the relevant pipeline and application rather than taking the newest record across all applications.

4. Check the native Stages view

For one pipeline, its Stages view may already provide the overview you need. Microsoft’s Sprint 271 update describes stage history and the latest deployed or deploying run at each stage. Named stages appear in that view.

Where Worre fits

I built Worre to keep several applications and environments visible together on my desktop. Select the pipelines and environments you need, arrange the columns, and inspect build context without reopening every pipeline page. Approval waits stay separate from the build already deployed.

Worre is a free Windows 10/11 x64 app. It signs in with a Microsoft Entra work account, without a PAT. Its deployment overview uses Azure DevOps Environments; classic releases and on-premises Azure DevOps Server are not supported.

To explore the interface first, download the app and choose Try sample data. When you connect your project, compare a few cells with Azure DevOps, including a waiting approval or a redeployment. That checks whether the overview represents your workflow correctly.

Ready to try it with your team? Start with one project, then share the workspace layout with a teammate.