Model stages (staging, production, archived) in MLOps - Step-by-Step Execution

Process Flow - Model stages (staging, production, archived)

Model Created

↓

Stage: Staging

↓

Test & Validate

↓

Promote

↓

Stage: Production

↓

Monitor & Use

↓

Archive Old Models

Models start in staging for testing, then move to production if validated, and old models get archived.

Execution Sample

MLOps

model = create_model()
stage = 'staging'
if test_model(model):
  stage = 'production'
else:
  stage = 'staging'

This code creates a model, tests it, and sets its stage to production if tests pass, otherwise keeps it in staging.

Process Table

Step	Action	Model Stage	Test Result	Next Stage
1	Create model	staging	N/A	staging
2	Test model	staging	Pass	production
3	Promote model	production	N/A	production
4	Monitor model	production	N/A	production
5	Archive old model	production	N/A	archived

💡 Model promoted to production after passing tests, then archived when replaced.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 5
stage	None	staging	production	production	archived
test_result	None	None	Pass	None	None

Key Moments - 2 Insights

Why does the model stay in staging if tests fail?

Because the test result is 'No' (see concept_flow ASCII diagram), the model is not promoted and remains in staging for fixes.

What triggers moving a model to archived?

When a newer model replaces the production one, the old model stage changes to archived (see execution_table step 5).

Visual Quiz - 3 Questions

Look at the execution_table at step 2, what is the model stage after testing?

A production

B staging

C archived

D testing

💡 Hint

Check the 'Next Stage' column at step 2 in execution_table.

At which step does the model get archived?

A Step 3

B Step 4

C Step 5

D Step 2

💡 Hint

Look for 'archived' in the 'Next Stage' column in execution_table.

If the test_model function fails, what will be the model stage after step 2?

A archived

B staging

C production

D deleted

💡 Hint

Refer to variable_tracker and execution_table step 2 for test results and stage changes.

Concept Snapshot

Model stages track lifecycle:
- Staging: model testing and validation
- Production: live use after passing tests
- Archived: old models replaced by newer ones
Models move forward only if tests pass.

Full Transcript

In MLOps, models go through stages to manage their lifecycle. First, a model is created and placed in the staging stage where it is tested. If the tests pass, the model is promoted to production, meaning it is ready for real use. If tests fail, the model stays in staging for fixes and retesting. When a newer model replaces an old one, the old model is moved to the archived stage to keep history and avoid confusion. This flow ensures only good models serve users and old versions are safely stored.

Practice

1. What is the primary purpose of the staging stage in model lifecycle management?

easy

A. To deploy models for live user traffic

B. To test and validate models before they go live

C. To permanently delete old models

D. To archive models for long-term storage

Solution

1. Step 1: Understand model stages

   The staging stage is used to test and validate models before they are deployed to production.

2. Step 2: Differentiate from other stages

   Production is for live use, archived is for storage, so staging is the testing phase.

3. Final Answer:

   To test and validate models before they go live -> Option B

4. Quick Check:

   Staging = Testing phase [OK]

Hint: Staging means testing before live use [OK]

Common Mistakes:

• Confusing staging with production
• Thinking archived means active use
• Assuming staging is for deleting models

2. Which MLflow command correctly transitions a model version to the production stage?

easy

A. mlflow models transition-version --model-name my_model --version 3 --stage production

B. mlflow model transition-version --model-name my_model --version 3 --to-stage production

C. mlflow models transition-version --model-name my_model --model-version 3 --stage production

D. mlflow models transition --model-name my_model --model-version 3 --stage production

Solution

1. Step 1: Recall MLflow CLI syntax

   The correct MLflow CLI command to transition a model version is mlflow models transition-version with flags --model-name, --version and --stage.

2. Step 2: Identify correct flags and command

   mlflow models transition-version --model-name my_model --version 3 --stage production matches the correct syntax.

3. Final Answer:

   mlflow models transition-version --model-name my_model --version 3 --stage production -> Option A

4. Quick Check:

   Correct MLflow syntax = mlflow models transition-version --model-name my_model --version 3 --stage production [OK]

Hint: Use 'transition-version' with --version and --stage flags [OK]

Common Mistakes:

• Using 'model' instead of 'models'
• Mixing up --model-version and --version flags
• Incorrect command order or missing flags

3. Given this MLflow Python snippet, what will be the stage of the model after execution?

from mlflow import MlflowClient
client = MlflowClient()
client.transition_model_version_stage(
    name="my_model",
    version=2,
    stage="archived"
)

medium

A. Archived

B. Production

C. Staging

D. None (error)

Solution

1. Step 1: Understand the method call

   The method transition_model_version_stage changes the stage of a model version to the specified stage.

2. Step 2: Check the stage argument

   The stage argument is set to "archived", so the model version 2 of "my_model" will be moved to archived stage.

3. Final Answer:

   Archived -> Option A

4. Quick Check:

   transition_model_version_stage with stage='archived' = Archived [OK]

Hint: Stage argument sets the model's new stage directly [OK]

Common Mistakes:

• Assuming default stage if not specified
• Confusing method name with other MLflow functions
• Thinking 'archived' means deletion

4. You run this MLflow CLI command but get an error:

mlflow models transition-version --version 5 --stage production

What is the most likely cause?

medium

A. The command should be mlflow model transition-version (singular 'model')

B. Incorrect stage name; should be 'prod' instead of 'production'

C. Version number must be a string, not a number

D. Missing the --model-name argument

Solution

1. Step 1: Check required arguments for transition-version

   The mlflow models transition-version command requires the --model-name argument to specify which model to update.

2. Step 2: Identify missing argument

   The command lacks --model-name, causing the error.

3. Final Answer:

   Missing the --model-name argument -> Option D

4. Quick Check:

   Missing required flags cause errors [OK]

Hint: Always include --model-name when transitioning versions [OK]

Common Mistakes:

• Assuming stage names are abbreviated
• Using singular 'model' instead of 'models'
• Passing version as string instead of number (both accepted)

5. You have two model versions: v1 in production and v2 in staging. You want to promote v2 to production and archive v1 using MLflow Python API. Which sequence of calls correctly achieves this?

hard

A. client.transition_model_version_stage('model', 2, 'archived') then client.transition_model_version_stage('model', 1, 'production')

B. client.transition_model_version_stage('model', 2, 'production') then client.transition_model_version_stage('model', 2, 'archived')

C. client.transition_model_version_stage('model', 1, 'archived') then client.transition_model_version_stage('model', 2, 'production')

D. client.transition_model_version_stage('model', 1, 'production') then client.transition_model_version_stage('model', 2, 'staging')

Solution

1. Step 1: Archive current production version first

   To free the production stage, first move v1 from production to archived.

2. Step 2: Promote staging version to production

   After archiving v1, promote v2 from staging to production.

3. Final Answer:

   Archive v1 then promote v2 -> Option C

4. Quick Check:

   Archive old before promoting new [OK]

Hint: Archive old production before promoting new [OK]

Common Mistakes:

• Promoting new before archiving old causes stage conflict
• Archiving staging version instead of production
• Reassigning stages incorrectly