We are ready to create our first production release. We trust our tests, and they proved that it is relatively safe to deploy to production. Since we cannot deploy to air, we need to create a production release first.

Please make sure to replace [...] with your Docker Hub user in one of the commands that follow.

 1  kubectl -n go-demo-3-build 
 2      exec -it cd -c docker -- sh
 3
 4  export DH_USER=[...]
 5
 6  docker image tag 
 7      $DH_USER/go-demo-3:1.0-beta 

 8  $DH_USER/go-demo-3:1.0
 9
10  docker image push 
11      $DH_USER/go-demo-3:1.0

We went back to the docker container, we tagged the 1.0-beta release as 1.0, and we pushed it to the registry (in this case Docker Hub). Both commands should take no time to execute since we already have all the layers cashed in the registry.

We'll repeat the same process, but this time with the latest tag.

 1  docker image tag 
 2     $DH_USER/go-demo-3:1.0-beta 
 3      $DH_USER/go-demo-3:latest
 4
 5  docker image push 
 6      $DH_USER/go-demo-3:latest
 7
 8  exit

Now we have the same image tagged and pushed to the registry as 1.0-beta, 1.0, and latest.

You might be wondering why we have three tags. They are all pointing to the same image, but they serve different purposes.

The 1.0-beta is a clear indication that the image might not have been tested and might not be ready for prime. That's why we intentionally postponed tagging until this point. It would be simpler if we tagged and pushed everything at once when we built the image. However, that would send a wrong message to those using our images. If one of the steps failed during the pipeline, it would be an indication that the commit is not ready for production. As a result, if we pushed all tags at once, others might have decided to use 1.0 or latest without knowing that it is faulty.

We should always be explicit with versions we are deploying to production, so the 1.0 tag is what we'll use. That will help us control what we have and debug problems if they occur. However, others might not want to use explicit versions. A developer might want to deploy the last stable version of an application created by a different team. In those cases, developers might not care which version is in production. In such a case, deploying latest is probably a good idea, assuming that we take good care that it (almost) always works.

We're making significant progress. Now that we have a new release, we can proceed and execute rolling updates against production.