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!
