On Sunday 10 August 2008, Greg Dunlap wrote:
When I created Deploy I had a set of goals in mind that I felt a solution had to meet. I think (hope) that most people will agree that these goals represent the ideal of what any staging and deployment system should achieve. Some of this will repeat some of what has already been said insightfully and thoughtfully above, but I kind of wanted it all put together in one place.
[snip]
I've been thinking a lot about this thread. It has developed to be a very informative and important discussion. I was not aware of the deploy module, and it definitely looks like a very big step in the right direction. Taking this a step further I could *not* imagine myself deploy-ing data onto a client's live production site, although I happily use 'svn export' on such a site for code. Making all sorts of changes to the DB in a bulk is very frightening to do on production, and something I will try to avoid as much as I can. Assuming I am not the only one with this thoughts, I tried to analyze the basis of that hesitation. SVN does version management. I trust the tool that if I had made a catastrophic change on production, I can always switch back to the old version and leave production in a stable state. I can also provide a log of changes and create a diff to know what has changed. In order to be able to use a deploy style solution on a production server, IMHO, it must provide a trackable, version control style of logging and rollbacks. Somebody in this thread mentioned another VCS that might be used - maybe this is what he meant.. I am not sure. Have you considered this type of version control handling for deploy? Or maybe this is achieved through the serialization that was discussed elsewhere in this thread? --yuval