Image promotion strategy

Question

How is image promotion handled with 'dev' images?

Like many others, we have three environments for deployments – Dev, Stage, Production.

Stage always tracks the latest master, and production deploys are triggered when releases are tagged in Github. It's easy enough to promote images between stage and production.

Where I'm having trouble understanding this is with Dev. Dev images are built on pull requests in our case, but there's a good chance the branch behind the PR is some number of commits behind master, so promoting this image through the ranks would cause outdated code to end up on stage and prod.

What is the typical practice here? Are dev images kept separate, in a separate image repository and never mixed with the stage/production images? Is there some way to promote them that I'm missing?

Answer 1

Stage always tracks the latest master, and production deploys are triggered when releases are tagged in Github

Dev images are built on pull requests in our case, but there's a good chance the branch behind the PR is some number of commits behind master

This is all a bit confusing to me. I like to keep things simple, and I usually advocate for one branch per environment.

In this scenario, I would advise you to have the following branches:

• dev
• stage
• production

This will allow you to make changes to one environment at a time, progressively. So first you would push your changes to the dev branch, and if they are successful, you would then push the same changes to staging; likewise, if the changes are successful in staging, you would then push the changes to production. The pushing to the branch can and should be done via merge requests.

Each branch would have its own pipeline associated to it, which would build, test and release the image to the environment specific registry. Keeping registries separate amongst environments may seem overkill but it would make your life easier when it comes down to permissions management.

Having one branch per environment also has the added benefit that you will be able to restrict access to certain branches, eg everyone should be able to merge to dev but not everyone should be able to merge to prod.