I'm Dan Previte, a web developer and a geek in general living in Chicago and working for
Hopefully by now you know what Subversion, aka SVN is. It's a version control system that keeps track of changes made to files like source code and documentation. It's similar to CVS, but with some major advantages. We've been using it at work for awhile, and I really like it. Changes don't get lost, we can easily keep track of released versions, and once we get around to implementing it SVN will tie into our bug tracking system.
We usually have two servers for a project, one as the development server, and the other a production server. We all have a working copy checked out on the development server. Using virtual hosts with Apache we all have our own sub domain. So for example on our dev server we'd have:
- dan.ourproject.com
- mike.ourproject.com
- jc.ourproject.com
With each pointing to that developers working copy. We make our changes on the dev server as we're making the site, when we finish a task we check it in, and everyone does an update often to avoid conflicts.
When we are getting ready to push a release out to the production server we have to be careful since a lot of the time there are people using the site. We don't want to have errors pop up on the production server. To make sure it runs on that server as well as it did in our working copies, we have a staging area. It's on the same server as the production copy, but only we have access to it.
So we do an export to the staging area, click through the site and run through a checklist of things to check for and once we're sure it's running ok we copy that to the production area and it's live.
Since we want to keep track of the versions we push out to the production server, we give that release a version number, tag it in our Subversion repo, and update our project wiki.
This workflow has worked well for us and if we have a problem we can always roll back to a previous release. We can also use the Change Report feature of SmartSVN to do a kind of code review when others commit code. If we see something a little strange we can fix it, or if's completely crazy we can roll back quickly.
This is just how we do it, if you do it differently I'd love to hear about it so just leave a comment. In the future I'd also like to look into using Git in a similar way.
A Look at SVN for Web Development…
Every web developer, no matter what language you use should know the workings of a version control system. The one I most often use when working on projects is Subversion, aka SVN. SVN not only helps me keep my code organized, it also allows for ot…
&php; - PHP News, Updates, and Tutorials
February 14th, 2008
Nice article, one thing I might suggest adding though. Have you considered having a commit hook that will update a development copy with the latest committed changes automatically? This saves the tedium of doing the commit/update/test cycle manually, you can commit and go straight to the browser for testing.
JGM
February 15th, 2008
I’ve thought about that, but haven’t tried it. How does that work with conflicts?
So far we’ve just been manually doing updates so we have a little more control over things. We have a post commit script send an email to the team working on the project that keeps everyone up to date.
dprevite
February 15th, 2008
We use svn on webdigs.com in a very similar way. The only difference is that we use http://trac.edgewall.org to keep track of changes, and the timeline & ticketing is great for keeping ahead of bugs and knowing what the team has been upto
Robert Speer
February 15th, 2008
So, do you use branches? One of the things I found that helps is to have a staging and production branch. Then you can merge from trunk into staging specifically what you want to deploy and then promote to the production branch when it is ready to go live. This way you always know what is in staging, what is in production, and you have a little more control over what features are pushed. I wasn’t sure by your post if you meant you have three dev branches for each dev or just that each dev has thier own local copy of the repo?
Kyle Beyer
February 15th, 2008
Each dev has their own subdmain with their working copy on the development server all working off of the trunk. We haven’t used branches at all yet, but I think we will for larger features in the future.
We are tagging versions released to the production server to keep track of what’s on the production server, and staging is just where we test things before a release/tag.
dprevite
February 15th, 2008
Using Subversion for Web Development…
[...]An example of the workflow when using Subversion with web development.[...]…
Web 2.0 Announcer
February 15th, 2008
we used svn1click instead of apache
it works well
nazanin
February 16th, 2008
How do you actually copy the files from staging area to the production area? Are you doing a simple “cp here there” or something advanced like rsync? A simple cp unfortunately doesn’t know anything about deleted files…
I’m interested because I’m currently building something similar and I realized that i need to find a way to deal with deleted files.
Fabian
February 16th, 2008
Wow, I’ve never used Subversion for bug-tracking. I’ll check out how it works though. The stuff we’re using now is our project management tool – Wrike http://www.wrike.com. What I like about it is that I can make a screen shot, paste it into my email and send it to the system as a bug to be fixed. Pretty cool, isn’t it? Saves loads of time.
Darren
February 16th, 2008
There are many other things which are a big question mark.
- What to do about database versioning?
- Suppose both persons commited task1,task2,task3. And for some reason i only want to upload task2 only.
Afnan
July 25th, 2008
We are starting to use a similar method for versioning on our video library. The best method we came up with was similar to yours. We are using asp.net for the website however, just on the same physical machine and it seems as if everything will work out well. We have one beta server where changes to the truck will be auto updated to consolidate modifications.
SQL Server is similar in that each person has their own sql server database. From their database scripts will be generated nightly into a directory structure that generates one script per object, and uses different subfolders for tables, views, procs, and functions. The Database Repository then checks for changes and merges them nightly to the beta database server.
Only tricky part I see is handling the global.asax and Web.config files because database locations are stored there. Thus they always need changes manually merged to not overwrite the association between website and database.
Nate
August 24th, 2009