Version Control and Projects
2009-02-03 07:49:19
Its only fairly recently that we have started to use true version control. Prior to this, we had a had anarchy. We had directories for each site, then random directories and archives, some correctly labelled as 'sitename-
It was unmaintainable and something had to change.
Many people are of the opinion that version control is only for when you are working in teams. This is untrue. You gain many benefits by moving over to a version controlled system.
Backups are important. Version control gets you part of the way there, but you still need to backup the repository. Its a lot smaller than dozens of full copies of your site in archives and its can be easily automated.
Some of the advatages we have found:
- You don't have to think about backing up... every checkin is a backup and can be rolled back to as needed.
- You have a comment from overy checkin you do so you can understand what changed when.
- You can hook into the checkin so that you can for example, run basic quality tests or generate documentation automatically from it.
- You can get emailed with a diff of anything that changed in each checkin so you can easily see what other team members are doing.
The way we currently work is as follows.
We have three stages for every project; dev, staging and live.
Dev is version controlled, we only try to checkin complete changes so that at any time we can checkout a version into staging and have a working site. While this means that in the event of a development workstation failure some data may be lost, it does mean that a checkout can be done and expected to mostly work.
Whenever we push a dev snapshot to staging we make a note of the revision that was pushed over. If the dev version is a generic backend like our CMS then we try to keep template config files rather than having working config files with credentials for our servers embedded in them. This means that as long as the config format doesn't change, we can keep a seperate config.php on the development environment, on the staging server and on the live server and have each site running on a seperate database and config on a fresh checkout without much effort.
When we are happy with the staging snapshot, we create a tagged version of the dev snapshot from the same revision as the staging snapshot and use this to push a new copy onto the live server.
There are two schools of thought as to whether you should use an export or a checkout for pushing onto a live server, both have advantages.
Using a checkout, you gain very quick upgrades between versions. The downside is that you then have to protect the subversion metadata from public access on the server.
Using export, there is no metadata to protect, however you can't as easily just roll out changes to the site. On large sites this means a roll out may mean up to a minute of downtime unless you are careful.
You can get around this by duplicating your document root and then exporting over the top of it. Once the export is complete, you switch the document root on the server and start serving from the new version. This only works properly if you don't write much into your document root from within you application. Between the time of the copy and the time the document root is changed, any writes within the document root will be lost. You can solve this by only writing application data outside the document root.
This isn't a perfect setup, far from it, but it is a vast improvement over what we had before. There are some things that we have had to change in our workflow, but these haven't been major changes and the advantages far exceed the disadvatages in our opinion.