<snip> > > > > 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. >
We don't currently have releases... we have a large application which serves several clients (An ASP). We make changes to individual client's code as well as to the shared code. We make changes and deployments daily. I'm not sure if we can copy it into a tag everytime we make a change... > 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 This would be nice... but the problem I have with export is that it downloads all the code instead of just updating the files that have changed. Also our codebase is about 20k files (including subversion files), so it's probably about half that. My guess is that it will take quite a while to export that. This is not even counting the media files. Also when you check out things you can see if anyone's made any changes to production directly (Which happens sometimes, and needs to be dealt with). If we're exporting things it won't even be possible. In the perfect scenario, we would have something like this: All the changes to dev are done through webdav or something and are stored in a dev repository. Once changes have been tested on dev, they are committed into a staging repository and the changes are updated on the staging server. Once it has passed QA, it is checked in from staging into the production repository and then updated on production. As far as I know though, there is no way to have a working copy tied to more then one repository (or branch) at the same time. > > > 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. > Thanks John, I will check those books out. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:235489 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=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
