0

Just a small bit of background. Right now my team tags release candidates in version control. I've learned that this may not be the best thing to do because we still have to go through user acceptance testing before we really release whatever application was tagged. So now we know that tagging release candidates is not the best thing, but it does provide something useful. It allows me to track the binary file that was a result of that build that is that tag. So if someone pushes up a tag called 1.2.0, then I know to pull 1.2.0 when deploying to the environment we use for UAT. Then if that passes testing, we use 1.2.0 to deploy to production.

I want to move us to use a branching strategy instead to distinguish release candidates, from changes that are currently getting user-acceptance testing, from changes that are currently in production. And plus I've learned that tags should not appear until we have conducted UAT and it has passed QA. But the artifact server that we deploy from requires that artifacts are stored by version numbers. So at this point, we will have to come up with a different way of deploying things in our internal testing environment, which I don't want to do. I want to keep how we deploy applications as similar as possible to the way we deploy in production.

Has anyone encountered a situation like this before? Or am I going to be forced into deploying to our UAT servers one way, and then deploying to our production servers a different way?

1
  • Why don't you just use a build number for the tag instead of a semantic release version, and tag it with the release version once the work is completed? Alternatively, tag it 1.1.x, where x is your candidate build, and move it to 1.2 when you're done. Oct 24, 2017 at 17:18

1 Answer 1

1

If you're still working on 1.2.0, you could tag your release candidate builds something like 1.2.0-RC.123, '123' being a unique identifier (commit hash, build number, timestamp, etc) making it easy to reference.

Once QA'd and approved and deployed, you could tag it with the 'official' version, 1.2.0, or 1.2.0-RELEASE.

It's easy to clean up old tags if you no longer need them. If you're using git, something like the following:

git tag | grep '${pattern}' | xargs -n 1 -I% git push origin :refs/tags/% (remote)

and/or

git tag | grep '${pattern}' | xargs -n 1 -I% git tag -d % (local)

You can derive and automate a lot of this if using git-flow like release branches in the form: release/1.2.0.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.