---
type: concept
x-llmwiki:
  schemaVersion: "0.1"
  contentHash: 6c1552c83f1f6185d5407f4c897d93bb2a7fa896439bd8b569ca06e8526ac0fb
  pageDirectory: concepts
  sources:
    - model-deployment-patterns-databricks-on-aws.md
  confidence: 0.85
  provenanceState: extracted
  freshnessStatus: unverified
  aliases:
    - ml-environment-stages-devstagingprod
    - MES(
  citations:
    - file: model-deployment-patterns-databricks-on-aws.md
title: ML Environment Stages (Dev/Staging/Prod)
description: The separation of ML workloads into development, staging, and production environments, each corresponding to a Unity Catalog catalog, with distinct purposes for model development, integration testing, and final serving.
tags:
  - mlops
  - infrastructure
  - databricks
timestamp: "2026-06-19T19:42:16.349Z"
---

---

title: ML Environment Stages (Dev/Staging/Prod)
summary: The three standard execution environments used in ML lifecycle management on Databricks: development, staging, and production.
sources:
  - model-deployment-patterns-databricks-on-aws.md
kind: concept
createdAt: "2026-06-20T12:00:00.000Z"
updatedAt: "2026-06-20T12:00:00.000Z"
tags:
  - mlops
  - deployment
  - environments
aliases:
  - dev-staging-prod
  - ml-environment-stages
  - deployment-environments
confidence: 1.0
provenanceState: extracted
inferredParagraphs: 0
---

# ML Environment Stages (Dev/Staging/Prod)

**ML Environment Stages** refer to the three standard execution environments in the ML lifecycle: **development (Dev)**, **staging**, and **production (Prod)**. These stages separate the work of model development, integration testing, and final serving. On Databricks, each environment typically corresponds to a [Unity Catalog](/concepts/unity-catalog.md) catalog. ^[model-deployment-patterns-databricks-on-aws.md]

The asynchronous nature of changes to models and code means that there are multiple possible patterns for moving ML artifacts through these stages. The two primary patterns differ in whether the **model artifact** or the **training code that produces the model artifact** is promoted towards production. ^[model-deployment-patterns-databricks-on-aws.md]

## Deploy Code Pattern (Recommended)

In the **deploy code** pattern, the code to train models is developed in the **development** environment. The same code then moves to **staging** and then **production**. The model is trained in each environment:

- **Dev**: initial model development.
- **Staging**: training on a limited subset of data as part of integration tests.
- **Production**: training on the full production data to produce the final model.

^[model-deployment-patterns-databricks-on-aws.md]

Advantages:
- In organizations where access to production data is restricted, this pattern allows the model to be trained on production data in the production environment.
- Automated model retraining is safer because the training code is reviewed, tested, and approved for production.
- Supporting code (feature engineering, inference, monitoring) follows the same pattern as model training code, both going through integration tests in staging.

Disadvantages:
- The learning curve for data scientists to hand off code to collaborators can be steep; predefined project templates and workflows are helpful.

^[model-deployment-patterns-databricks-on-aws.md]

In this pattern, data scientists must be able to review training results from the production environment, as they have the knowledge to identify and fix ML-specific issues. If the situation requires that the model be trained in staging over the full production dataset, a **hybrid approach** can be used: deploy code to staging, train the model there, and then deploy the model to production. This saves training costs in production but adds an extra operation cost in staging. ^[model-deployment-patterns-databricks-on-aws.md]

## Deploy Models Pattern

In the **deploy models** pattern, the model artifact is generated by training code in the **development** environment. The artifact is then tested in the **staging** environment before being deployed into **production**. ^[model-deployment-patterns-databricks-on-aws.md]

Consider this option when one or more of the following apply:
- Model training is very expensive or hard to reproduce.
- All work is done in a single Databricks workspace.
- You are not working with external repos or a CI/CD process.

Advantages:
- A simpler handoff for data scientists.
- In cases where model training is expensive, only requires training the model once.

Disadvantages:
- If production data is not accessible from the development environment (which may be true for security reasons), this architecture may not be viable.
- Automated model retraining is tricky. You could automate retraining in the development environment, but the team responsible for deploying the model in production might not accept the resulting model as production-ready.
- Supporting code (feature engineering, inference, monitoring) needs to be deployed to production separately.

^[model-deployment-patterns-databricks-on-aws.md]

## Environment Lifecycle Summary

The diagram below compares the code lifecycle for the two deployment patterns across the environments. In the **deploy models** pattern, final unit and integration testing is performed in the development environment. In the **deploy code** pattern, unit tests and integration tests are run in development, and final unit and integration testing is performed in the staging environment. ^[model-deployment-patterns-databricks-on-aws.md]

| Step | Deploy Code Pattern | Deploy Models Pattern |
|------|-------------------|----------------------|
| Unit / Integration tests | Dev (initial), Staging (final) | Dev (final) |
| Model training | Dev (initial), Staging (subset), Prod (final) | Dev (final) |
| Model deployment | Code moves: Dev → Staging → Prod | Artifact moves: Dev → Staging → Prod |

## Related Concepts

- [Unity Catalog](/concepts/unity-catalog.md) – Each environment typically maps to a Unity Catalog catalog.
- MLOps workflow – The recommended workflow that incorporates the deploy code pattern.
- Model artifact – The trained model object that is promoted in the deploy models pattern.
- Training code – The code that produces the model artifact.
- CI/CD – Continuous integration and continuous deployment, relevant to code promotion.
- [Model Serving](/concepts/model-serving.md) – The production use of the deployed model.

## Sources

- model-deployment-patterns-databricks-on-aws.md

# Citations

1. [model-deployment-patterns-databricks-on-aws.md](/references/model-deployment-patterns-databricks-on-aws-231ed92b.md)
