Instant Development Network
Update July 2012: We noticed that the website for the cre824 contest is now pointing to a different site, so we’ve removed the links and replaced the urls to sampledomain in the text examples.
We completed the cre824 competition this morning. Our submission came out great, and we somehow managed to complete everything we set out to accomplish. My favorite piece of the competition was our development environment, which we set up the night before.
The central piece of a good development environment is a centralized, version controlled code repository. We’ve recently migrated our stuff from cvs to subversion, which is almost the same but better. Developers keep their own working copy of the code, which they can checkout either to their home directory on the development server, or to their local machine via SvnX, which is a great gui interface to subversion.
Apache runs on the development server, and there’s a name-based vhost for each developer that has their checkout directory on the server. As they make changes to their copy, they can immediately view them through their own vhost. For instance, my checkout directory is
~scott/dev/cre824, and my vhost is
http://dsh.sampledomain.com/ with its document root pointed to my checkout directory.
For developers using SvnX to checkout to their local machines, we have Apache running on their computers. They can have their own vhost pointing to their checkout directory, or they can just view files directly without the web server, though then they forgo any PHP processing.
Once code has been checked in to the repository, it can be exported to a development vhost where we can view and test the current code. For this project, it was
http://dev.sampledomain.com/. Then all we need is a simple shell script, export-cre824, that exports the code from subversion and into the dev vhost. Subversion’s export command, in contrast to checkout, gives you a clean copy of the latest code without any subversion files or directories in it.
For cre824, we brought a router, switch, and Debian Linux server. Freddie and I worked directly on the server, while Jon and Ryan worked on their laptops and used SvnX. The last part of the development cycle was to deploy our site to the production server. For cre824, we only had ftp access, so another shell script was written to copy the dev vhost to the production server. By automating and testing this process early on in the competition, we were able to quickly and confidently push new versions to the server.
It can be a little tricky to move a project into a new development environment, so we prefer to start them in one. We were able to prepare our network before the competition, so it didn’t take time away from development in that regard. There is some overhead involved with checking things in and out, but it is the only way to safely and efficiently have multiple people working on code at the same time.