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?