Isn't a Spreadsheet Good Enough?
What happens if you deploy the wrong software version; the version that still has the bugs you were paid to fix? Or if the testers test the incorrect version? Or what if the developers modify the wrong version? It can, and usually does end badly, wasting time, wasting resources, and making the entire team look unprofessional. Source Code Management (SCM) and its associated automated tools help you avoid such calamities.
What Are Source Control Management Tools?
Source Control Management tools are applications that:
- Provide a single point of entry and exit for the developer adding or updating code or other files.
- Facilitates the maintenance of revisions, releases, and patches, usually through some degree of automation.
- Facilitates communications between developers, managers, testers, and Quality Assurance.
- Controls the configuration of the latest release.
Without an Effective Source Code Management Process
Several things are likely to happen when a project does not have an effective Source Code Management process. They are:
- You deliver the wrong release to the client. This, of course, makes your team look completely incompetent. Management has to spend time assuring the client it was a one-off mistake. And if you don't have a very disciplined manual process (which tends to be time consuming), it is guaranteed to happen again.
- You test the wrong release, wasting time and money.
- IV&V tests the wrong release, wasting time and money. In most software development processes, even Agile ones, at some point the software has to be delivered to Independent Verification and validation. If the release sent to them does not have all of the revisions, IV&V test results will be meaningless. And if the revisions or modifications were supposed to fix a bug, the bug will still be there and the software will fail - again.
- You develop code using the wrong release, wasting time and money. Rather than spending development time on the correct set of code, you spend your time updating an incorrect file. All of the effort going into the development will be wasted. At a minimum, time will have to be spent seeing if the newly developed code can be integrated into the correct version.
- Your release ends up with undocumented and untested capabilities. As a result they don't get tested by IV&V and if the capabilities.
With a disciplined approach, SCM allows users to keep track of software major releases, minor releases, and patches. It allows the project managers, the developers, and the testers to keep track of source code while it is in development, while it is in testing, and once it is deployed. It forces user to access the code (or files) in a controlled manner. And prevents developers from writing over each other. SCM can benefit virtually any project handling multiple versions or revisions of files of any time. But they generally specialize in source code.
Single Point of Entry and Exit
If configured correctly, an SCM will allow for the existence of, or access to a single version of a specific file. That file can be coding, documentation, comment files or anything else whose version is important. There is only a single copy of the file available for editing. We will discuss histories and versions later.
In general, the SCM will force the user to "check out" a file. This action prevents anyone else from modifying the file until the user checks in the file at the end of their activity, updating the file and the SCM database.
Facilitates Maintenance of File Versions
An SCM should provide the ability to automatically maintain the contents of releases, indicating which revisions, additions, or patches are to be a part of which release.
If, for instance, a release will include a patch to temporarily address a bug, an SCM tool will note this and the patch will be identified. If there are several patches in the release, the SCM will track the patches, the release to which they are assigned, and other pertinent information.
Once the new release incorporating the patches has been developed, the SCM tool should be able to indicate the inclusion of the patches in the newest release.
Graphic Presentation of Release History
Some code management software has the ability to provide a graphical presentation of the source code history. Figure 1 is an example of such a diagram.
The diagram provides an illustration of the history of the development of a set of code. Boxes 1, 4, and 9 represent new releases. 2 and 3 represent code merged with 1 to create 4. Box nine is a merger of 4, 6, and 7. Boxes 5, 8 and 10 are a discontinued effort.
Another advantage or benefit of using an SCM is the increased communications between developers, testers, customers, and management. While the tool does not take the place of communications, it can provide an environment that promotes it.
Most current SCMs provide the ability to comment on specific code. The comments do not have to be a part of the code or file itself. Thus, a discussion between participants, even those geographically separated, becomes possible. And it follows that reports can be generated using the information.
If your developers seem to have insufficient discipline to follow a specified workflow, some applications such as Surround© provide a framework that will enforce workflow rules, even sending an e-mail notification once a step has been successfully completed. Is there a requirement that all involved developers review source code and comment on it before it goes forward? Some SCM systems can make sure reviews are made and notify management if the comments are late. They can enforce the order in which the reviews are submitted. Once the reviews are completed, the system can make the source code available for the next step in the process. If configured properly, they can even send notification e-mails to the personnel involved in the next point in the workflow.
The uses of the workflow enforcement aspect of SCM is virtually without limits. If a management system is able to generate reports, the managers of a project have a powerful tool with which to evaluate the team's and the individuals' performance.
Within an Agile environment, this control or enforced discipline, goes a long way to ensuring the success of the project.
Within an Agile Environment
Solid version control becomes critical within a Agile software environment. The software is constantly changing. Developers are making updates to the code; fixing the code as testers locate errors. In this environment, software and documentation version control become critical, an aid in having the right version all the time.
There are several difficulties in source code management systems. They include:
- The danger of an individual checking out source code and failing to check it back in, delaying access to that code by another developer.
- Loss of access to the SCM will delay everyone.
- If the system does not enforce a specific process (naming conventions, storage locations, annotations), files can be misplaced
But overall, a development project is better off with a well-tailored SCM than without.