Using Source Control for Advanced Web Development
Conferences can be great sources of information. In the technology industry, the culture of knowledge sharing that is present at conferences can expose web developers to new ways of working that are in practice at other companies. Given the nature of the web profession, it is natural that the technology stack and workflow is a topic of frequent discussion. Large companies often employ cutting-edge tools to help produce quality work in an efficient manner.
Even on a small team with a limited budget, it is possible to add a number of enterprise-caliber development features to the technology stack that works within the budgetary constraints. Source control often is the foundation for these advanced development features, and many companies use open-source technology to deploy and manage their code.
Benefits of Using Source Control
Using source control provides the benefits as described hereafter regardless of what modern system is implemented (e.g. Mercurial, Git, Subversion, et al.). Source control also provides a means to track and fix mistakes for the occasional “oops.” I personally cannot imagine going back to developing without using source control in some form, and many thought leaders in the software engineering and computer science field such as Martin Fowler and Jeff Atwood share this opinion.
Source Control the Easy Way
The easiest road to using source control is to use a hosted provider. Each provider will often offer additional services such as integration with bug tracking, time management, code review, or deployment services. I currently use Beanstalk at my full-time employer to manage the projects for my department. I couldn’t be happier with their service, but there are many other vendors out there to consider. My short list includes:
- Assembla (Subversion or Git)
- Beanstalk (Subversion or Git)
- Bitbucket (Mercurial or Git)
- FogBugz (Mercurial or Git)
- Github (Git only)
Include Common Code from Remote Repositories
One helpful but underutilized feature of source control is the ability to include code from remote repositories. The use case for this feature is to help manage a piece of code that is used on multiple projects. In my experience, many developers put a copy of the common code in each repository, but that is far from ideal since any change to this common code would have to be patched and updated in multiple places in this scenario.
A better alternative is to reference the common code from an external repository. The way this is done is by setting the
svn:externals property in Subversion, by adding a subrepository in Mercurial, or by adding a Git submodule depending on what type of source control is being used. Despite the difference in terminology, these accomplish the same feat - external projects can be referenced without creating duplicate code inside of the repository. Updating the common code in this scenario is simply a matter of pulling the changes from the remote repository into the local working copy.
Working with svn:externals
The trick with
svn:externals is that the property needs to be added to the folder that is one level up from the folder being brought into the project. For instance, if the contents of
https://svn.example.com/trunk/scripts/common need to become part of the project in the
/assets/scripts/common folder, the
/assets/scripts folder first needs to be under version control in the repository. Then the
svn:externals property needs to be added to the
/assets/scripts folder via command line or GUI such as tortoiseSVN.
Working with Git Submodules
Automate Whenever Possible
Version control facilitates the ability to automate tasks, and this is probably the largest enterprise-caliber feature of an advanced development platform. This automation is accomplished by using a commit hook, which is essentially a small program that performs a task either before or after code is committed to the repository. If the task can be scripted, it can run automatically as a commit hook. Git, Mercurial, and Subversion all offer hooks that can be used to run code before or after the commit.
The use case for automation that I use most frequently is deploying code to a server. Using hooks in version control to deploy code removes an element of human error that can occur by simply using an FTP client. Optionally, some vendors such as the aforementioned Beanstalk include deployment features in their product that are driven by source control, or external tools such as Capistrano or Jenkins can deploy code from the repository directly.
There are great resources about deploying code written and presented by some brilliant developers. Deploying code from version control is a much better solution than using FTP because it allows the development team to see what is deployed to each server as well as provide a mechanism for rolling back code to a prior version.
Craft-centric marketplace, Etsy has a wealth of information on their development blog about how they deploy code:
- Quantum of Deployment
- How does Etsy manage development and operations?
- Optimizing for Developer Happiness
Scott MacVicar mentions how Facebook uses git for source control but deploys from subversion in his presentation at PHP NW 2011.
Other Use Cases for Automation
In the modern development stack, version control is more than a way to keep track of code. It is an indispensable tool that is a catalyst for collaboration, deployment, and development.