Source Configuration Management (SCM) is an essential part of the Application Development lifecycle. Any kind of software development project is impossible to complete without some sort of source control manager tool.
For the first eight years of my career in IT, I have had an opportunity to use such tools as PVCS, CVS, RCS, and Aegis. The main function of these tools is to provide a framework within which a team of developers may work on many changes to a program independently and record the history of source files and documents. But, Source Configuration Management is much more than that—it is not only control of versions of files, it is also establishment of baselines and, more importantly, control of how file versions can be grouped together into logical tasks.
Two years ago, I was introduced to a new kind of Source Configuration Management tool—Synergy CM. This tool is a task-based Configuration Management solution. It answers all of the directives posed by Source Configuration Management. Synergy CM is not the only task-based Configuration Management tool out there. There is also a tool called Perforce. Unfortunately, I have not been able to use Perforce, but from reading up on it, I realize that the tool attempts to offers similar features. But, given the fact that IBM, owner of Rational ClearCase Software (another SCM), acquired Telelogic (developer of Synergy CM) last summer, I am confident that Synergy will capture a much larger market share in the near future.
This article will cover major features of Synergy CM. Furthermore, it will uncover some of the complexities associated with using the tool. I will leave it up to you do decide whether the tool is worth your consideration.
Suppose the requirements call for two enhancements to be implemented:
- Enhancement One: Update Business Constants and Rules Constants
- Enhancement Two: Update Rules Manager Interface and XML Parsing
After identifying what source code files have to be modified, the application developer creates two new tasks (see Figure 1).
- Task 27036: Business Constants and Rules Constants
- Task 27037: Update Rules Manager Interface and XML Parsing
Figure 1: Two new tasks
Then, the developer checks out files into their appropriate tasks (see Figure 2):
Figure 2: Checking out a source file
Task 27036 now contains the following checked out files (see Figure 3, upper section):
Task 27037 now contains the following checked out files (see Figure 3, lower section):
Figure 3: Checked out files
After coding has been competed, the application developer checks in all the files (see Figure 6) by completing the tasks (see Figure 4):
Figure 4: Application Developer completes a task
The preceding exercise shows that developing with help of Synergy CM can help you establish a new abstraction level that allows you to group changes to files into logical tasks.
Here are few more key features that Synergy CM provides:
Checking in files without completing a task
A developer can check in individual files without completing a task. This means that collaboration between developers is possible even when the task is not yet completed (see Figure 5).
Figure 5: The task is not completed, but one file is already checked in
Multiple developers can checkout the same file at the same time
Parallel development is a powerful mechanism that allows developers to share source files even if separate changes need to be made to the same file (see Figure 6).
Figure 6: The same file is checked out by two developers
Full merge and compare features
Synergy CM allows developers to compare and merge versions of the same file. This feature is especially helpful during parallel development (see Figure 7).
Figure 7: Two versions of the same file are compared for differences
Synergy has a concept of a Fix Task. Fix tasks are created to fix a regular task. Because Fix Task is associated with a regular task, one can relate bug fixes to enhancements.
Multiple Release Lines
Synergy CM supports multiple release lines. This is a great feature that I use extensively in my day-to-day life. Here is how it works and why it is so essential to a successful application development process:
A “Release” is a snapshot of specific versions of files. Assume for a minute that you have an application called “ATM”. The application has only three files: ATM.java, Bank.java, and Customer.java. Under Synergy CM, a new release is created: ATM version 1.0.0. This release has all three files. There is only one version of each file.
- ATM.java, version 1
- Bank.java, version 1
- Customer.java, version 1
Suppose you have to implement three enhancements for this application:
- Enhancement 1: “Withdraw” function
- Enhancement 2: “Review Balance” function
- Enhancement 3: “Get Last 5 transactions” function
Your developers create three tasks (Task1, Task2, and Task3), check out files associated with each task, make coding changes, unit test the changes, check in code, and complete tasks.
Say you want to release two out of three changes to QA. For that purpose, you create a new release with a different version—ATM/1.0.1. At the point of creation, ATM/1.0.1 and ATM/1.0.0 are identical.
Once the new release is created, you “move” (how tasks are moved between release is beyond the scope of this article) your two enhancements (Task1 and Task2) to the new release. Now, if you compare releases 1.0.0 and 1.0.1, you will observe that the releases differ; 1.0.1 does not have changes associated with Task 3.
Now, what are the benefits of what you just have gone through?
ATS/1.0.1 can be used to create a QA build. You now have two snapshots: Development environment and QA. I can affectively continue developing in the development release (ATS/1.0.0) without disturbing the code that is intended for QA (ATS/1.0.1). If, for example, you need to fix bugs that are uncovered as a result of QA testing, you can do that in ATS/1.0.1, re-release the code to the QA environment, and not worry that the changes related to Task3 are included in the build.
You now can know and have immediate access to a code base that is relevant to any environment—be it development, QA, or Production.
Furthermore, you can work on multiple development efforts under the same application without the risk of mixing code.
I have to mention that taking the approach of multiple releases is not without its dangers. Let me give you an example.
The ATM.java class has been modified as part of Task1 and Task3. Version 2 of the file belongs to Task3 and version 3 belongs to Task1. When you “move” Task1 to release ATM/1.0.1, you inevitably carry over changes that had been made as part of Task3. To alleviate this problem, Synergy CM has something called “Detect Membership Conflicts.” The “Detect Membership Conflicts” function will let you know that your file contains code that does not belong in the release (see Figure 8).
Figure 8: This listing is produced by the “Detect Membership Conflicts” function
Task-based development, parallel development, and multiple release lines are great tools to help your team to be as productive as possible. Task-based development helps you logically separate and track assignments, enhancements, and bug fixes. Parallel development allows your team to work in tandem. Having multiple release lines can help you map application environments to application code.
It is clear that Synergy CM offers many features that are beyond anything that tool like CVS and PVCS can offer. But, on the other hand, Synergy CM is harder to learn—the learning curve is much higher than it is with tools like CVS.
About the Author
Aleksey Shevchenko has been working with object-oriented languages for eight years. For the past four years, he has served as a technical lead and a project manager. Aleksey has been implementing Enterprise IT solutions for Wall Street and the manufacturing and publishing industries.