Making the move to source control

Question

Ours is a fairly small company (3-4 programmers and 3-4 site designers) that develops a single-purpose PHP web app which provides the functionality to about 100+ websites. We've operated for a couple years in a separate development and production environment which has worked fairly well. There's always been enough separate features to be developed that the programmers never really clash and it was more convenient to work without the source control; even though it had risk of data loss and we've had our fair share of files going missing in an inadvertant move.

The other consideration is that our designers are not tech savvy (I introduced them to html markup, instead of using WYSIWYGs). This has been one of the reasons to hesitate on making the move to versioning.

However, now that we've reached 100+ sites and the development team is growing, I'm trying to standardize our procedures and source-control seems a logical step as far as programmers go. I'm hoping this will also speed up our patch deployments.

Unfortunately, I've very limited experience with setting a source-control system up. What I'm curious to hear about from people with a similar setup, or experience making the switch:

1) Do you version everything (sites, css, html templates, and app code) and thus force the designers to learn versioning? Or is it just the developers that work on the application code?

2) What are some pitfalls to watch out for when initially setting up the source control?

3) Deployment of dev => production tips for source control.

Thanks for all insight.

Edit 1: Dang. Everyone so far is recommending controlling everything. That's going to make me lose my hair early. It's probably going to spark a new question in the near future. Thanks for the advice so far, keep it coming!

Edit 2: A lot of good answers, and we'll be looking into the various version control systems. Thanks for the replies everyone!

Answer 1

It's helpful to have everything versioned, even for designers. And if implemented well with good training, I think they'll find it more helpful than burdensome.

If you're just starting out, I'd strongly suggest using a distributed version control system like git or mercurial. This is the general trend in the world, and there are a lot of advantages. It's easy to work in a disconnected mode, with no network dependency and the ability to do private, unpolished work still under version control, checking everything in centrally when it's ready.

And, not to resort to appeals to authority or anything, but check out what Joel Spolsky has to say on the topic. (Choice quote: "Subversion = Leeches. Mercurial and Git = Antibiotics.") Among other things, he makes the interesting point that these new systems use a new mental model, different from traditional version control — which is why getting into this kind of approach from the beginning is a win.

Answer 2

I would say put everything under version control. Once it all works, you can copy it to a tag which for most SCM systems does not require lots of disk space on the server.

As far as initial pitfalls go you should shouldn't have to worry much; commit everything to the server and if it's not correct you can shuffle it around and delete the extra stuff later. The only thing I would not commit is artifacts that are built from source, i.e., java code files belong in version control but not the compiled classes or entire ISOs / DVDs of "built from source" binaries.

Dev to production is easy, at every major milestone create a branch. The directory layout in the version control system usually looks something like:

/trunk/project /branches/project/version1 /branches/project/version2 /branches/project/version3

So let's say you find a bug in version 2 of the product, you navigate to that branch, fix it, and release version 2.1. All the while you are working on the /trunk/project folder for the new version 4 and it's up to you which features are merged backwards and forwards.

Don't let the SCM kool-aid drinkers fool you, there are very little functional differences between the popular version control systems out there, namely Subversion and Git. The most important thing for your team will be how well those servers integrate with your existing tools. I don't like WYSIWYGs either but it sure is nice to have eclipse-php or other IDEs that are compatible with the server.

Answer 3

With great respect to much of the wisdom that appears above - and it is wise - rollout of version control is like rollout of monitoring systems. My clients say "what should I monitor", and the obvious answer is "monitor everything". But this is not welcome news: they have 350 systems, each of which has 20-30 system variables plus a bunch of usage-specific variables, and they could all be usefully monitored; but there's only one of me, and they'd like to see some results inside a fortnight.

So although I agree that best-practice is to version-control everything, if this isn't practical in the first instance, start by controlling those things whose lack of control has caused you most problems hitherto.

If most outages are caused by the application code, start by controlling that; if most by unplanned CSS patches, control that; and so on.

Not only will this give you the best return for investment-of-time, but it gives you in turn sound reasons for extending the use of version control in future: "Since we added version control to the application code, unplanned outages over 30 minutes have dropped from 11 a month to 2. Those two were caused by static HTML changes, so we intend to version-control those next.".

A graduated rollout also gives you skilled users inside the organisation. Yes, you had to teach all six app developers how to use the system, but they learned, and they're OK with it; now that it's time to roll the system out to the CSS team, you have six more in-house experts than you did three months ago. You may even have converts by this time; a developer who's had his or her arse saved by the ability to promptly backout a damaging change may well be your best evangelist to the CSS team.

