This deployment won't have the latest changes to the project

Automated deployment for web applications and databases

Moderators: Mike Upton, justin.caldicott, Sean.newham, csmith, chirayu, DavidSimner, david.conlin

This deployment won't have the latest changes to the project

Postby haans74 » Wed Apr 09, 2014 7:49 pm

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?
haans74
 
Posts: 6
Joined: Thu Jan 30, 2014 8:43 pm

Postby james.billings » Tue Apr 15, 2014 3:02 pm

Thanks for your post.
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?
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.

Postby jehrman » Wed Apr 16, 2014 4:42 pm

I prefer the release saving every variable.

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.
jehrman
 
Posts: 2
Joined: Thu Nov 07, 2013 5:16 pm

Postby haans74 » Sun Apr 20, 2014 8:26 pm

I was just thinking our environments might change from time to time. ie: Adding a new web server to the farm, etc.
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.
haans74
 
Posts: 6
Joined: Thu Jan 30, 2014 8:43 pm


Return to Deployment Manager

Who is online

Users browsing this forum: No registered users and 0 guests