The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

How do you version control web applications?

I started using Subversion a while ago for school projects just to get a feel for it. The small amount of time I spent setting it up was already paid back many times over while writing my compiler. (stuff like, "this was working last night, why isn't it now? *diff* ooooh, I changed those variable names)

However, I also had to develop a web application for software engineering class, and I couldn't really reconcile all the different file locations and configuration files that needed to be maintained.

For example, you might have:
SQL database definitions - these need to be kept somewhere but you have to alter them if you alter the database, or run the SQL file if you've updated it directly.
Actual database contents - sometimes you have to make fake data to test some pathological case, or use the real data to see if the program works as expected
Source files - php, pl, asp, py, whatever files that actually run the app
Configuration files - for example, I use a db.php that contains the code to connect to the database, but it has to be different on my local dev machine vs. the remote target server

So how do you manage these unwieldy collections of files?
blake8086
Tuesday, May 31, 2005
 
 
==>So how do you manage these unwieldy collections of files?

It's called "being a professional". Everything in the source repository. Everything.

==>For example, you might have: SQL database definitions - these need to be kept somewhere

We keep 'em in the repository

==> but you have to alter them if you alter the database,

You shouldn't be altering the database directly. Only through script files, and those script files are in the repository.

==>Actual database contents - sometimes you have to make fake data to test some pathological case,

"fake data" (a.k.a. test data) is entered via a script, and the script is in the repository. We use SQL Server, so it's easy to setup test data by hand, and spew it out into an XML file that can be loaded easily for testing "fake" scenarios. The XML data file is in the repository. The script to load the XML data file is in the repository.


==> or use the real data to see if the program works as expected

Well ... that's the one exception to the "Everything in source control" rule. We don't keep user data in the repository, however we do keep static system data and initial populations for lookup lists/tables in the repository. User data is stored in the database and kept in a library of backups.

Incidentally, you'll want to write a number of scripts that grab particular elements out of your production database and pull it to your DEV/TEST database -- e.g. pull a given customer and all employess, orders, products, shipments etc. that are related to the customer. You'll use these a lot.

==> Source files - php, pl, asp, py, whatever files that actually run the app

In the repository.

Don't forget your server config that has really nothing to do with the particular site/development effort you're working on. For example, in my world, once we setup a site in IIS, we script the config for the site so it can be created in a snap from the script. This script goes in the repository.

==>Configuration files - for example, I use a db.php that contains the code to connect to the database, but it has to be different on my local dev machine vs. the remote target server

In the repository. Both versions (your personal version, and the production version.

That's why we have source control. It gives us a nice way to manage all this stuff, and keep it consistent.

Attempting to keep track of this stuff w/out source control is a quick trip to the insane asylum.
Sgt.Sausage Send private email
Tuesday, May 31, 2005
 
 
Sarge is 100% correct.

If you lost everything but your repository, would you be able to build/deploy/test/use your application?  If the answer is "yes", then you're doing it correctly.

For database stuff, I have it check the server path.  If it's running on a server referenced as localhost (my local dev box) then it connects to dev... otherwise do production.  Vary this one as necessary.
KC Send private email
Tuesday, May 31, 2005
 
 
The usual thing to do with web applications in SCM is to have scripts to install them, this way you also have a reproducible setup system.
Baruch Even Send private email
Tuesday, May 31, 2005
 
 
"Configuration files - for example, I use a db.php that contains the code to connect to the database, but it has to be different on my local dev machine vs. the remote target server"

I have a single configuration file that contains information for each host the site runs on.  It sense at runtime which host its running on uses the appropriate configuration.

This saves a lot of headaches.
Almost H. Anonymous Send private email
Tuesday, May 31, 2005
 
 
Yup, everything in version control. The problem of getting all the files back out to where they need to be is one of scripts. Personally I tend to go for a combination of make,rsync and perl for the special cases...

Wednesday, June 01, 2005
 
 
You're lucky you're using Subversion! Here we pay big bucks for PVCS that stopped evolving about the same time RCS did.

Everything said here is right on track.  You will be happy that you scripted everything.

I'm at a bank, so we would not pull production data to a lesser environment, but most other things apply.
wishing-I-were-able-to-use-svn-here
Thursday, June 02, 2005
 
 
I am using IIS, coldfusion, php and mysql and i am trying to figure out some way of using version control but not sure which will be the best way to go in windows based systems
sandy
Thursday, June 02, 2005
 
 
I can't speak to the Windows world, but I have an app built on Linux, specifically Debian, that works wonderfully.

First, everything needed to get the app started from the beginning is in our source tree.

Second, we use Debian packages for all installations.

The database updates are handled via the package system, automatically.  We keep 2 sets of SQL scripts around - 1 to create the database and initialize it, and 1 to update from one released version to another.

I have spent a decent amount of time getting the package system all working, but that measn that everything about how to install the system is documented in, at least, code, and we actually use that method on a regular basis, so it gets tested, both of which are critical aspects of this.
Ryan Anderson Send private email
Thursday, June 02, 2005
 
 
Sandy,

I'm not sure which aspect of version control you're concerned about, but if you're new to version control, I'd highly recommend installing SVN for Windows with the Tortoise SVN client. Just install it on your own machine and use a local repository. Then get "Pragmatic Version Control using Subversion" ( http://www.pragmaticprogrammer.com/titles/svn/ ). If your experience is like mine, then pretty soon you'll wonder how you ever did without it.
EKB Send private email
Sunday, June 05, 2005
 
 
I would keep everything in version control (since you already know Subversion I would stick with that). For my projects using <a href="http://www.rubyonrails.org/">Ruby on Rails</a> I keep all of the files under Subversion control (the scripts I use to generate the MySQL DB, images, .rb files, .rhtml files, .css, project outlines, UI mock-ups, etc).

At work we keep 3rd party libraries under version control as well (this includes binaries to which you do not have the source code as well as the documentation associated with each version of the library).
Sean Mountcastle Send private email
Monday, June 06, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz