DAG versioning strategies in Apache Airflow - Commands & Configuration

Introduction

When you update workflows in Airflow, you need a way to keep track of changes and run the right version. DAG versioning strategies help you manage different versions of your workflows safely and clearly.

When you want to test a new version of a workflow without stopping the current one

When you need to keep old workflow versions for audit or rerun purposes

When multiple teams update the same DAG and you want to avoid conflicts

When you want to deploy workflow changes gradually to avoid breaking production

When you want to rollback to a previous workflow version quickly if errors occur

Config File - example_dag_v1.py

example_dag_v1.py

from airflow import DAG
from airflow.operators.bash import BashOperator
from datetime import datetime

with DAG(
    dag_id='example_dag_v1',
    start_date=datetime(2024, 1, 1),
    schedule_interval='@daily',
    catchup=False
) as dag:
    task1 = BashOperator(
        task_id='print_date',
        bash_command='date'
    )

This DAG file defines version 1 of a workflow named example_dag_v1. The dag_id includes the version number to distinguish it from other versions. This way, Airflow treats each version as a separate workflow.

The start_date and schedule_interval control when the DAG runs. The catchup=False flag prevents running old missed schedules when the DAG is first added.

Commands

This command lists all DAGs currently registered in Airflow. It helps you verify that your versioned DAGs are recognized separately.

Terminal

airflow dags list

Expected Output

example_dag_v1

example_dag_v2

This triggers a run of the version 1 DAG manually to test or run it immediately.

Terminal

airflow dags trigger example_dag_v1

Expected Output

Created <DagRun example_dag_v1 @ 2024-06-01 12:00:00: manual__2024-06-01T12:00:00+00:00, externally triggered: True>

This triggers a run of the version 2 DAG, showing how you can run different versions independently.

Terminal

airflow dags trigger example_dag_v2

Expected Output

Created <DagRun example_dag_v2 @ 2024-06-01 12:01:00: manual__2024-06-01T12:01:00+00:00, externally triggered: True>

Pauses the version 1 DAG to stop it from running on schedule, useful when you want to switch to a newer version.

Terminal

airflow dags pause example_dag_v1

Expected Output

Dag example_dag_v1 is paused

Unpauses the version 2 DAG to allow it to run on schedule, enabling the new version to take over.

Terminal

airflow dags unpause example_dag_v2

Expected Output

Dag example_dag_v2 is unpaused

Key Concept

If you remember nothing else from DAG versioning, remember: use unique dag_id names with version info to run and manage multiple workflow versions safely.

Common Mistakes

Using the same dag_id for different versions of a DAG

Airflow will overwrite the old DAG with the new one, losing the ability to run or track the old version separately.

Include version numbers or dates in the dag_id to keep each version distinct, like example_dag_v1 and example_dag_v2.

Not pausing old DAG versions when deploying new ones

Both versions may run simultaneously, causing duplicate work or conflicts.

Pause old DAG versions using airflow dags pause before unpausing the new version.

Changing DAG code without updating the dag_id

Airflow may not detect the change properly, leading to confusion about which version is running.

Always update the dag_id when making significant changes to create a new version.

Summary

Use unique dag_id names with version info to keep DAG versions separate.

Trigger and manage each DAG version independently using airflow CLI commands.

Pause old versions before enabling new ones to avoid conflicts.

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