Deployments

Deployments answers two questions: what is running in each environment right now, and how did it get there.

It observes. Taiga records and reports deployments; it does not perform them. Your pipeline stays where it is, and Taiga reads what it did.

It reads through your source control, which is the one prerequisite: a product sees deployments once its repository is linked, and not before. Until then there is nothing to observe and nothing to import.

What is running where

Each environment has its own tab, production first, so what runs in production is always one click away. A dot beside each environment’s name says how it stands: running, deploying, or its latest deployment failed. An environment that is deploying or failed also says so in words beside its name, so the one that needs a look shows before you open it. A tab pins what is running in that environment now at the top, together with anything deploying to it, and lists the rest of its history below, week by week, newest first. Each week says how many deployments it holds and how many of them failed, and only the newest one starts open.

Each line is one run of your pipeline. A deploy workflow reports a deployment per job, and a line brings a run’s jobs together and says how many there were. It names what shipped, the commit’s message, with its version and who deployed it. Every line carries its status, except one that a later deployment has simply replaced, which is every deployment’s normal end and says nothing. The one an environment runs now is marked as current, even when the provider has already marked it superseded. A failure shows the error the provider reported.

What is running is derived from your deployment history rather than taken from a provider’s “active” marker, because that marker is not reliable enough to build on. It is the most recent deployment that actually succeeded. When a newer attempt failed or was rolled back, you see it next to the version still running, not in place of it.

Opening a line shows every attempt to deploy that commit, in every environment, so you can follow the change from development through staging to production and read any one attempt in full: how it ended and, for a failure, the error the provider reported; which deployment it took over from, with a comparison of the two commits when the product links exactly one GitHub repository; how long it took to deploy, how long the change took to get there from its commit, and after a failure, how long until the environment ran a good deployment again. When Taiga built the change, the initiative it came from is named, and the link opens the build run.

The history

The history is mirrored from your provider, so it includes every deployment your pipeline made, whether or not Taiga had anything to do with the change being deployed. The record does not have a hole in it for work that happened outside Taiga. It arrives live, as the provider reports each event, and every few hours Taiga reads each environment’s newest records again, so an event that never reached it is picked up on the next pass; the page says when it last synced.

Per-pull-request previews and verification checks are kept apart from the environments, grouped by the pull request they belong to, on a tab named for what it holds: Previews, Checks, or Previews & checks. A check is a pull request’s run that recorded a deployment to a shared environment without deploying, such as a Terraform plan that uses the environment’s credentials. Previews are real deployments, but both are noise when you are asking what shipped, and neither counts toward the delivery metrics.

Each deployment is completed with its commit as it arrives: the commit’s message, when it was written (which lead time is measured from), and the pull request it belongs to. If you connected a repository that already had deployment history, importing it backfills the record rather than starting your history at the day you signed up. Taiga imports when the repository is connected, and again when you choose Refresh history, or Import deployment history while the record is still empty. An import reaches back 90 days, one environment at a time, production first, so the history you read first is in first; the header says which environment it is on and how far through. If an import stops, say because the provider was briefly unavailable, it keeps what it brought in, the header says why it stopped, and Taiga tries it again on its own a few times. Importing again also completes deployments that were recorded before Taiga looked their commits up. Importing is an administrator action, since it reaches into the connected provider; reading the history is not.

Delivery metrics

The Insights tab derives DORA’s five software delivery metrics from the production history, over the last 30, 60 or 90 days, chosen with the same Window control as Monitoring. They are grouped the way DORA groups them, throughput first and instability second:

Metric	Group	What it tells you
Deployment frequency	Throughput	How often you ship.
Lead time	Throughput	How long a change takes to reach production.
Failed deployment recovery time	Throughput	How quickly you recover when a deployment fails.
Change-failure rate	Instability	What proportion of deployments cause a problem.
Rework rate	Instability	What proportion of deployments were unplanned repairs.

The last three are read from deployments, not from incidents: a problem is a deployment that failed or was rolled back, and recovery is the next deployment that went live in that environment after it. A deployment counts as rework when it started after a failure and before any deployment went live again, so a fix and a fix to the fix both count. Re-running a failed pipeline run is that same run, so it is not counted again. A rollback after a deployment that succeeded but broke production is not seen, because nothing in the deployment history says it failed.

Beside them, the tab reads the flow behind the numbers over the same window: how long a change waits after going live in one environment before it goes live in the next, and which deployments failed or were rolled back, production’s first, each with when it failed, the error it failed with, whether the environment has recovered and how fast, and a link to the run.

The metrics are reported for the environment marked as production. A product without one sees a notice that links to the environment’s settings, where you can mark it, and still sees the flow, which is read from every environment.

They are computed, not entered, which is the point. Metrics that require someone to maintain a spreadsheet stop being maintained.

Each metric carries a trend against the window before it, and every metric but rework rate carries a performance band. DORA has published no bands for rework rate, so read it against its own trend. A trend built on fewer than ten deployments in either window is shown as approximate rather than as a verdict. The tab has nothing to report only when production had no deployment in the window; a metric that no deployment fed, such as recovery time in a window with no failure, says so instead of showing a number.

Environments, and how deployments find them

An environment is what a deployment is recorded against. You set yours up from the product, with a standard ladder offered, Development, Staging and Production, and reshape it in product settings, where the cloud connection behind an environment also lives.

Your pipeline does not need to know about any of this. A mirrored deployment arrives carrying whatever environment name your pipeline used, and Taiga matches it to yours: to the environment it matched before, by name, or by tier, so a workflow deploying to “prod” lands on Production.

A name that matches nothing is not dropped. Taiga creates the environment automatically, because deployment history must never be lost for the lack of a matching environment. And per-pull-request preview deployments all collapse onto one shared preview environment, rather than each pull request minting its own.

Today the mirror reads GitHub.