Node/Express Semantic Release + Docker Image (Artifact) Versions w/n Continuous Delivery(CD)

[codeangler]

With a CI/CD pipeline set up to build, analyze (test, etc), and release a Node/Express applications to a Docker Image, what suggestions do you have for application versioning and container versioning?

One key piece of direction, I’m trying to follow is something I read about Apps in containers just being artifacts passed along environments. Taking this approach to a possible limit then code merged to master sets off a build of a new app version and container version. And since not all code will pass the pipeline analysis this then sets off lots of semantic bumps on the code app when they don’t all pass the pipeline?

[BretFisher]

Typically automated CI/CD pipelines, which should generally do these things in this order:

• git commit webhook to CI
• git clone your repo
• build docker image
• unit tests (either as part of Dockerfile stage or build pipeline)
• image security scans and npm audits (either Dockerfile stage or build pipeline)
• docker-compose functional and integration testing (build pipelines)
• if all successful, tag and push unique build image to repo, tagging as CI job number, commit ID, date/time, or combo of things like epic-branch-commit, etc. None of these should get reused, and these are the tags that should be used in deployments, to ensure the correct image is used, and easy to identify.
• Also tag and push to "human friendly" reusable tags, if you'd like to provide the team easy ways to ensure they are on the latest image... tags like git branch name, latest, etc. These tags are not used for server deployments, but rather for dev's or testers to quickly find the latest of something without studying CI or git history. Some teams don't allow any reusable tags, as to prevent their misuse.
• Kick off automated deployments. Which usually means updating yaml, or using env's with yaml templates. Ideally saving new image tags with yaml into a git repo so that GitOps is being used to document the state of server cluster DevOps operations. The goal here too is also to allow people to easily use git to determine server state rather than digging through CI/CD job history.
• Optional, push a reusable image tag that indicates "current prod version" or "current staging version". This, again, is only for human convenience of someone wanting to run "the same versions as production" somewhere else temporarily, and don't want to look up CI or git logs to figure it out. Maybe image appname:prod is always the latest successfully deployed image to prod cluster, etc.

Notice that there's two distinct image tagging paths... one for machines that are non-reusable tags used to guarantee and easily identify what's running, and a friendlier reusable tag plan for humans. One of the many reasons you want to limit what people/things use reusable tags, is that all the container tools have different ways of handling how they check for "newer versions of this tag". By never reusing tags for CI and servers, you 100% know that's the properly updated image in use.

Hope that helps :)