My latest CI/CD performs all the functions that a build and deploy system is supposed to. Sure there are some purists that talk about deploying everything, chaos monkey, and so on… but until you’ve trashed a financial database with millions of records your opinion might not matter.CI/CD can promote systems to production either through a push or a pull. And there are not many advantages although some security people would prefer a pull and I understand that… but the last thing you want to do it get your head wrapped around versions. I’m currently tagging my registry images with the pipeline ID. And as each pipeline completes I also push ‘latest’.Depending on the speed of the CI/CD runner ‘latest’ can be assigned to the wrong image. Also, it really isn’t the latest until it’s been pushed all the way around the system. Now that I’m using pipeline ID instead of the one ID:latest I’m seeing that latest can be promoted prematurely.Just look at any of the images on the hub and you’ll see that there is some crazy numbering schemes there… seems that at some point in their projects there is a branch and the promotion of the branch with some config identifies the version. Make sense? It’s just a lot of many versioning. Just look at the golang package… it’s crazy how many versions they publish at once. I think I get the why and how but as a best practice it means there is an army of high priced SREs managing the bits.Right now my project looks like:The build task builds the system, packages it and pushes it by ID and latest to the registry. Staging is a QA instance even though there is a DEV instance too. “Weston” is one prod instance and “Zurvita” is another. The challenge here is that we deploy from gitlab and there is no manual deploy. So at what point does the version become “latest” and does it really matter?