Edit 1: if you decide to go this route, a cheap-as-chips backstop is to add tripwire on top, at least on a production box. That way, if Things Break but the VCS says it was nothing it currently has responsibility for, you can quickly identify what has changed, which both speeds the fix and suggests your next candidate for version control.

Answer 4

I'm a developer and have been involved in working as an IT admin before.

To answer your specific questions:

1) Yes, Version everything.

2) Suggest you set up a dummy version control repository and dummy project for people to learn on.

3) Tag the versions that get put into production. even the trials. Then you can always check out a specific version that someone is running.

I see you've tagged the question CVS.

My suggestion is to take a serious look at subversion instead, combined with TortoiseSVN which makes it very easy to use. There is also a TortoiseCVS as well.

I suggest you run an in-house tutorial on version control. I'll be surprised if your developers/designers haven't encountered this before. Tortoise just makes it very user friendly.

It can also be beneficial to install one of the web interfaces into cvs or subversion.

The reason I suggest subversion over CVS is that while CVS is very good, it has some serious design and implementation problems. The biggies for me were: 1) You can't version directories 2) Binary file handling is not too good as lots of things default to being text. 3) No atomic commits. 4) I recall it often messing up and leaving lock files around that I had to remove manually from the code store. There was room for corruption in doing this since your rm the lock files. 5) SSL support and managing users/passwords

Subversion basically fixes all of those problems are probably many others. It also has a lot of advanced features like externals (which I actually do use). And it's possibly to link the users/groups into active directory which you might find useful. At the time I used CVS that wasn't available. It might be now, I haven't checked.

Probably the biggest difference to get your head around svn in using it is that you don't create tags. Instead you create what appear to be copies where the project directory is copied to the Tags folder and given a name. Have a look in the documentation and you'll see what I mean. I know it looks weird but you get used to it.

This website might be of some benefit (although I can't vouch for it): Setting up a modular svn repository for php websites http://www.howtoforge.com/set-up-a-modular-svn-repository-for-php-websites

Answer 5

Version control everything. There's no point having HTML files under version control and then having a site completely screwed because of a change in CSS that is not being controlled, and therefore cannot easily be reversed.

Pitfalls: I personally haven't come across any during my admittedly fairly limited use of version control.

Deployment: I currently use subversion hosted on Windows boxes, both at work and at home. Windows only because that is what is available. Otherwise it could just as easily have been another OS. The key for non-tech users i to give them a simple GUI based tool to handle imports, exports, commits, diffs, etc. What tool to use will depend a bit on the OS and VCS system used.

Use: When I'm making code changes I test and commit often. This allows me to go back as far as necessary when I screw up. Plus, by comparing various revisions and copying parts of the code I don't have to lose every change just because I need to revert to a previous version to fix some stuff-up in another part of the code.

Added benefit: You can give access to the source repository over a VPN or secure connection, allowing users to work from home or elsewhere. e.g. I might get an idea at home and edit my work code there and then, before I lose the thought.

Answer 6

Version everything.

Deployment depends on how much you have to "customize" for each of these sites. If they're identical except for a config file or two, you can just check out a copy of the code to them, and make minor changes. As needed, run your version control's update command for each of the clients.

If you go with the "checkout directly into the customer's site" distribution model, you'll want to be sure that your server excludes access to the version control directories so that people can't browse to http://example.com/.git/ and peek into your internals. Also, I would definitely have a test and production virtualhost for each client in order to make sure that a site update doesn't go haywire. Especially if you're making custom changes to individual clients' files, then you'll need to handle conflicts before changes go live. In this case you'd checkout/update the test virtual host, and when everything works right, you'd copy the test virtual host to the production virtual host.

Answer 7

All that people are saying about what to version is good.

If you decide to go with subversion can I recommend trying the Bitnami Trac stack; http://bitnami.org/stack/trac

It simplifies setting up subversion for you, comes with a ticketing system (which you can choose to use at this stage or not) for keeping track of changes & bugs, and a wiki which you can use to document how you want your developers to use the system.

Give all your Windows developers TortoiseSVN. Teach everyone a few svn command line basics.

At the end of the day the tool is less important than the mindset you need to instil in your developers. Hopefully they'll soon see that version control is A Good Thing becuse it stops them losing work and allows them to revert from dead ends that are leading them nowhere back to known good states. The benefits outweigh the (slight) overhead.