Wanted: A software configuration management (SCM) tool that (a) provides the capabilities necessary to support an organization's software development process, (b) integrates seamlessly with the Integrated Development Environments (IDEs) and other development tools used by the organization, (c) facilitates the organization's change management process, (d) facilitates the organization's build process, (e) requires only modest training for technical staff before it can be installed and adopted, and (f) encourages proper and effective use by technical staff.
Does this request sound like a delusion? It need not be a fantasy with proper planning and adequate organizational support. Below is a practical approach I used to help an organization select and adopt an SCM tool.
Determine the Scope and Potential Impact of the Effort
Anyone who has worked with an organization to select and adopt a new SCM tool can attest to the planning, research, perseverance, support, and diplomacy required to accomplish this undertaking. Chapter 5 in Susan Dart's book, Configuration Management: The Missing Link in Web Engineering, describes this activity well. Most importantly, Susan Dart's discussion of the SCM tool selection and adoption effort emphasizes that this endeavor typically "opens up a can of worms" because SCM is involved in so many aspects across a company.1 For example, an initial decision to select an SCM tool primarily for version control of source code files may eventually lead to discussions about how software configuration management fits into the organization's software development process.
Since SCM impacts many aspects of a company, the scope of the tool selection and adoption effort should account for these impacts. There is little value in launching a tool selection and adoption effort that focuses solely on one aspect, such as version control, if doing so will ignore other SCM issues that eventually will need to be addressed. For this reason, it is important to define the scope of the tool selection effort before starting this endeavor.
To define the scope of the effort, begin by identifying the original need. Ask why there is a need to select and adopt an SCM tool. Common reasons for selecting a new SCM tool include the following.
- A new software development project is starting. The project needs both an SCM process and an SCM tool.
- The SCM tool currently being used no longer meets the needs of the software development organization.
- The software development organization is adopting another new tool, such as a new IDE, which requires the organization to select a compatible SCM tool.
- The software development organization is attempting to standardize on a single SCM process and tool that can be used on all projects.
Whatever the reasons expressed for selecting an SCM tool, begin by documenting them.
The expressed motivation for the SCM tool selection effort will help delineate the scope of the effort. For example, the effort to unify SCM tools and process across a large organization is much greater in scope than the effort to select an SCM tool for a new project that has a relatively small staff. The larger the scope of the effort, more people will be impacted and more issues will need to be resolved.
1 Dart, Susan, Configuration Management: The Missing Link in Web Engineering, Artech House, 2000, page 137.
Obtain Organizational Support for the Effort
Since the effort to select and adopt an SCM tool impacts people and the way they work, an organization should not undertake this endeavor without adequate organizational support. Adequate support means that the leaders at the highest level of the technical organization demonstrate their commitment to adopting a new SCM tool. Without this commitment, the organization is unlikely to endure the cost to adopt the SCM tool. The cost is not merely the purchase price of the SCM tool, but the learning curve and productivity impact that occurs during the tool adoption process.
To obtain the necessary organizational support, the members of the organization who recognized the need to select a new SCM tool must present a business case to management. Management is less likely to be concerned with the technical reasons for selecting a new SCM tool, such as powerful branching support for parallel development, than with the business reasons for selecting a new tool (e.g., the ability to create software quicker and with fewer defects because the powerful branching provided by the SCM tool keeps production fixes isolated from new development). Ultimately, management will want to know what return on investment (ROI) can be achieved by selecting and adopting a new SCM tool. Researching and reporting ROI is important even if an SCM tool is being selected for an organization that does not use one. In this case, advocates of procuring an SCM tool need to make the case that using any SCM tool will provide a tangible financial benefit to the organization.
Once the potential ROI in calculated, perhaps with the help and resources of SCM tool vendors, the proponents of selecting and adopting an SCM tool should work to ensure that management support will not wither when the first setback occurs during adoption. The best way to secure support is to set expectations early with management that there may be significant short-term setbacks before the organization can achieve the desired productivity with the new SCM tool. Do not cave in to pressure to meet unrealistic schedule expectations. Adopting a new SCM tool takes time. Realistically, the organization may need to work through a few complete software development lifecycles with the new tool before the organization can see the benefits.
Staff the Effort
Selecting and adopting an SCM tool is a project, and needs to be managed like one. Like software development projects, the project to select and adopt an SCM tool requires time and resources. Resources are the staff members, and possibly an experienced SCM consultant, who will work on the project to select the new SCM tool. The project is not likely to be a full time effort for all involved, but it is not an activity that can be completed successfully with minimal effort. Selecting and adopting an SCM tool requires far more effort than contacting a vendor, procuring a tool, installing the tool, and attempting to use the tool.
Staffing the tool selection and adoption effort begins with securing a sponsor. Susan Dart describes the sponsor as "the manager who is responsible for the deployment effort, who is not actively involved in the deployment effort unless called upon for help, and who pays the bills for the resources".2 She characterizes the sponsor's duties as fostering the deployment effort, overseeing it, and supporting the needs of the deployment team.3 The sponsor should be a manager whose opinions and actions are respected and supported by the organization's top-level technical management, namely the Chief Technical Officer (CTO) or Chief Information Officer (CIO).
2 Dart, Susan, Configuration Management: The Missing Link in Web Engineering, Boston: Artech House, 2000, page 148.
3 Dart, Susan, Configuration Management: The Missing Link in Web Engineering, Boston: Artech House, 2000, page 148.
Once the sponsor is identified, the project leader needs to be selected. The tool selection and adoption effort should be lead by a technical person who has the interpersonal skills to work with both technical staff and management. The project leader needs to understand and be able to address both the technical and business issues related to tool selection and adoption.
Other members of the team should include developers and technical staff who will eventually use the selected SCM tool. These team members bring the necessary end user perspective to the selection process. Team members should be selected because of their interest and experience. Software developers who are vocal proponents for effective SCM practices are ideal candidates for the team. Technical staff who show an interest in software development process are also very good candidates for the team.
Understand the Organization's Needs and Constraints
After the project is staffed, the first step in the tool selection process is to understand the organization's needs and constraints. Since software configuration management is an integral part of software development, an organization's approach to SCM must fit within the organization's software development process.
Gather details about the organization's software development process by interviewing a representative cross section of the organization's staff. Interview project managers and business analyst's to gain the perspective of how projects are initiated and how business requirements are translated into programming specifications. Speak to developers of varying levels of experience to understand how they translate programming specifications into running code. Interview quality assurance (QA) staff to understand how they test software and identify and track defects.
Document the organization's software development process using the interview results. Distribute the document to those interviewed for review. Following the review, make the necessary corrections then distribute the document to all technical staff and managers who will be impacted by the SCM tool selection. Since the SCM tool selected needs to support the organization's software development process, you need to verify that members of the organization agree on the process currently used by the organization.
Frequently, the effort to select and adopt an SCM tool also involves enhancing the organization's existing software configuration management and software development processes. Even if this is the case, existing processes cannot be improved if they cannot be defined. For this reason, it is essential to understand and document how the organization develops software before introducing a new tool into the process.
Understand the Impact of Process Support on the Scope of the Effort
Process support is one of the most significant factors that impacts the scope of an SCM tool selection and adoption effort. Organizations that desire an SCM tool that supports process, or workflow automation, face a more involved selection and adoption effort than those organizations that require an SCM tool primarily for version control.
How do you determine the right level of process support for your organization? There is no simple answer. Process support may be essential for some shops, but overkill for others. Understanding your organization's software development process will help you determine your requirements for process support. For example, organizations that follow an agile software development process, like eXtreme Programming (XP), will be inclined to shop for an SCM tool that is not process heavy. In contrast, organizations that must follow a more controlled software development process, like defense contractors, will require an SCM tool that enforces this process. Still other development organizations will desire a tool that supports process without mandating a rigid approach.
Before beginning your tool selection effort, determine where your organization falls on the spectrum of process support. By doing so you will be able to focus your selection effort on SCM tools with similar capabilities.
Develop an SCM Tool Evaluation Scenario
Since the SCM tool selected will need to support the organization's software development process, there is no better way to evaluate the tool's ability to support the process than by using a comprehensive evaluation scenario based on this process. While you could examine candidate SCM tools demonstrated according to a vendor's scenario, this activity may not be beneficial if the vendor's scenario does not relate to how your organization develops software.
An extensive scenario or set of scenarios should cover all aspects of your software development process. The scenario should mimic activities that occur from the time your organization starts a software project until the time it deploys and maintains the software produced. Use of the scenario will test how the features of candidate SCM tools support real development activities.
At the very least, the SCM tool evaluation scenario should cover common activities such as check out, check in, branching, merging, and labeling baselines. Since the SCM tool will be used to support team development, the evaluation scenario should reflect team activities. For example, the scenario should simulate concurrent development by having two different users check out, modify, and check in the same file, such that the two users are making changes to the same version of the file.
The more closely the evaluation scenario reflects a lifecycle of your software project, the more effective it will be at helping you evaluate SCM tools against the needs of your project. Ideally, the scenario should cover the common SCM activities that will occur in a complete lifecycle. These activities probably include creating a task branch to support development or maintenance on a separate thread.
The scenario will only serve you well if it is detailed in a document. In the same way that you captured your organization's software development process in a document, you must record the scenario in a document. Be sure to distribute the tool evaluation scenario to the members of the tool evaluation team for review. Once the scenario meets the approval of the tool evaluation team, you are ready to identify candidate SCM tools.
Consider Integrations with IDEs and Development Tools
While developing the SCM tool evaluation scenario, consider the IDEs and other development tools used in your organization. For these tools to work effectively with an SCM tool, there should be an SCM tool vendor supported integration between the IDE (or development tool) and the SCM tool.
Ensure that your SCM tool evaluation scenario incorporates SCM activities performed from within the IDE. Developers who use IDEs to create and modify code should not have to leave the IDE to perform basic operations with the SCM tool, like file check out and check in. The productivity gains of an IDE can be diminished if routine SCM activities cannot be accomplished from within the IDE. For this reason, it is essential that the tool evaluation scenario center on SCM activities that occur within the IDE and other development tools used by the organization.
Identify Candidate SCM Tools
Armed with your tool evaluation scenario, you are ready to investigate candidate SCM tools. Begin your investigation by compiling a list of candidate SCM tools. Do not overlook the relatively new SCM tools that do not have dedicated discussion forums on CM Crossroads. Also, do not overlook an open source product as a candidate SCM tool.
Since there are several SCM tools available, you need to restrict your search to the tools that will work in your environment. To compile your list of candidate tools, first identify the SCM tools that support your development platform, i.e., hardware and operating system. Next, identify SCM tools that provide SCM tool vendor supported interfaces to your IDEs. You should be able to identify the platforms and IDEs supported by each SCM tool from information that is available on the vendor's web site.
The list of SCM tools that support both your platform and IDEs is likely to be long. To narrow the list of candidates, consider your organization's stated needs and constraints. Specifically, consider the level of process support (i.e., workflow automation) needed by your organization. If your organization only needs fundamental SCM capabilities, such as version control and branching support, you probably can eliminate those tools that are process based. However, if your organization requires strict process automation, you can probably eliminate those tools that are not process based.
Classify Candidate Tools Based on Process Support
How do you identify the process based tools? SCM tools that are process based require users to work in the context of a process to perform any SCM activity. SCM tools that are process enabled allow, but do not require, users to work in the context of a process. For example, a process based tool will not allow you to check out a file unless you associate the check out with a task that has been assigned to you. A process enabled tool will allow, but not require, the check out to be associated with a task.
Susan Dart uses a stricter definition to identify process based tools. She characterizes process based tools as having "semantics or knowledge and meta-data that are automatically associated with the notion of state, such as roles and actions or version finding rules (file selections)"4. In chapter 4 of her book, Susan Dart places SCM tools on a spectrum that ranges from evolutionary to full-process. She characterizes "evolutionary tools" as those in which "users have to manually (specifically) do the things that are automatically done by the full-process tools".5
However, just because a tool falls closer to the evolutionary end of Susan Dart's process spectrum does not mean the tool will not provide process support that meets the needs of your organization. There are trade-offs among the tools on the spectrum. The tools that Susan Dart classifies as "full process" provide this capability along with higher complexity and cost. If process support is a criterion important to you, it would be best to examine tools that fall along the spectrum of functionality to determine which tools most closely match your expectations.
Work with Tool Vendors to Research Their Products
Armed with your tool evaluation scenario and list of candidate tools, you are ready to research tools. At this point in the selection effort, SCM tool vendors can be your most valuable resource.
All SCM tool vendors, including open source providers, make information available about their tools on their web site. For this reason, a vendor's web site should be the first place you visit to gather detailed information about a candidate SCM tool. In addition to open source providers, some SCM tool vendors make their software and supporting documentation available for download from their web site. Although these vendors use their web sites for marketing their products, they still employ marketing and sales staff to assist prospective customers.
4 Dart, Susan, Configuration Management: The Missing Link in Web Engineering, Boston: Artech House, 2000, page 111.
5 Dart, Susan, Configuration Management: The Missing Link in Web Engineering, Boston: Artech House, 2000, page 111.
Completing a contact form on a tool vendor's web site is usually the quickest way to initiate a call from an account representative. When you are contacted, the account representative is likely to inquire about your time frame for selecting a tool and the member(s) of your organization who will approve the purchase. Next, the account representative will want to know what other tools you are considering and how you plan to select a tool.
As you speak to the account representative, the representative will "qualify" you to gauge how serious you are about purchasing an SCM tool. You will demonstrate to the account representative that you are qualified because you have identified your needs and developed a way to evaluate candidate tools against those needs. You will explain that the documents detailing your organization's software development process and tool evaluation scenario will be used by the tool selection team to evaluate candidate tools against the needs of the organization.
At this point, you should arrange for a demonstration of the tool to your tool selection team. Provide the account representative with the tool evaluation scenario then ask when the account representative can arrange for a demonstration. The account representative may suggest a web-based demonstration of the tool. This is an excellent approach because you and the other member's of the tool selection team will be able to watch the demonstration from your desks via a web browser and phone. When planning the demonstration insist that the tool vendor demonstrate the SCM tool by stepping through your tool evaluation scenario.
Be prepared to take detailed notes during the tool demonstration. You are likely to have questions following the demonstration about some of the features demonstrated. Your notes will be very useful when you want to compare tools after you have viewed demonstrations of different SCM tools.
Test Drive Candidate SCM Tools
If an SCM tool appeals to you and your colleagues during the demonstration, ask the vendor to provide you with a copy of the tool for at least a 30 day evaluation at your site. Along with an evaluation copy of the tool, the vendor will provide you with support installing and using the tool. There is no better way to get a feel for how an SCM tool will work in your environment than by installing it and using it.
When the software arrives from the tool vendor, document the steps you take to install and configure the tool. Since some SCM tools are complex to install, you may need the tool vendor's support engineer to assist you on site. If this is the case, insist that you perform the actual installation while following the instructions of the support engineer. While this approach is likely to take longer than if you just observed the support engineer, the benefits to you are significant. You will learn far more about the installation and configuration process if you are executing commands at the keyboard, rather than if you are observing an experienced support engineer.
Even if the vendor's documentation is very detailed, you can benefit from recording, in writing, the exact steps you take to install and configure the tool. (Matthew Johnson describes the benefits of maintaining a log in his article, "Logs Aren't Just For Your Holiday Fire", which appears in the December 2003 issue of Crossroads News.) The information that you record in a log will help you as you compare tools. It will also help you when you need to support the SCM tool that you eventually select.
Once the SCM tool is installed and configured, attempt to exercise your evaluation scenario with the tool. Although the tool vendor probably stepped through this scenario during the initial demonstration, you will benefit from executing the scenario in your environment. You will need to determine how to use the features of the SCM tool to execute each step in the scenario. There is no better way to learn how an SCM tool works than by trying to use it to complete real tasks, i.e., tasks that are likely to occur during your organization's software development lifecycle.
Do not be surprised if it takes several days for you to step through your tool evaluation scenario. You may need to invest significant time to set up your environment to execute the scenario. For example, you probably want to place the entire code base for a real software project under version control before you attempt to execute the scenario. Modeling your development environment is absolutely essential before executing your tool evaluation scenario. The more closely you can model your development environment for a candidate SCM tool, the more likely you are to observe how that tool will perform in your environment as you execute your software development process during a software development lifecycle.
Select an SCM Tool
Selecting an SCM tool usually comes down to choosing the tool that feels right for your needs. This is why it is critical to employ a tool evaluation scenario that encompasses the activities that you typically perform during your software development lifecycle. Executing a tool evaluation scenario with candidate tools will put you in a position to know what tool feels right for your needs.
When evaluating candidate tools you can score these tools based on a list of evaluation criteria. In fact, you may need to do this to justify the tool that is selected.
You will be able to make an informed decision by discussing with your team and documenting how each tool performed according to your tool evaluation scenario. When evaluating each tool against the scenario, ask the following questions.
- What features of the tool were most appealing?
- What features of the tool were least appealing?
- How intuitive was the tool to use?
- How smoothly did the tool operate throughout the scenario?
Feature set, ease of use, and stability are important criteria that are likely to influence your selection. In addition to these criteria, you will also need to consider vendor support. During the test drive you probably needed to contact the vendor to resolve problems and get answers to your questions. When you worked with the vendor's support staff you probably observed their response time and effectiveness in resolving your problems. You need to balance your evaluation of the tool itself with an assessment of the tool vendor's support to arrive at an appropriate scoring for the tool.
Consider support even when evaluating an open source tool. While an open source tool may not be supported by a vendor, this does not mean there are no places to turn for assistance. Discussion forums, such as those available on the CM Crossroads site (http://cmcrossroads.com/
Adopt the Selected Tool
Once your team selects an SCM tool, there is still significant work to undertake to adopt the tool. Adopting the SCM tool involves gaining experience with the tool in a production environment. The adoption process is a learning experience for tool users, tool administrators, and management.
A successful adoption effort needs to occur over time. The adoption effort typically requires one or more software development lifecycles. During a complete software development lifecycle, you are likely to encounter the typical SCM activities that you will perform with the tool. These activities include
- branching,
- merging,
- creating and labeling baselines,
- promoting baselines,
- and tracking defects and fixes.
To avoid organization-wide chaos, begin the adoption on a small pilot project, not on a large mission critical project. It is unrealistic to expect that SCM tool use will be smooth during the first lifecycle in which it is used. Even very skilled developers need to work with a new tool before they become proficient with it.
Populate the New SCM Repository
Begin the SCM tool adoption effort by populating the new SCM repository with the code base. The effort required for this task varies greatly. For a new project, populating the SCM repository involves adding existing frameworks and third party code to the repository. For a new release of an existing project, populating the SCM repository involves migrating the code deployed at the completion of a prior release. For the enterprise-wide adoption of a new SCM tool, migration potentially involves moving the code bases of several software projects to the new repository.
Migrating code to the new SCM repository can be a major activity, particularly if file version history needs to be migrated. The simplest migration strategy is to populate the new SCM repository with a single baseline. This can be done by loading the baseline into the IDE then exporting the files that comprise the baseline to the new SCM repository. The most involved migration strategy is to move the contents of the existing repository to the new repository. This requires creating scripts to move the files and version history.
Choosing the strategy to follow is a decision that should be made, or at least recommended, by the SCM tool selection and adoption team. To make this decision, you may need to weigh the desires of the development staff with the wishes of management. Cost may be a factor in making this decision. Even if your organization is legally or contractually obligated to maintain history, you may still be able to do so by keeping the history in the existing SCM repository.
If you need to migrate the complete version history from one SCM repository to another, consult with your tool vendor for migration utilities. Migration is a common request from customers. In addition to migration utilities, your tool vendor should be able to provide you with consulting services if necessary. Keep in mind that migration can become a time consuming project by itself. One of the biggest challenges of a migration effort involves timing. The migration effort can be a moving target if developers are working in an existing SCM repository while SCM staff are attempting to migrate files from the existing repository to the new repository. To undertake the migration while minimizing risk, the migration should be performed on a copy of the existing repository. If destructive activity were to occur accidentally during the migration, the production repository would not be impacted. To complete the migration without impact to the project, it needs to occur when there is no activity in the existing SCM repository, such as over a weekend.
Build Using the New SCM Repository
Before the new SCM tool can be used in a production environment, the SCM staff must be able to build applications using the code in the new SCM repository. While the effort to migrate code to the new repository is underway, an effort to build using the new SCM tool needs to be initiated. Waiting until the new SCM tool is in use to attempt to build is not prudent.
Clearly, to validate the repository migration approach, one or more trial attempts need to occur using a copy of the existing SCM repository. When an attempt to migrate to the new SCM repository is successful, the effort to validate the build process needs to begin. If there is an existing build process, it needs to be attempted using the new SCM tool and repository. Realistically, this entails using the command line interface to the new SCM tool to check out the appropriate versions from the new SCM repository then compile using these versions.
Train Staff to Use the New SCM Tool
Continue the SCM tool adoption effort by developing training for your organization while the migration effort is underway. Ideally, vendor provided training will address the issues your organization is likely to face as it starts to use the tool. Consider working with the tool vendor to develop training customized to your organization.
Customized training should focus on how to use the SCM tool within the context of your organization's software development process. Customized training should also focus on the manner in which developers in your organization will work with the tool. Since developers are likely to see the SCM tool through the IDE, the training should cover how to use the SCM tool via the integration with the IDE. Since people learn best by doing, the customized training should combine presentations with hands-on exercises. Once concepts are presented, staff should complete hand-on exercises to gain experience completing tasks with the SCM tool.
To ensure that knowledge is consistent across the development team, hands-on classroom training should be given to all staff who will use the SCM tool. If this training is not provided by the tool vendor, it can be provided by members of the SCM tool selection and adoption team.
Classroom training presents a cost to the organization because of the staff time that needs to be allocated to this activity, rather than to software development activities. Further, when in classroom training, staff should not be distracted by other activities, like work assignments. The only way to ensure that staff complete hands-on classroom training is with the support of management. Therefore, an organization's work scheduled needs to be pre-empted so that developers and other technical staff can complete the hands-on classroom training.
Roll Out the New SCM Tool Using a Pilot Project
When migration and training are completed, the new SCM tool can be rolled out to the pilot project. If the pilot project is a release of an ongoing software development project, the pilot can begin only after a baseline is created. Ideally, the baseline is created at the end of a work week, the repository migration occurs over the weekend, and the pilot begins at the start of the new work week. Prior to the start of the pilot project, all staff who will be working on the project should have completed hands-on classroom training. Ideally, the staff working on the pilot project completed the training during the week prior to the start of the pilot.
Questions about using the new SCM tool are likely to occur during the first week of the pilot project. For this reason, SCM staff familiar with the new SCM tool must be available to answer questions and assist developers and other technical staff. It is beneficial to have a support engineer or consultant experienced with the new SCM tool on site during the first week of the pilot project. Should problems arise with the new SCM tool, a support engineer can work directly with the vendor's support staff to resolve these problems.
Conclusion
Selecting and adopting an SCM tool need not be a nightmare. To succeed, the effort needs to be scoped correctly, staffed properly, supported by management, and directed to follow a systematic approach. A tool evaluation scenario plays a critical role in the tool selection process. Once selected, an SCM tool needs to be adopted on a pilot project, over the course of a few software development lifecycles.
