# Slightly OT: SVN deployment of Rails apps **URL:** \ **Category:** Rails\ **Created:** [October 25, 2006, 12:43am UTC](https://www.ruby-forum.com/t/slightly-ot-svn-deployment-of-rails-apps/73515 "2006-10-25T00:43:22Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![bradeck](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/7cd45c/32.png) [@bradeck](https://www.ruby-forum.com/u/bradeck)\ **Post date:** [October 25, 2006, 12:43am UTC](https://www.ruby-forum.com/t/slightly-ot-svn-deployment-of-rails-apps/73515/1 "2006-10-25T00:43:22Z")
I need advice from deployment gurus. I’m working on setting up a “permanent” stable deployment environment for a large app that is going live. The application will be undergoing significant new feature development after deployment, so we will be keeping svn branches to separate stable from new features. Right now, code is deployed by hand (svn up && mongrel\_cluster restart) from trunk. I will be setting up Capistrano for deployment and misc. tasks. We aim to have 3 environments on the production server: development (features branch), staging, and production. My primary question is: should I deploy from trunk or a “release” branch? Cal Henderson’s “Building Scalable Web S.s” suggests deploying from a branch for larger projects and/or teams. This is a large project, but not a large team (2 developers). If I deploy from a branch, would that limit my ability to concurrently develop multiple features in other branches? What would be the purpose of trunk, then? ---
**Author:** ![bradeck](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/7cd45c/32.png) [@bradeck](https://www.ruby-forum.com/u/bradeck)\ **Post date:** [October 25, 2006, 1:01am UTC](https://www.ruby-forum.com/t/slightly-ot-svn-deployment-of-rails-apps/73515/2 "2006-10-25T01:01:23Z")
> My primary question is: should I deploy from trunk or a “release” > branch? Cal Henderson’s “Building Scalable Web S.s” suggests > deploying from a branch for larger projects and/or teams. This is a > large project, but not a large team (2 developers). If I deploy from > a branch, would that limit my ability to concurrently develop > multiple features in other branches? What would be the purpose of > trunk, then? Doesn’t matter. Subversion doesn’t really have a “trunk” or HEAD in the sense that CVS does. It’s just a convention (at least as I understand it). They are all just copies of the repository at one point or another… For what it’s worth, we have a “trunk” copy with the rule that it can be pushed at any time and will work. This lets our designers tweak things easily and 99% of the time don’t have to deal with any branches (please, no comments about designers pushing content 🙂 Then for things that take more than a couple of hours/days us developers create a branch, work, test, then merge back into trunk and push. So we have a lot of short lived branches and one main trunk. Seems to work for us, but we push constantly it seems. If you are more structured you could certainly have a “production” branch that you merged into… definitely a lot more stable that way as little things won’t creep in unless you intentionally put them there… ---
**Author:** ![bradeck](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/7cd45c/32.png) [@bradeck](https://www.ruby-forum.com/u/bradeck)\ **Post date:** [October 25, 2006, 1:21am UTC](https://www.ruby-forum.com/t/slightly-ot-svn-deployment-of-rails-apps/73515/3 "2006-10-25T01:21:26Z")
i got into trouble once by deploying from a tag, which is functionally equivalent to branches in subversion. eventually it came time to upgrade, and as i had no automatic deployment tool (was in php) i wanted to run something like `svn update`. well, thing is, the new code was in the trunk (or possibly another tag), which meant that `svn update` just wouldn’t work. svn doesn’t do smart updates when you’re switching repo paths at the same time (svn switch may have helped, but i didn’t learn about it until too late). now this may not apply to your situation because capistrano, per my superficial understanding, doesn’t use `svn update`. but still, it’s something to think about. i personally will be shy for a while about deploying from anything except trunk. =) Brad E. wrote: > server: development (features branch), staging, and production. > > > – Lance I. Web Applications Developer RBS Interactive removed\_email\_address@domain.invalid ---
**Author:** ![bradeck](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/7cd45c/32.png) [@bradeck](https://www.ruby-forum.com/u/bradeck)\ **Post date:** [October 25, 2006, 1:27am UTC](https://www.ruby-forum.com/t/slightly-ot-svn-deployment-of-rails-apps/73515/4 "2006-10-25T01:27:27Z")
I use a main trunk that deploys to staging and then production by passing a parameter to the cap call. You can see how I do it on my blog [1]. Then after I deploy to production, I tag the release as the current production release. I use svnmerge.py on this tag, so that I can merge changes into it as needed. This way I can merge back into it needed changes, or even fix on it specific release related bugs. And I can redeploy both to staging and production from it. I have a pretty complex script that does the checkout, svnmerge.py actions and also prepare the plugins for that. But after the script does it’s thing, I only have to use svnmerge.py merge, and svn ci to update this tag. Please note that like Philip said, in svn trunk/branch/tag are all just conventions. They are exactly the same as far as you are concerened. That’s why I can continue development on a tag if needed. Bye, Guy. [1] Deploying to staging and production: [http://devblog.famundo.com/articles/2006/09/28/deploying-to-staging-and-production-with-capistrano](http://devblog.famundo.com/articles/2006/09/28/deploying-to-staging-and-production-with-capistrano) On 10/24/06, Brad E. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > and misc. tasks. We aim to have 3 environments on the production > > > – Family management on rails: [http://www.famundo.com](http://www.famundo.com) - coming soon! My development related blog: [http://devblog.famundo.com](http://devblog.famundo.com) ---
**Author:** ![bradeck](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/7cd45c/32.png) [@bradeck](https://www.ruby-forum.com/u/bradeck)\ **Post date:** [October 25, 2006, 2:03am UTC](https://www.ruby-forum.com/t/slightly-ot-svn-deployment-of-rails-apps/73515/5 "2006-10-25T02:03:30Z")
> > prepare the plugins for that. But after the script does it’s thing, I > > 1. Less cognitive overload – just use branches for feature development > Might be worth downloading this and giving it a read through “just > because”. > **[K-12 Education Curriculum – K-12 Learning – Savvas Learning Company](https://www.savvas.com/)** > > Savvas Learning Company creates award-winning K–12 education curriculum, assessments, and K-12 learning solutions to improve student outcomes. (look for the downloads section) > 1. Because it’s a web app, it only has one ‘release’ version at a > time. There would never be a situation where we have to support an > old release. Write this on a piece of paper and stick it to your wall for when the time comes you have to do exactly that. heh heh 🙂 ---
**Author:** ![bradeck](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/7cd45c/32.png) [@bradeck](https://www.ruby-forum.com/u/bradeck)\ **Post date:** [October 25, 2006, 1:55am UTC](https://www.ruby-forum.com/t/slightly-ot-svn-deployment-of-rails-apps/73515/6 "2006-10-25T01:55:28Z")
On Oct 24, 2006, at 6:25 PM, Just S. wrote: > complex script that does the checkout, svnmerge.py actions and also > prepare the plugins for that. But after the script does it’s thing, I > only have to use svnmerge.py merge, and svn ci to update this tag. > > Please note that like Philip said, in svn trunk/branch/tag are all > just conventions. They are exactly the same as far as you are > concerened. That’s why I can continue development on a tag if needed. Thanks to everyone for the help and advice. I think I might end up deploying from trunk for 2 reasons: 1. Less cognitive overload – just use branches for feature development 2. Because it’s a web app, it only has one ‘release’ version at a time. There would never be a situation where we have to support an old release. Thanks again for the help. Brad ---
**Author:** ![bradeck](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/7cd45c/32.png) [@bradeck](https://www.ruby-forum.com/u/bradeck)\ **Post date:** [October 25, 2006, 2:13am UTC](https://www.ruby-forum.com/t/slightly-ot-svn-deployment-of-rails-apps/73515/7 "2006-10-25T02:13:30Z")
On Oct 24, 2006, at 7:08 PM, Philip H. wrote: > > > redeploy both to staging and production from it. I have a pretty > > (look for the downloads section) Neat, thanks for the pointer. > > 1. Because it’s a web app, it only has one ‘release’ version at a > > time. There would never be a situation where we have to support an > > old release. > > Write this on a piece of paper and stick it to your wall for when > the time > comes you have to do exactly that. heh heh 🙂 Yeah, I’ve been bitten by making those kind of statements before. Luckily, I control the deployment environment, so… they get the releases I tell them they get. 😉 Thanks again– be ---
**Author:** ![bradeck](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/7cd45c/32.png) [@bradeck](https://www.ruby-forum.com/u/bradeck)\ **Post date:** [October 25, 2006, 6:56pm UTC](https://www.ruby-forum.com/t/slightly-ot-svn-deployment-of-rails-apps/73515/8 "2006-10-25T18:56:19Z")
You can also keep a tag called LATEST\_STABLE to which you can copy a tag or a known revision point on trunk.