Software configuration management: The single solution myth
Stories Columns Opinions Resources
Preflight builds spread wings for smoother projects
Developers are increasingly turning to preflight builds, allowing them to experiment with ...
|
Coverity creates program to enforce code adherence
The Architecture Analyzer uses mapping technology from the company's Software DNA static a...
|
QCon 2008 features domain-driven development
This year's QCon invites speakers like Eric Evans and Dan North to talk about domain-drive...
|
.NET similarities prove golden for Silverlight
Microsoft has focused on making Silverlight 2 symmetric with the .NET platform, and that h...
|
SOA Watch: New economic realities
In the current economic downturn, agile programming and SOA are attractive options that bu...
|
Integration Watch: A new twist on threads
The key to raising the efficiency of multiprocessors is to shrink the overall workload by ...
|
Integration Watch: The Return of NetRexx?
Java scripting languages are seeing a surge in popularity, with NetRexx looking particular...
|
Windows & .NET Watch: Transaction crowd gets a boost
With multicore chips becoming the standard for processors, the need for a flexible, usable...
|
From the Editors: Election should shake up JCP
Rod Johnson has the right ideas for opening up the Java Community Process, and he may be a...
|
Letters to the Editor: Sun gives REST, SOAP choice
A reader takes issue with a headline on our story about Sun working with REST along with S...
|
Guest View: Be smart and lazy
The optimal solution for problems is the simplest one, so always aim to streamline your ap...
|
Zeichick's Take: From EXEC to EXEC 2 to REXX to NetRexx
Andrew Binstock's column last week, "The Return of NetRexx," brought back some fond memori...
|
Advanced Corda CenterView™ Data Visualization for the BusinessObjects™ Intelligence Platform
Corda Technologies presents a white paper on pervasive BI. The BusinessObjects business in...
|
From Mobile to SOA: A Guide for Optimized Application Deployment
Customer need has driven the emergence of multiple computing tiers. Today’s application d...
|
e-Kit: Web Application Security
Is your network secure? What about your web applications.
If IT security is your top p...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
By Jennifer deJong
July 1, 2008 —
Toolmakers aren’t known for looking beyond their own bottom line. But when it comes to software configuration management, many are putting aside their short-term interests. Rather than insisting on being the only fish in the pond, they see strength in diversity.
When asked how best to contend with the complexity of managing multiple SCM offerings found in most IT shops today, SCM toolmakers are pointing out the value of pragmatic approaches, as opposed to standardizing on one solution. They say that allowing different SCM tools to coexist—and devising an effective strategy to share data among them—permits IT to create a single view of all development projects, without the pain of wholesale migration to a single SCM offering.
“Combining all SCMs isn’t always the answer,” said IBM Rational vice president Mike O’Rourke. An alternative, he said, is a “connector strategy,” in which individual development teams stick with their own SCM tool and figure out how to share what data, with whom and when.
The challenge of combining systems, or just the data in them, comes as IT shops find they’re running more SCM tools than ever. The proliferation is driven not only by mergers and acquisitions, and the emergence of offshore teams in India, but also by open-source projects, which force code committers to use open-source SCM offerings.
“We live more and more in the world of open-source and commercial offerings,” said Corne Human, a product marketing director for Borland. So when it comes to SCM tools, he added, it’s best to just “live and let live.”
By advocating coexistence, toolmakers are bowing to the reality that SCM consolidation is a hugely complex, often unrealistic, undertaking, said Forrester analyst Jeffrey Hammond.
“The costs of conversion are substantial, and for a large development shop, the migration process can take years,” he wrote in an October 2007 report titled, “Standardized Software Change And Configuration Management: Achievable Goal Or Wishful Thinking?” What’s more, SCM consolidation is increasingly seen as a low priority for IT shops focused on the more strategic mission of delivering applications that help the business achieve better results, many toolmakers said.
Lost in migration
One issue that complicates migration is that SCM tools rely heavily on business logic that has been built into them over time, said IBM’s O’Rourke. In this case, business logic refers to the rules and procedures unique to each development team, such as, “When you check in code, do this; when you check out code, do that.” When migrating from one SCM tool to another, much of that valuable information falls by the wayside. This means losing the “one-to-one mapping of the business logic,” O’Rourke noted.
Another challenge in consolidating configuration management tools is that they are invariably linked to other tools, such as those for requirements, defect tracking and change management. A migration from one SCM offering to another can affect many other systems.
“That creates a degree of complexity that teams must pay attention to,” said Microsoft’s director of marketing for Visual Studio Team System, Norman Guadagno. They must ask themselves, “How are you tracking and managing the requirements for systems you are merging?” he noted.
Database compatibility issues also arise during consolidation. For example, when the Microsoft SCM offering, Team Foundation Server, is merged with IBM Rational SCM tool ClearCase, data must be refactored. The Microsoft offering stores data in the SQL Server database, while the IBM tool relies on DB2, Guadagno explained. “It’s a tough problem.”
To ease the way, SCM experts offered best practices for maintaining peaceful coexistence, or migrating when necessary. They also have advice on how to share data among SCM tools, painting a picture of the overall state of all development projects. Here’s what they said:
Look for tactical opportunities to reduce SCM tools, but don’t force it, wrote Hammond in his report, “Don’t Expect a Straight-Arrow Path Toward SCM Tool Consolidation.” To reduce licensing costs, get rid of older SCM tools, added Tom Tyler, a consultant for Perforce Software. Also helpful is combining tools that are used for similar types of projects, said IBM’s O’Rourke. “Some SCM offerings are geared to waterfall, others to more iterative development.”
Focus on better visibility, not on migration, said Laura Wingerd, Perforce Software’s vice president of product technology. “The goal is visibility and accountability.” Wingerd explained that the aim is to create a central, big-picture view of who is working on what, which people are spread across which projects and what your bug rates are. Accountability, she said, focuses on such factors as who has access to which files and who is responsible for what.
To create a big-picture view, pull data from each SCM, said Guadagno. Rather than merge back-end SCM systems, create reports in a third-party tool that combines data from separate SCM systems. Things to measure for management’s sake include code completion and bug tracking. Developers themselves are focused on more rudimentary information, such as what’s checked in and what’s checked out. Create reports in tools such as Microsoft Excel, or through one’s change management or project management portfolio, which can automatically collect data.
Let tools help you coexist. SCM tools themselves can help ease coexistence, said Hammond. Increasingly, toolmakers are letting developers check code into their own tool while also updating other SCM tools used by other teams within the company. That way, said CollabNet senior product manager Bob Jenkins, each team sticks with its tool of choice but “gets visibility into the other code base.”
Fix the process first, said AccuRev’s vice president of marketing and business development, Cliff Utstein. That, he said, is good advice whether you opt for coexistence or a wholesale migration. “You have to ask what the process should be going forward,” he said. “What happens when I’m done developing code? Do I share it on an hourly basis with the rest of the team? Who reviews it? Do I run unit tests? Does the build happen when I check in code?”
Achieving consensus on such issues is challenging but crucial. “If you ask three different engineers, you get three different answers,” Utstein said. Additional concerns arise as one moves up the chain of command. “How do you ensure the code is reproducible anytime? How are you handling the final release of the code? What is the checklist before release? Is there a security audit, a compliance audit?” asked Utstein. All the process work must happen up front, said Serena senior director of product marketing Nathan Rawlins, adding, “The tooling is second.”
Make the move. If you opt for migration, import data from one system to another knowing that you will forgo some of the business logic, said O’Rourke. “It’s disruptive, but most tools have an export or import mechanism, so you get as much of the code and the history as you can.” Keep the older system around, in case something comes up in older code. “But for new stuff, you are on one system.”
When you merge, maintain mirrored systems, said Guadagno. This is a reality for perhaps one release cycle, he said. “That way, you can drop back to one system if anything goes wrong.” And something probably will, he added. “Merging [SCM tools] is a software engineering challenge, largely because of the different ways information has been kept. You have to find the common language, get some perspective on what you have pulled in and figure out the new structure for your code.”
Make a clean start. Sometimes it’s better to forgo merging altogether. Instead, take the current state of a project and start in a new tool, maintaining earlier project status in the legacy offering, said MKS product manager Colin Doyle. “Obviously, this approach is not acceptable if you want history.” But it’s often a workable alternative to reconciling the different ways that SCMs define terms and concepts, he said. For instance, one tool might define a project as a container and associated subcontainers. But another tool might use an entirely different concept for a project.
When migrating, don’t move everything, said Jenkins. “The gut reaction is to ‘migrate everything.’ ” A better approach would be to keep current the legacy system data pertaining to projects that are longer, he said. “Even if you are eliminating the legacy system, don’t move its data to the production repository. Set up a legacy repository instead. It’s a pack-rat thing to want to take everything.”
Too much information is stifling, added Wingerd. “A lot of naive managers will take that approach at first, but then they learn to focus.” She recommended retaining all assets related to the release of current projects: configuration files, source code, builds.
Don’t underestimate the scope of the challenge. Consolidating SCM tools—or merely pulling data from them to create a unified view of all projects—is a “hard, hard problem,” said O’Rourke. “There is no cookie-cutter approach, and it can take years and years.” The goal is to make management comfortable with what’s going on in development, added Guadagno. “Ultimately [SCM consolidation] isn’t really an engineering problem; it’s an organizational problem.”
Related Search Term(s): SCM, AccuRev, IBM, Microsoft, MKS, Perforce
Share this link: http://www.sdtimes.com/link/32405