DAG versioning strategies in Apache Airflow - Step-by-Step Execution

Process Flow - DAG versioning strategies

Create DAG code

↓

Save DAG file in repo

↓

Commit changes with version tag

↓

Deploy DAG to Airflow environment

↓

Airflow scheduler loads DAG

↓

Run DAG with specific version

↓

Monitor and maintain versions

↓

Update DAG code for new version

↩Back to Save DAG file

This flow shows how DAG code is created, versioned, deployed, and run in Airflow, with updates leading to new versions.

Execution Sample

Apache Airflow

from airflow import DAG
from airflow.operators.dummy import DummyOperator
from datetime import datetime

def create_dag(version):
    dag = DAG(
        dag_id=f"example_dag_v{version}",
        start_date=datetime(2023, 1, 1),
        schedule_interval='@daily'
    )
    start = DummyOperator(task_id='start', dag=dag)
    return dag

dag_v1 = create_dag(1)
dag_v2 = create_dag(2)

Defines two DAG versions with different version numbers in their IDs.

Process Table

Step	Action	DAG ID Created	Version Used	Result
1	Call create_dag(1)	example_dag_v1	1	DAG object for version 1 created
2	Call create_dag(2)	example_dag_v2	2	DAG object for version 2 created
3	Deploy DAGs to Airflow	example_dag_v1, example_dag_v2	1 and 2	Both DAG versions available in Airflow
4	Run DAG example_dag_v1	example_dag_v1	1	Runs tasks of version 1 DAG
5	Run DAG example_dag_v2	example_dag_v2	2	Runs tasks of version 2 DAG
6	Update DAG code to version 3	example_dag_v3	3	New DAG version created and deployed
7	Run DAG example_dag_v3	example_dag_v3	3	Runs tasks of version 3 DAG

💡 Execution stops after running the latest DAG version (3) and all versions are deployed.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 6	Final
dag	None	example_dag_v1	example_dag_v2	example_dag_v3	example_dag_v3
version	None	1	2	3	3

Key Moments - 3 Insights

Why do we create separate DAG IDs for each version instead of overwriting the same DAG?

Each DAG version has a unique ID (see execution_table steps 1 and 2) so Airflow can track and run multiple versions independently without conflicts.

How does Airflow know which DAG version to run?

Airflow runs the DAG by its unique ID (execution_table steps 4 and 5), so specifying the version in the DAG ID directs Airflow to the correct version.

What happens when we update the DAG code to a new version?

A new DAG object with a new version ID is created and deployed (step 6), allowing Airflow to run the updated workflow alongside older versions.

Visual Quiz - 3 Questions

Look at the execution_table, what is the DAG ID created at step 2?

A example_dag_v2

B example_dag_v3

C example_dag_v1

D example_dag

💡 Hint

Check the 'DAG ID Created' column at step 2 in the execution_table.

At which step does the new DAG version 3 get deployed?

A Step 4

B Step 5

C Step 6

D Step 7

💡 Hint

Look for the step where 'Update DAG code to version 3' happens in the execution_table.

If we did not use version numbers in DAG IDs, what would happen?

A Airflow would run all versions separately.

B Older DAG versions would be overwritten and lost.

C Airflow would create duplicate DAGs automatically.

D No effect; Airflow handles versions internally.

💡 Hint

Refer to key_moments about unique DAG IDs and versioning.

Concept Snapshot

DAG Versioning Strategies in Airflow:
- Use unique DAG IDs with version numbers (e.g., example_dag_v1)
- Create and deploy each version as a separate DAG file
- Airflow runs DAGs by their IDs, enabling multiple versions
- Update DAG code by creating new versioned DAGs
- Maintain old versions for history or rollback

Full Transcript

This visual execution shows how to manage DAG versions in Airflow by creating separate DAG IDs with version numbers. We start by defining DAGs with different version numbers, deploy them, and run each version independently. Updating the DAG means creating a new version with a new ID. This approach prevents overwriting and allows running multiple versions side by side. Key points include unique DAG IDs, deployment steps, and running specific versions. The quiz tests understanding of DAG IDs, deployment steps, and consequences of not versioning.

Practice

1. What is the main purpose of DAG versioning in Airflow?

easy

A. To speed up the execution of tasks in a DAG

B. To reduce the number of DAGs in the Airflow UI

