Wednesday, October 12, 2005

Using Version Control in Web-Development
The use of a Version Control System (VCS) in web-development

Reasons:
Offline-development, more than one developer, testing (staging)-area to try out code on server before production-release, always have good conscience when deleting old dev-files and old thoughts / ideas in todo-lists (all versions of every file is saved in the system!)

My experience:
It took me a long time to even get all the pieces and facts together to actually understand what a VCS does! All guides were all about how to use them. Why should I learn that when I don't know what I was to use it for, and in what context? What happened was I dropped my interest in VCS for some months. First when I really needed a smart solution for offline-dev and staging-area I took back my interest and searched a LOT about it and posted pleas of clarification on desvshed.

(If someone presented me with the reasons above a long time ago, I probably would have started using it a long time ago and saved huge amounts of developing time! VCS correctly used is really a saver!)

But even then, it took me a long time to understand which VCS to use (CVS is the most popular historically, first I thought it was the only one!).

Now I know.

Choosing a Version Control System:
CVS has many shortages, for instance it cannot version control directory structures... Subversion can do this. And this is what I use today, together with the great windows GUI-tool TortoiseSVN.

(SVK is yet a Subversion-like VCS that even claims to have all that Subversion-capabilities plus offline repository-mirroring an such, but without the existance of TortoiseSVK, I will not use it)

Prerequisites:
First of all, my setup is a Windows XP Pro laptop for development and a Linux server with shell-access for production purposes. (I will eventually post my experiences of how to cope with the situation when there is no shell access available, as i am to face that problem in a project coming up soon).

(Do not worry if you do not understand some of the terms I am talking about. Either you read the Subversion Book now or after this. All will come clear after the initial chapters in that book!)

Note! Common knowledge about linux adminstration, user permissions etc are recommended. I had to learn it from scratch when I started this out. Be prepared rather than learning as you come, it will save you head-aches. Expecially: Understand that permissions are grouped into user, group, and all - levels.

Use a google search to find a nice Linux adminstration tutorial, and use LAME for reference.

My way of using VCS with web-development:
Using shell access to my production-server I have set it up using the ssh+svn:// method (using putty-tunneling for a secure simulated direct connection). I guess WebDAV is faster, but I haven't come araound changing it to that. It was simply easier to get ssh-tunneling up and running, and furthermore it is easier to set up permissions, as it uses the server's linux-permissions for this. (All activity through WebDAV goes through the webserver-user)

Preparations:
I...
1. Checked-out a working-copy to my laptop and got a server up and running on the checked-out code.

Tip: Have the server function as much alike as possible as the production server. This will save you lots of headaches! Especially important to be the same: mysql, apache and php versions, php safe mode activated or not, activated modules.

2. Checked out a working-copy to productions folders on the server, but called them www-staging etc.

When doing step 1 and 2, be prepared for a bunch of permission issues to take care of to make the checked out copies work with the webserver (since php in safe mode on linux is much more sensitive than on windows, where everything commonly is run by the same user and with adminsitrator rights). The most common solution here is to allow full read and write access globally* to folders for file-uploads, image-uploads etc and wherever the webserver-userneeds to alter stuff in the filesystem.
Also, some svn-ignores is good to put in wherever you have temporary files lying around. (Remember to ignore the compile-directory if you use S

* Globally because the user that created the files (you) most often is not belonging to the same permissions-group as the webserver-user! If your linux supports Access Control Lists, you might want to use that instead.

3. Made a common include that together with virtual host-directives adjusts settings and paths depending on the location of the code - so that they all can work on the different locations with the same identical code-base. I use the following scheme:
http://local.site.com - Local on laptop (dns through hosts-file only)
http://staging.site.com - Staging code and copy of the production database
http://preview.site.com - Staging code and uses the production database
http://www.site.com - Production code, live
4. Deleted the production folders and checked out working copies for the production code instead, once I was certain it was to work.

(Use
# Disallow browsing of Subversion working copy administrative dirs.

Order deny,allow
Deny from all

in httpd.conf for safety)

I you managed to come this far, you are ready to fully use VCS in your web development!

Basic work-cycle, an example:
(One developer, offline development, staging-area)
1. Develop on laptop and the local server. When considered done, commit.
2. Update the staging folder, try it out and fix bugs. Commit changes when done.
3. When moving to production, tag this bugfixed code-base, lying in the trunk, as /tags/site_v1.#.RevisionNumber
4. I then switch the production-codes code-target to this tag-folder. And voila changes are made live, already bugfixed, almost instantly.

This is very summarized. I have more advanced routines in use, taking advantage of branching for post-bugfixing and patching already staging-released code while developing further on laptop etc, as well as coping with routines for two developer's development.

If you plan to use Subversion, read the Subversion Book, it explains everything!

Database Management for Version Control Systems:
As for today, there are no VCS-systems for Databases. I have solved my needs of at least being able to syncronize my development and staging-databases from time to time by using the great SQLYog Enterprise's Database synchronization wizard. It is totally worth the money (99$ for commercial use. 49$ for private).

I have tought of a semo-automatic model of using VCS with a database, and I figure I eventually will use it as well. As for today with my needs, it would be too much overhead though. My thoughts about how to do it, however, are posted here: Database Management for Version Control Systems (Coming).

Forum posts that eventually lead up to this blog-entry:
- Set up a CVS server to which it it should be possible to log on with ie NuSpherePHPED (December 22nd, 2004)
- Developing Web Applications in Three Levels for offline work (July 9th, 2005)

No comments: