3 ms·
Use latest during development, but push to production using image in your private Docker registry which has proper names and tags. git push -> Docker build (bo
by hpaavola 5y ago
Use latest during development, but push to production using image in your private Docker registry which has proper names and tags.
git push -> Docker build (bonus points for building only if needed [for example only if Dockerfile, Jenkinsfile or requirements.txt has changed], otherwise use latest from Artifactory) -> run all automated tests -> if pass, push the Docker image to Artifactory with reasonable name and tag.
When doing a release, push the image from Artifactory to production.
This way you don't have to have a process to update all the things in Dockerfile on reqular basis, but you still only push to production the actual binaries that are really tested and proven to be ok. And can re-use the actual binary when doing a hotfix of something similar.
- peakaboo 5y agoSo what actually always happens with this approach is that companies stay on ancient docker images, because there is never time for updates as long as they work. It's the same with locking python pip packages to specific versions. Nobody ever looks at it again and you run code that is 5 years old in production. People only look at it when it breaks.