C. To give each workflow version a unique name for safe management

D. To automatically fix errors in DAG code

Solution

1. Step 1: Understand DAG versioning concept

   DAG versioning means assigning unique names to different versions of workflows to avoid confusion and conflicts.

2. Step 2: Identify the main benefit

   This unique naming helps run and manage multiple workflow versions safely without overwriting or mixing them.

3. Final Answer:

   To give each workflow version a unique name for safe management -> Option C

4. Quick Check:

   DAG versioning = unique naming for safety [OK]

Hint: Remember: versioning means unique names for workflows [OK]

Common Mistakes:

• Thinking versioning speeds up task execution
• Confusing versioning with error fixing
• Believing versioning reduces DAG count

2. Which of the following is a correct way to name a DAG version in Airflow?

easy

A. my_dag_v1

B. my dag version 1

C. my-dag-version-1!

D. my.dag.version.1

Solution

1. Step 1: Check valid DAG naming rules

   DAG names should be simple strings without spaces or special characters like ! or dots.

2. Step 2: Identify the valid option

   my_dag_v1 uses underscores and no spaces or special characters, making it valid.

3. Final Answer:

   my_dag_v1 -> Option A

4. Quick Check:

   Valid DAG names use underscores, no spaces [OK]

Hint: Use underscores, avoid spaces and special chars [OK]

Common Mistakes:

• Using spaces in DAG names
• Including special characters like !
• Using dots which can cause issues

3. Given this DAG code snippet, what will be the DAG id when versioning is applied as shown?

version = 3
dag_id = f"example_dag_v{version}"
print(dag_id)

medium

A. example_dagv3

B. example_dag_version3

C. example_dag_3

D. example_dag_v3

Solution

1. Step 1: Understand f-string usage

   The f-string inserts the value of 'version' variable into the string where {version} is placed.

2. Step 2: Substitute version value

   Since version = 3, the string becomes 'example_dag_v3'.

3. Final Answer:

   example_dag_v3 -> Option D

4. Quick Check:

   f-string with version=3 = example_dag_v3 [OK]

Hint: f-string inserts variable value directly [OK]

Common Mistakes:

• Confusing variable placement in f-string
• Adding extra words like 'version' manually
• Missing underscores in the name

4. You have two DAG versions named data_pipeline_v1 and data_pipeline_v2. You accidentally overwrite data_pipeline_v1 code with v2 code but keep the same DAG id. What is the main problem here?

medium

A. Airflow will only run the latest code under one DAG id, losing version 1

B. The scheduler will crash due to duplicate DAG ids

C. Airflow will create duplicate DAGs with same id

D. Both versions run simultaneously causing conflicts

Solution

1. Step 1: Understand DAG id uniqueness

   Airflow identifies DAGs by their DAG id. If two versions share the same id, only one is recognized.

2. Step 2: Identify effect of overwriting code

   Overwriting v1 code with v2 under same id means v1 is lost and only v2 runs.

3. Final Answer:

   Airflow will only run the latest code under one DAG id, losing version 1 -> Option A

4. Quick Check:

   Same DAG id means only one version runs [OK]

Hint: Unique DAG ids prevent overwriting versions [OK]

Common Mistakes:

• Thinking both versions run at once
• Expecting duplicate DAGs with same id
• Assuming scheduler crashes on duplicates

5. You want to manage multiple DAG versions without changing DAG ids manually. Which strategy below best helps you achieve this in Airflow?

hard

A. Manually rename DAG files for each version

B. Use Airflow Variables to store the version and dynamically set DAG id

C. Use the same DAG id and overwrite code for each version

D. Disable all DAGs except the latest version

Solution

1. Step 1: Understand dynamic DAG id setting

   Using Airflow Variables allows you to store version info externally and inject it into DAG id dynamically.

2. Step 2: Compare with other options

   Manual renaming is error-prone, overwriting loses old versions, disabling DAGs is manual and not scalable.

3. Final Answer:

   Use Airflow Variables to store the version and dynamically set DAG id -> Option B

4. Quick Check:

   Dynamic DAG id via Variables = best versioning [OK]

Hint: Use Variables to automate version naming [OK]

Common Mistakes:

• Relying on manual file renaming
• Overwriting code without versioning
• Disabling DAGs instead of versioning