Joey Adams Dot Net

By the title you should already have a good idea what I am going to be speaking about, and the variety of options out.

Whether you are a single at home developer, or a member of a complex development team, you can benefit from version control systems. I will not go through explaining the intricacies of each system (check the footnotes for links), but in case you are unfamiliar with version control, I will give an overview.

Version control systems are highly collaborative storage mechanisms, called repositories (or repo),  for storing application code.  The current working code that is being developed is located in a central location. Each developer then pulls a copy from the repo, and works on it on  his/her own machine locally. When finished working (and testing) the modified code is updated in the repo.

So what is so special about that? Nothing, actually in nuts and bolts, a repo is nothing more than an archiving system.  The real power of version control comes with the tools integrated.

Keeping the working code in a central managed location is the heart of version control systems (VCS). This is a fantastic idea, as you know everyone has an up-to-date version of the application. There are built-in conflict resolution tools in most VCS as well.  So if you are trying to update some code in the repo, but your colleague has made a change to it since you have grabbed a copy, you can analyze the changes, checkout the most recent version, continue testing, then update the code when you are finished. Some systems allow file locking, which is  an option that only allows 1 developer at a time to work on a specific file. If you have a highly modular layout, this is a great option, however on bigger teams with larger files, this may be too much of an overhead. Mastering conflict resolution flows for your VCS is the most preffered way for synchronous and seamless collaborative development.

Perhaps the best part of version control is revisions. Everytime the code in the repo is updated from a developer, it marks the changes and a new revision  is created.  This means if we find a problem in our current revision, we can always roll back to the previous working copy. This also allows us to track changes, so debugging problems between revisions is trivial. Say in revision 3 we encounter an error that could not be recreated in revision 2. All we have to do is check the  logs on the version control software to find out what changes were made. This can assist us in debugging and analyzing our application.

On top of this, most versioning software has access lists. This is one  of the biggest selling points, imho, for larger corporations. Leaking private confidential data, such as application code or binaries, is a serious problem. Being able to tell who has what copy and made what changes at what time will assist in cracking down on any outsider sharing of data, as well as malicious insertion/modification of program code. As a note, version control is also used outside software development, for keeping control and access over confidential data and schematics.

Branching and tagging is another huge plus of using version control. Say you are working on an application, and have finished a stage of development ready for release, but of course,  you still want to keep working on the application. You take your tested working copy in the repo, and then copy it into a ‘branch’. You can give this a descriptive name, such as ‘release1′. Now people can grab the released version of your software, while you keep working on the latest version. At a point in time, you may want to fix something you find wrong in release1. All you have to do is grab a copy of ”release1′ from the repo, make your changes, then update the branch in the repo.

Tagging is basically, and sometimes literally, the  same thing as branching. The difference, is tagging is often used to identify code revisions in the past that are unmanaged.

If you are familiar with linux distributions you may be having dejavu. Does current and stable ring a bell. Think about it. Current is the code in progress at the time and stable  is a branch for code that has been tested and deemed ok for common use. There may be tags, or branches, of older versions of the software as well.

Now last but not least, my favorite reason for version control. Security. . Let me say this in caps so everyone gets it. STOP MAKING DIRECT CHANGES TO YOUR PRODUCTION WEBSITE/SOFTWARE. We are all human, we make grammatical and syntax errors all the time and have to clean, re factor and debug our way out of them. Using version control, it is possible to never allow a developer to modify source on a production system. Here is my, single at home developer, way of doing things using version control.

We have a production server which is web facing that serves our application. There is also a repository (or repositories) for holding our application code. Our repo has our working version(trunk), a “staging” branch and a “live” branch. We have the developer network which is confined, and has no access to the production network systems.

We have a development server which is a copy (hardware/software) on the developer network, which has a user for each of our developers as well as a corresponding vhost. Our developer workstations are connected to this network and securely map their own home folder on the development server. A developer checks out the latest copy of code from the repo, and makes changes and modifications. He views his changes and does testing through his vhost on the development server. Whenever he is satisfied, he simply updates the repo with his modified code.

Once the team is confident with the current state of the trunk, they copy the current version into the “staging” branch. Depending on topology and the environment in which we are developing, there is a vhost for the application on either the development server (for project managers) or a vhost on a web facing system (for clients) that requires authentication and in some instances, as with project managers, only access is granted to certain machines on the network. This vhost is for our staging branch. The code is checked out into the proper location, and the vhost points to the wwwroot of our application. While we wait on our client or manager to approve/deny the revision, we can still be working on the current version (trunk) of our software.

If the code needs to be edited, the developers can simply grab the branch from the repo, make changes, then update the repo, etc..

Once the revision is accepted, then we can copy our ’staging’ branch into our ‘live’ branch. Then a systems administrator in control of the production server simply grabs the newest copy of the ‘live’ version which updates our application on the web. Never did a  developer have to touch anything on the production server. If we need to quickly fix an issue, we simply grab a copy of the live branch, make changes, then seek approval if needed, update the live branch, then have our administrator check out the newest version of the live branch (this will  only update changed files, not replace every single file, which is a plus for performance).

Another benefit to this form of development is scalability. With central code repositories, we can have mirrors and load balanced servers all over the world grab a copy of the latest version every (day/hour/on demand/etc) and be confident that they are identical.

The bottom line is version control is being used by big development teams. If you want to be a professional, you need to be using the tools that professionals use. Your knowledge increases your marketability as a professional developer. Version control is also something that can legitamately help us in our SDLC, and allows teams to simultaniously work on multiple projects securely at radically different points in time, without making any changes to our production servers with great organization and ease.

Stay tuned for day 3.

//Info
Revision Control:http://betterexplained.com/articles/a-visual-guide-to-version-control/

// VCS
Subversion: http://subversion.tigris.org/
Perforce: http://www.perforce.com/perforce/products.html
Git: http://git-scm.com/
CVS: http://www.nongnu.org/cvs/