luvv to helpDiscover the Best Free Online Tools

Topic 6 of 9

Environment Based Workflows Dev Stage Prod

Learn Environment Based Workflows Dev Stage Prod for free with explanations, exercises, and a quick test (for Analytics Engineer).

Published: December 23, 2025 | Updated: December 23, 2025

Why this matters

Branch naming and conventions

Feature branches: feature/add_metric_x
Hotfix branches: hotfix/fix_null_values
Release tags: v1.3.0, v1.3.1
Commit style: verb-first, small scope (e.g., "add L7 revenue metric")

Worked examples

Example 1: Add a new metric safely

Create feature branch from main.
Implement and test locally (Dev).
Merge to staging and run validations (Stage).
Merge staging into main and tag (Prod).

git checkout main
git pull

# Dev
git checkout -b feature/add_l7_revenue
# edit models/revenue_l7.sql
git add models/revenue_l7.sql
git commit -m "add L7 revenue metric"

# Stage
git checkout staging
git merge --no-ff feature/add_l7_revenue -m "stage: add L7 revenue metric"
# run validations here

# Prod
git checkout main
git merge --no-ff staging -m "prod: release L7 revenue metric"
git tag -a v1.4.0 -m "Release L7 revenue metric"

Example 2: Hotfix without pulling in unfinished work

Branch from main.
Fix and test quickly.
Merge to main, tag.
Cherry-pick or merge into staging/dev to sync.

git checkout main
git pull
git checkout -b hotfix/fix_nulls
# edit transform to handle NULLs
git add .
git commit -m "hotfix: handle NULLs in revenue calc"

git checkout main
git merge --no-ff hotfix/fix_nulls -m "prod: hotfix NULL handling"
git tag -a v1.4.1 -m "Hotfix NULL handling"

# keep other envs updated
git checkout staging
git merge --no-ff main -m "sync hotfix from prod"

Example 3: Keep feature branch up to date

Sync with main to reduce merge conflicts later.

git checkout main
git pull

git checkout feature/add_l7_revenue
# either merge or rebase
# merge style:
git merge main -m "sync main"
# or rebase style:
# git rebase main

Exercises

Practice the exact promotion steps locally. Mirror outputs and commands as shown.

Exercise 1: Create a three-environment flow

Goal: main (Prod), staging (Stage), feature branch (Dev) with a promoted change and a tagged release.

Initialize a repo and create main + staging.
Create a feature branch and commit a change.
Merge feature → staging; validate (simulate).
Merge staging → main; create an annotated tag.

Exercise 2: Run a hotfix and keep branches aligned

Goal: cut a hotfix from main, release it, then sync staging.

Create hotfix from main; commit fix.
Merge to main; tag vX.Y.Z.
Merge main back to staging to sync.

Common mistakes and self-check

Merging dev directly to main. Self-check: Did your change go feature → staging → main?
Forgetting release tags. Self-check: Does each prod release have an annotated tag?
Letting feature branches drift. Self-check: When did you last sync with main?
Hotfix not synced to staging/dev. Self-check: After hotfix, did you merge main back to staging?
Giant PRs. Self-check: Are changes small and reviewable?

Practical projects

Project 1: Branch map poster. Document your teams branch-to-environment policy and examples of commands.
Project 2: Release playbook. Write and test a one-page checklist for stage validation and prod tagging.
Project 3: Hotfix drill. Simulate a prod bug and run the full hotfix + sync flow.
Project 4: CI-friendly checks. Add a simple script or checklist that runs validations when merging to staging.

Learning path

Before this: Git basics (init, branch, commit, merge/rebase), code reviews, simple tagging.
Now: Map branches to environments; practice promotions and hotfixes.
Next: Release strategies (semver), automated checks, deployment approvals.

Who this is for

Analytics Engineers implementing and promoting data models.
BI developers integrating metrics to dashboards safely.
Data engineers collaborating across multiple environments.

Prerequisites

Comfort with Git branching, committing, merging.
Basic understanding of your teams data warehouse and validation checks.

Mini challenge

In a new repo, simulate two concurrent features. Promote Feature A to prod first, then handle a hotfix, and finally promote Feature B. Ensure tags exist for each production release and that staging stays in sync after the hotfix.

Hint

Feature A and B both branch from main. After hotfix merges to main, rebase or merge Feature B onto main before promoting.

Next steps

Automate: add validation scripts on staging merges.
Standardize: adopt branch names and tagging rules.
Improve safety: require reviews and status checks before promoting.

Practice Exercises

2 exercises to complete

Instructions

Initialize a repository with main (Prod) and staging (Stage). Create a feature branch (Dev), commit a change, promote to staging, then to main, and create an annotated tag.

Init repo and branches.
Create feature branch and commit a file (e.g., models/add_metric.sql).
Merge feature → staging, then staging → main.
Tag the release (v1.0.0).

git init env-flow && cd env-flow
echo "# Env Flow" > README.md
git add README.md && git commit -m "init"
git branch -M main
git checkout -b staging

git checkout -b feature/add_metric main
echo "SELECT 1 AS metric;" > models_add_metric.sql
git add models_add_metric.sql
git commit -m "add metric model"

git checkout staging
git merge --no-ff feature/add_metric -m "stage: add metric"

git checkout main
git merge --no-ff staging -m "prod: release metric"
git tag -a v1.0.0 -m "Initial metric release"

Expected Output

Repository with branches: main, staging, feature/add_metric. Merge commits present on staging and main. Annotated tag v1.0.0 on main.