This deployment won't have the latest changes to the project
haans74
Posts: 8
If I make changes to project steps and/or variables, why do I need to create a new release?
In our environment we have been naming our releases with the convention - Major.minor.date.build Example - 1.0.20140304.3
For a particular project, we would need to deploy to dev, qc, test and production. If we make a change to the project steps or vaiables after deploying to dev and qc, but prior to deploying to test and production, this would force us to have different releases on dev/qc and test/prod. We don't like this. Any chance there will be a future update that will allow changes to project steps and variables without being forced to create a new release or deleting/recreating the release and redploying?
In our environment we have been naming our releases with the convention - Major.minor.date.build Example - 1.0.20140304.3
For a particular project, we would need to deploy to dev, qc, test and production. If we make a change to the project steps or vaiables after deploying to dev and qc, but prior to deploying to test and production, this would force us to have different releases on dev/qc and test/prod. We don't like this. Any chance there will be a future update that will allow changes to project steps and variables without being forced to create a new release or deleting/recreating the release and redploying?
Comments
The behaviour you see is by design- if you could change variables and re-deploy the same release you have no way of knowing what was actually deployed based on the version number. Releases, once created, cannot be changed. This is to provide you with reliable knowledge of what a given version contained.
Having said that, if it's something a lot of users don't like we could probably look in to changing the behaviour- please suggest it on our Uservoice site so we can see if it gets a lot of votes?
Redgate Software
You can keep the same version and use something like "-r1" at the end of the release number to note that something was updated (usually variables), and if you want to go more in-depth, you can use the comment block to note every change.
I was a little frustrated with this at first, but it adds to the great change control Deployment Manager offers.
I get what you are saying about changing variables, but I believe it forces you to create a new release even if you just want to add new target nodes to the project for a particular environment. Not sure, I have to double check that.