I'm currently working on a CI/CD pipeline for my Java Spring Boot application, which has two main stages: a Pre-Production Pipeline and a Release Pipeline. In the Pre-Production stage, I build and test the app, creating a Docker image tagged with a `-SNAPSHOT` version (like `myapp:1.23.7-SNAPSHOT`) before deploying it to a Docker registry for testing. Then, in the Release stage, I want to promote this tested SNAPSHOT image to production by giving it a clean version (e.g., `myapp:1.23.7`) and creating a Git release tag before deployment.
The issue I'm facing is that various files within the Docker image still contain version strings that show `-SNAPSHOT` in the production environment, such as `manifest.json`, `package.json`, JAR manifest files, and any compiled assets with embedded version info. I want to promote these tested artifacts without rebuilding everything, but I need advice on how to properly handle the version strings during this process. Any insights?
2 Answers
One approach you might consider is to avoid using the `-SNAPSHOT` tag altogether and instead adopt a continuous build number or ID. This way, you can keep track of your builds more cleanly. If you do want to stick with snapshots for testing new features, you’d need to think about versioning after you've validated a build. For instance, if you need to fix a bug after testing version 1.23.7, you could create a hotfix and publish a new version, like 1.23.8. This could help maintain a clearer version history without overwriting builds.
But I get the concern about having multiple builds with the same number in your history – it does muddy things up a bit, doesn't it? Maybe I'm overcomplicating it, but it feels tricky!
Personally, I'm a fan of keeping things minimal. I don't worry too much about version string cleanup because I avoid shipping code directly in the Docker image. Instead, I use the commit ID as the Docker tag, thus making the repository the source of truth for versions. This way, you're less concerned about whether the version is semver or calver since you’re using the commit ID as your identifier – it's straightforward and reduces the clutter.
You’re definitely not overthinking this! It’s a common dilemma. Using a continuous versioning system can be beneficial, especially for tracking changes without confusion over overrides. You might also want to consider adding a suffix for builds that are still in testing to differentiate them.