Docker Tagging Strategies for Deploying to Production

Docker Tagging Strategies for Deploying to Production

2 min read

The first instinct when deploying images is to work with a latest  or master  tag and always deploy that. While that can be a convenient way of deploying it can cause a few problems. Multi-tagging is an invaluable way to solve these issues. But first, what are the problems?

High-Velocity Teams Guarantee a latest tag will be useless

If you’re building and deploying five or more times a day the latest  tag will essentially become a random image. Whatever was built last lives here regardless of whether it was pushed to production or not. Referencing this image just a few minutes apart can lead to unexpected results.

Using a latest tag means you have no history

Imagine this scenario: production is broken and you want to go back to the last image. Maybe the person who previously deployed was hit by a car so you don’t what they were doing and what previously lived in production. Maybe you have a previously-latest  tag?

Multi-tagging to the rescue with versioned releases

This screenshot shows multiple tags on an image in the free private docker registry included in Codefresh. By default, Codefresh will add a tag to match the branch name in Git. In this case, the image both represents the feature branch and master branch. The production version number has been added here after the image was built.

Now if my production image version is prod.v.1134 and I need to rollback, I know that I’m looking for prod.v.1133 without having to look at any other information.

New to Codefresh? Create Your Free Account Today!

Ready to Get Started?
  • safer deployments
  • More frequent deployments
  • resilient deployments