The Power of Control: Is Version Control Still Necessary?

Every company already has a Web site, is developing a Web Site or redesigning their Web site. Initial sites that simply provide information can be quickly put into production and are fairly easy to maintain. On the software side, only content has to be managed. However,it does not take long to realize that traditional software development tools are needed to support an E-business development environment.

• 10/01/2000

Every company already has a Web site, is developing a Web Site or redesigning their Web site. Initial sites that simply provide information can be quickly put into production and are fairly easy to maintain. On the software side, only content has to be managed. However, when the Web site is enhanced to accept orders that tie into the organization’s Enterprise Resource Planning (ERP) system, it becomes much more complex. It gets even more complicated once in production and changes have to be made while development continues. It does not take long to realize that traditional software development tools are needed to support an E-business development environment.

And what about that ERP system? Implementing an ERP system is supposed to eliminate in-house development.

However, each company or organization does business differently and each ERP vendor has developed their solution differently. They never match the way you do business perfectly.

Thus, custom code and in-house development lives; although, officially discouraged. Discouraged because more custom code not only means more development. It also means more support. It should also mean version control.

Version control software allows the management and maintenance of multiple versions of files by multiple people. It prevents developers from overwriting each other’s changes. More importantly, version control allows new development to continue while a production version is maintained. While there may be multiple developers, generally only one can have write access to a particular version at a time. Other developers can still have read access. The big benefit is that developers do not have to waste time determining who overwrote their changes and then recreating those changes. Also, while developers have read or write access, they cannot delete stored file versions, which are generally known as archives. This prevents accidental deletion of files that could occur if not using version control.

Version control also provides the ability to quickly back out code to a previous version if a problem is found in production. However, version control is not really meant for backing up files. Versions still need to be backed up to another disk or backup device.

Most version control systems also provide some additional functionality such as version or file comparison. This allows a user to compare two versions and display the differences. This helps in debugging problems.

In addition, most version control systems utilize a centralized repository for storing archives. These are generally organized by project. This is another benefit to the development team as they all know where to go to get the project’s files. This is particularly important in today’s virtual working environment. It also makes the job of the Configuration Management team much easier by allowing them centralized access to file versions.

Configuration Management (CM) is a technique used to manage one or more files – constituting a "product release" – through the entire software life cycle. To a large degree, CM depends on version control to fulfill this need. However, CM also includes change control (i.e., processing a request to change functionality). It also includes deployment to production after the change has been coded, unit tested and processed through quality assurance. Any code changes are managed through version control. Configuration Management by its nature adds a level of control in the organization. CM like any other "control" organization requires a reporting capability. This may at least in part be provided by the version control system. So Configuration Management is a superset that includes version control.

As with any enterprisewide effort, management support is required up-front. It would be a frustrating effort to try to implement version control without management buy-in. Keep in mind that management will have to be involved to approve the purchase of version control software. Therefore, management should be brought into the process early.

Management should be inclined to provide a development organization with the tools that will minimize risk to an enterprise effort by emphasizing discipline in orchestrating file changes while minimizing costly maintenance. Management should establish the use of version control as a company requirement and a specific version control tool as a standard. This needs to be clearly communicated to development organizations.

Specific requirements for version control are dependent on each development department. It is best to find a tool that satisfies all requirements in order to have a single standard tool. There are many benefits to this, including making it easier when developers change departments. When they do, they will not have to learn another version control tool.

The most important requirement is that the version control software must support the development environment. Some tools operate only under UNIX or only under a Microsoft operating system. Some version control tools are built into the development environment.

Another important feature is whether the version control product should be web-based or client/server with a graphical user interface (GUI). Since everything is going in the direction of the Web, it should not be surprising that version control is too. Web-based version control systems are generally easier to use but even easier to deploy and maintain since there is essentially nothing to install on the developer’s desktop.

Another important decision before getting started is to establish a standard file naming convention. If working with an ERP vendor, review their naming conventions. With a slight modification, it could make your custom filenames unique. Unisys prefixes its custom filenames so they look like this: UXXX<original vendor filename> where "U" stands for Unisys customization and XXX is a geography. The filename (UBRZINVEDI810.sql) in Figure 1 follows this standard where BRZ is an abbreviation for Brazil and INVEDI810.sql is the original filename. (Note that the vendor prefixes its filenames with a three character module abbreviation. In this case, INV indicates that this in the inventory module.) This also necessitates changing the first row of Figure 1. It should now be "UBRZINVEDI810.sql Revision History" instead of "UBRAINVEDI810.sql Revision History." This is just changing the A to a Z in the filename as BRZ is the appropriate abbreviation for Brazil.

Build on the use of the vendor’s file naming convention and consider using the vendor’s directory structure for deploying customizations again with a slight modification.

After management support, this could be the most important part of implementing version control. First, you want to encourage use and second, you want it used correctly. Understand that version control software is not difficult to use, but if a developer has not been trained, it is an easy excuse for not using the tool. Written documentation or online help files are also beneficial but are often not read. An hour or less of training is really all that is needed for developers. Administrators need some additional training and may want to actually attend the vendor’s training. In this way, the administrator(s) can provide the user training.

Version control is still required in today’s development environment. Determine your requirements. Get management support. Evaluate tools and purchase one that will be deemed the development standard. Implement the use of the tool with a standard file naming convention and start taking advantage of the benefits of version control.