Tagging Docker images for fun and profit

We :heart: Docker. It’s enabled us to have more confidence that our dev environments match production and has made deployments a breeze. Something that I’ve struggled with is effectively naming the images I generate. I’ve struggled to find consensus online about how this should be done, so have come up with something that I’ve not really seen around.

First, the problem: in some environments there’s a sensibly versioned artifact that’s pretty easy to name. For instance, packaging up an OS or a major release of publicly distributed software. In these scenarios, we’re burdened with versioning anyway so figuring out a slick system isn’t as important.

We don’t release binaries for sale, and generally operate software as a service. I don’t really want to have to enforce manual versioning through code review and the tech stack we’re using doesn’t have a slick way to verify that our versioning is correct. Most automated versioning I’ve seen just increments the PATCH version even if a contract is completely violated.

That’s why we decided to start versioning artifacts with the first eight chars from the git commit SHA. This worked great! If we see a bug in prod, we can quickly figure out what version is currently running and check it out locally. Unfortunately, it doesn’t give a quick view into order when looking at a docker registry. That’s why we’ve made an addition to this format – the date.

We now name our continuously deployed docker images (built then deployed to staging/prod in a single pipeline) like so $IMAGE_NAME:YYYY-MM-DD-$SHA . While this doesn’t give us great granularity in terms of order of changes within a single day, we’ve found it to be a happy medium. I guess an alternative on a larger team might be to use an incrementing count, but that’s harder to manage than ‘what day is today?’

We like to build our docker images early in our pipeline to use in the integration tests (a topic for a later post), so this make it pretty easy for subsequent pipeline stages to figure out what image it should run for the next test, without having to carry over artifacts from the previous stage in a stateful way.

That’s it for now, I’ll write more on this topic again I’m sure.