Docker Image Tagging Strategy for Edge Deployments

Overview

This document outlines tagging conventions for Docker images deployed to edge devices. Consistent tagging enables reliable deployments, easy rollbacks, and clear audit trails.

Image Naming

Always use ECR-registered image names from development onwards.

✅ Correct format:

<account-id>.dkr.ecr.ap-south-1.amazonaws.com/service-name

❌ Avoid local-style names:

service_name_new_model_support:latest

Tagging by Environment

Development / QA

• Avoid generic tags like dev or latest
• Use sprint/week format: [weeknumber][year]_[feature/bugfixid]

Examples:

ww1521                    # Week 15, 2021
ww1521_json-compare-db    # Week 15, 2021 with feature
ww1521_FS-999             # Week 15, 2021 with ticket reference

Workflow:

1. Tag and push images to ECR
2. Add tag to corresponding Jira task
3. Get QA approval
4. After sprint merge, create consolidated sprint tag

Production

Production tags follow semantic versioning only:

Tag format: stable.major.minor

Production tagging steps:

1. Determine version increment (major/minor)
2. Create versioned tag: v1.3
3. Also tag as prod (edge devices pull prod tag)
4. Push both tags to ECR

docker tag myservice:v1.3 <ecr-url>/myservice:v1.3
docker tag myservice:v1.3 <ecr-url>/myservice:prod
docker push <ecr-url>/myservice:v1.3
docker push <ecr-url>/myservice:prod

Version Timeline Example

Development        QA             Release
    |              |                 |
 ww1521_feature → ww1521 → ... → v1.3 + prod
    |              |                 |
 ww1621_bugfix  → ww1621 → ... → v1.3.1 + prod
    |              |                 |
 ww1721_newapi  → ww1721 → ... → v1.4 + prod

Sprint Guidelines

Branch-to-Tag Workflow

1. Create branches from sprint tasks (enables task-branch linking)

2. For dependencies across branches:

   • Create validation branch
   • Merge dependent branches
   • Share for validation
   • Merge validated combination to sprint branch

3. Sprint branch merges to develop and master only after release criteria met

4. Create tagged release on master with description

Deployment Rules

Git Guidelines Summary

Commit Restrictions:

Best Practices:

• Detailed commit messages
• One branch per task (branches are free!)
• Maintain one-to-one branch-task relationship

Release Documentation

Every release should update the release tracking page with:

• Release version
• Sprint/week reference
• Changed components
• Deployment date
• Rollback version (previous stable)