On 3/15/06, Russ <[EMAIL PROTECTED]> wrote: > So we've been using subversion for a little while with a dev server and a > production server, and things have been great. We make changes on dev, > commit them into subversion, and update on production (we have the code tree > checked out on both).
Good start! > Now we're planning to add a staging server to the mix. So code would get > developed on the dev server, committed and updated to the staging server, > and then when it passes QA, committed and updated on the production server. > > > > I am not too sure how to do this, since we have the same code tree checked > out on both dev and production. I don't want changes meant for the staging > server to accidentally go to production, until they are ready. I'd recommend now that the process is starting to get more complex, implementing some build management into the workflow -- and probably the best place to start is with Ant. Probably the simplest way to handle things for the first pass is to continue doing what you do now, using a checkedout branch on the *staging* server in lieu of production -- same thing you're used to -- then you can create a production build by 1) *tag* the svn code when it passes QA - easiest way is to create a tags directory and then copy the code into a named tag. You probably want to move the dev code to a trunk directory, so the dir structure is myapp/ tags/ trunk/ so then you'd copy the QA'ed trunk to /myapp/tags/REL-1.0 or similar Even better, you'd tag the code as it goes to QA (QA-1.0) and then developers can make changes against that codebase without affecting the main line. 2) *export* the tagged release to the production server. That gets it up there without all the .svn files, and since there's an extra copy of the base files in the .svn directories, might save a lot of space as far as media in the repository goes. And it removes the temptation of making changes directly in production. Plus it means your repository is connected in a write-only way to the prod server. You can automate all of this with Ant scripts, or more sophisticated apps like CruiseControl for continuous build on the development/integration side <shamelessplug>I'm talking about this in my preconference class at CFUnited this summer</shamelessplug> > Is anyone using subversion in this configuration? (dev, staging, > production). How do you have things set up and how do you manage > deployments? It's very common. I'd run out and et Pragmatic Version Control with Subversion and possibly Pragmatic Project Automation, both from the Pragmatic Bookshelf. The SVN books is especially relevant here. -- John Paul Ashenfelter CTO/Transitionpoint (blog) http://www.ashenfelter.com (email) [EMAIL PROTECTED] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:235473 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
