Software Configuration Management (SCM)

Software Configuration Management (SCM)

Proper Software Configuration Management (SCM) can be a lot of work. Companies and teams that lack insight into how to integrate their projects are headed for failure. Using an effective software development tool with built-in SCM can enable a team and company to manage the unmanageable.

Team System improves your team's SCM in the following ways:

• Enables you to develop and manage multiple versions of a product at the same time

• Enables multiple developers to work on the same files simultaneously

• Relates bugs and bug fixes back to their origin

• Merges changes from one release to another

• Manages software builds

• Manages releases

As I mentioned in the initial chapter, improving team communication is a great start for solving problems related to design and development. It's also the basis for improving SCM. Team-based software development is like an orchestra during a symphony, where all the members need to be in sync, watching their manager, and working in unison to bring the deliverable to fruition on time. Managers regularly need to know what state the project is in, how much code churn is in the nightly builds, when the project has reached zero new bugs, and so on. Requiring team members to pull out of their task at hand so that they can answer these questions is quite distracting.

Depending on the methodology you choose, your approach to software development might be quite different from project to project or from team to team, but your need to intelligently store information will be the same as any other. Your team must constantly manage repositories of work items and artifacts, including tasks, risk items, requirements, source code, bugs, and reports. Scattering each of these item types to different tools fractures the already brittle communication pathways of teams and software.

Team System's core concepts of proper software configuration management are as follows:

• Work item tracking

• Version control

• Build and release management

• Team communication

• Reporting

I will explain work item tracking, version control, and build and release management in this chapter. You'll see them further explained throughout the chapters in Part II, which show you Team System in a role-based approach, focusing on the team members and their activities. Team communication will also become evident as you read through those chapters. Although reporting will be used throughout your project's life cycle, I won't cover it until Chapter 10.

Work Item Tracking (WIT)

The term work item abstracts or generalizes the various concepts of software development. A work item can define any actionable unit of information that is part of the software development life cycle. Examples of work items include requirements, tasks, and bugs. Work items have properties, such as title, date, status, and name of the team member they are assigned to. If you allow them to be, these items become the foundation of your software process. As you pass through the various phases and iterations of your project, the work items move with you.

The actual type and format of work items is dictated by the methodology you choose for your project. Microsoft Solutions Framework (MSF) for Agile Software Development defines different work items that ask different questions than other methodologies. Figure 2-3 shows what information MSF Agile specifies for a task.

NOTE
If you choose the MSF for Agile Software Development methodology for your Team System project, the five work item types you'll have available are risks, bugs, tasks, scenarios, and Quality of Service (QoS) requirements. You will learn more about the various MSF 4.0 methodologies in Chapter 8.

Figure 2-3 A task work item as defined by MSF Agile

A powerful feature of work items is the ability to link them to other artifacts, which is key to an effective SCM strategy. Linking a work item to a set of code checked into version control allows the developer or the project manager to track which changes are related to which requirements or bugs. Tough questions such as, “Why was the change made?” and “Who authorized the change?” can now be easily answered. All these linkages can be queried and reported. You also need to know which builds contained which work items. This information is displayed clearly on the Links tab of a work item.

NOTE
Ask yourself this: How many times have you or a developer you know become sidetracked in writing a “cool feature” or adding some functionality that's not called for explicitly by a functional requirement or bug fix? These excursions can cost a project time or money.

If, as a project manager, you're already tracking bugs and requirements in Excel or Project, you should keep doing so. By using the integrated Team System toolbar, you can synchronize work items, allowing you to work in an environment you're comfortable with—even when you're disconnected from the network—if you choose.

Once committed to the Team Foundation Server database, all of these work items are just records in tables in SQL Server 2005. The familiar interfaces and lightweight operational maintenance of SQL Server result in a very short learning curve and back-end extensibility if necessary. You also know that your valuable intellectual property enjoys transactional integrity and robust security.

Customizing Work Item Tracking

Microsoft realizes that the work items it developed for its MSF methodologies won't satisfy everyone's needs. For example, you might want to assign an hourly rate, dollars, security classification, or budget information to a task. Currently, the MSF 4.0 methodologies don't support those definitions.

Team System, however, allows you to add, edit, or delete the actual work item fields, including how they appear in the user interface and any rules and workflow associated with them. These new or altered work items will surface in the various tools and reports throughout your development process based on the methodology templates, just like those work items Microsoft provides by default.

More info
Be sure to check out Chapter 9 for a useful section on how to customize and extend Team System.

Pluggable Methodology vs. Built-In Processes

So how can you have a completely flexible and pluggable methodology? You can't, but let me explain. For example, I can't alter Work Item Tracking so that after 50 new bugs are entered team members need to physically attend a team meeting. I also can't change the infrastructure and workflow of Team Foundation Server.

For example, a typical methodology describes the following items:

• Role

• Work stream

• Activity

• Types of work items

A methodology, however, can't alter these built-in rules of the underlying meta-model:

• Users belong to security groups.

• Users own work items.

• Roles perform work streams.

• Work streams are sequences of activities.

• Work items track activities.

• Activities produce and consume work products.

• Iterations group and schedule work items.

Why am I mentioning this? While you are learning about all the ways in which you can customize and extend Team System, keep in mind that there are basic, intrinsic rules when you use Team System.

Version Control

Team Foundation Version Control (TFVC) was built new, from the ground up. Microsoft did not just update Microsoft Visual SourceSafe® and change the name. The new version control is a multitiered architecture and, as such, offers the same benefits as those enjoyed by the work item tracking architecture. Unlike Visual SourceSafe, TFVC supports large distributed development teams and projects.

TFVC introduces a new concept called a changeset. With other version control products, the individual files you work on have no linkage or context. They are just separate files checked in at the same time. Hopefully, your comments are enough to glue them together, giving them context and fidelity. In TFVC, changesets describe a group of associated file modifications. This allows for better accounting and workflow, as well as simplified administration. Internally, each changeset is given a unique identifier for tracking and reporting.

As a developer works on the files under version control, the changes are made to a local workspace. Later, he or she can check them in, specifying any required documentation and associating the changeset with one or more work items, such as a task or bug.

NOTE
The internal team at Microsoft responsible for building Team Foundation Server is located in North Carolina. Microsoft has a rather substantial campus there and has been “dogfooding” (using) this same version control throughout the development of Team System. They have been synchronizing builds with the team members on the Redmond, Washington campus.

If you have both Visual SourceSafe and TFVC installed, you can switch back and forth by selecting a different plug-in. This way, you can continue to support any Visual SourceSafe projects, as well as any new development efforts under the Team System Version Control (see Figure 2-4). Remember also that Microsoft includes a migration tool to move your Visual SourceSafe artifacts over to TFVC. Microsoft, or other partners, may release similar migration tools down the road.

Figure 2-4 Choosing your version control plug-in inside Visual Studio

You'll learn more about the version control integration in Chapter 6, which covers the Visual Studio 2005 Team Edition for Software Developers.

TIP
There is also a command-line utility (tf.exe) for interaction with TFVC. This utility allows you to interact from any environment, not just Visual Studio 2005.

How does version control work in environments involving many development shops or teams in different sites? What if they are working over slow connections? In the past, this would be a nightmare of virtual private network (VPN) connections. With TFVC, the solution is to have all the sites connect to the same application tier. Remember that the application tier is just an XML Web service. The integrated tools inside Visual Studio 2005 will natively interact with these Web services.

I'll provide an overview of the TFVC capabilities for branching, merging, and shelving, which are really its unique features.

Branching

Branching in TFVC is similar to copying items from one project to another; however, it is done intelligently. The origin, context, and history of the copied items are maintained so that future changes can be merged back into the original path. This capability is important to software configuration management because it allows multiple builds and releases to be maintained efficiently. These branches are easy to visualize and navigate in the Visual Studio Source Control Explorer. This tool enables a developer to work simultaneously on many branches of the same code, as is sometimes necessary.

Branching can be performed by date, label, or version. You can branch from an existing project in the Source Control Explorer (as shown in Figure 2-5) or when you begin a new team project (as shown in Figure 2-6). All changes that you make to the newly branched code are done locally, in your local workspace, until you check in the changes to the TFSC. The advantage of this process is that you can make any necessary changes, build the code, and test it to make sure it works properly before checking it back in as a new branch.

Figure 2-5 Creating a new branch from Source Control Explorer

NOTE
The Source Control Explorer allows you to move and rename items from one team project to another. This explorer will be available only in Visual Studio 2005. Microsoft is planning to release a Microsoft Source Code Control Interface (MSSCCI) plug-in as a download sometime after Visual Studio 2005 launches. This will enable basic version control integration between TFVC and previous versions of Visual Studio.

Figure 2-6 Creating a new version control branch at project creation

Another benefit of branching is that of storage space efficiency. TFVC minimizes the required storage by only maintaining one copy of content, regardless of how many source files contain it. This is similar to how Exchange Server keeps only one large attachment even though it's being sent to many people. For example, in TFVC, only one copy of a 3 MB file will be saved, even when there are 10 copies of the file in various projects and branches. For this reason, new branches consume very little space. As the developers start making changes to particular files, the additional storage will be used for those changes. TFVC stores only the differences, or deltas from the original files, which is very efficient.

Security can be configured on these branches just as you would set permissions on any directory folder in Microsoft Windows. Remember that branches are essentially paths, so you can use the same access control list (ACL) security model that you are used to. Just right-click on a branched folder, choose Properties, and set permissions.

Merging

Merging is at the core of TFVC's high level of efficiency. This intelligent process reconciles all the changes you've made in your branched code (“the source”) with its original code (“the target”). This is why TFVC remembers the origin and relationships when branching. Merging is more than just blending text. It's almost transactional in nature, because it will merge additions, deletions, un-deletions, and renames from the source to the target environment.

Team System projects can be configured for multiple checkout. This feature allows more than one user to edit the same file simultaneously. The same engine that merges changes between branched projects can also merge changes from two or more checked-out projects back to the source. This feature is not enabled by default.

NOTE
In the case that both the source and target code were changed during a session, the merge will result in a conflict. TFVC will communicate this message to the developer, providing guidance and options on how to resolve the conflict. For straightforward conflicts, you can simply choose whether the source or target should take precedence. For more complex conflict resolution, you can use the included graphical three-way merge tool. This tool is the same as the one you may have used in the past with Visual SourceSafe.

You can choose which changes you want to merge. For example, you can merge the code that fixed a single bug without merging anything else that you were working on. After merging, TFVC updates the merge history for the items. This information is tracked automatically and can be viewed from inside Visual Studio or accessed from the command-line utility.

From the developer's point of view, it's a simple process. Microsoft includes a Merge Wizard in Visual Studio 2005, which leads the user through the process, allowing him or her to choose what changes to merge. The possible answers in the wizard are constrained to keep mistakes to a minimum. For example, if you've branched a particular project twice, only those other two projects would be listed as possible targets for the merge.

Shelving

Shelving is another new, key concept to TFVC. Shelving allows a developer to store pending changes to the server without checking them in. TFVC introduces the concept of a shelveset, which is similar to a changeset except that it's used to store shelved files in a personal space on the server. You can upload pending changes, comments, and associated work items to this personal space for whatever reason. This is not to suggest that developers should start keeping their source code and project files in their own personal area away from other team members. That goes against why we are using version control in the first place. Figure 2-7 shows the shelving feature from inside Visual Studio.

There are many reasons that you might want to shelve your code, including the following ones:

• You need to switch to a different project to perform work with higher priority.

• Your code fails a check-in policy, and you can't fix it immediately.

• Your code is not complete enough to share with others.

• You need to leave suddenly, and you want to upload your work to the server for safekeeping.

Figure 2-7 Shelving code from Visual Studio

Each user can have as many shelvesets as desired. Other users are able to see what shelvesets are available, but they can't access them unless permission is explicitly granted.

NOTE
Shelving is a great feature, but it can be abused. It's intended for unforeseen interruptions during a development session. As a best practice, however, all contributors to a project should check in their files and documentation normally to the shared folders only after all check-in policies are satisfied.

Work Item Integration

From a management standpoint, one of the coolest features is the ability to associate a work item with your check-in. This capability will enable others to see why code was changed. Ideally, they'll always see a code change linked back to a requirement or bug. This type of managerial oversight is important in any project in which developers shouldn't be able to add features or make unnecessary changes.

Check-In Policies

Even though a project manager or team lead might tell his or her developers, “You can't check in your code until you perform a clean build” or “Don't even think of uploading code that fails its unit tests,” these are just words, and words can be ignored. With Team System, policies can be created and enabled inside Visual Studio 2005 that will enforce the two example conditions I just cited, as well as others. Figure 2-8 shows the various check-in policy types.

Figure 2-8 Team System check-in policies

• Clean Build

  The project must compile without errors before check-in.

• Static Analysis

  A static analysis test must be run before checkin.

• Testing Policy

  Check-in tests, such as unit tests, must be run before checkin.

• Work Items

  One or more work items must be associated with the checkin.

Team System projects can also be configured to track additional notes at check-in. Figure 2-9 shows some standard notes associated with the MSF Agile methodology as well as how easy it is to create a new required note. The project administrator can create new notes and set any note to be required. This becomes another type of check-in policy.

Figure 2-9 Creating a new check-in note

If a developer needs to override a policy, he or she could shelve the changes instead, or override the policy. Figure 2-10 shows the flexibility in Team System to allow for a policy override. This might be required in an emergency situation where a fix is required at 2 A.M., for example, and there may be need to check in code that hasn't been fully reviewed.

NOTE
The fact that a check-in policy has been overridden is made known to the administrator, so a developer can't simply ignore checkin policies with impunity.

Figure 2-10 Overriding a check-in policy

TFVC and Sarbanes-Oxley Requirements

If your shop needs to comply with the Sarbanes-Oxley (SOX) Requirements, then you'll need to have tight controls over your source code and related configuration management. Security permissions are a good start, but they are not enough. You also need to have tight auditing in place—that is, you'll need to track which developers are assembling which parts of the application and when. Implementing these types of controls is different from how most shops perform their normal day-to-day routine, but we are developing software under different circumstances now than we did ten years ago.

One of Team Foundation Server's answers to SOX is to manage promotion levels by using branches. Successive levels of promotion are handled in different branches of a project's source code. Developers will typically do their work in the branch that corresponds with the lowest promotion level. Changes then get merged to higher levels of promotion when they are ready. Remember that TFVC branches by using a path-space method, so it can use standard file system ACLs to manage access rights. This ability allows a manager or lead developer to lock down each branch so that only authorized users are allowed to check in code.

To help your project achieve SOX compliance, Microsoft suggests creating at least two promotion levels:

• A developer branch for the day-to-day work

• An approved branch where approved changes are merged

The manager or lead developer would lock down the approved branch so that only authorized users could perform check-ins. TFVC provides native audit trail support of who changed what, which allows you to prove that only authorized people have been making changes in that branch.

What Happened to Visual SourceSafe?

I've been asked and answered that question many times recently. Most developers are aware of the limitations of Visual SourceSafe. Many of you have probably hit the same walls I have when using it: scalability limitations, remote operation limitations, and (occasionally) corruption of data. But love it or hate it, we have to agree that it's the easiest version control tool out there.

Rest assured, Visual SourceSafe is alive and well. Although it's not being built by the same group as Team System, Microsoft continues to research and develop Visual SourceSafe. There's a new release of Visual SourceSafe to accompany certain Visual Studio 2005 editions. It contains a big feature that is shared with Team Foundation Version Control: HTTP access through Web service interfaces.

Some other features we'll see in Visual SourceSafe 2005 include the following:

• A copy-modify-merge model, to reduce lock contention

• A local area network (LAN) performance booster, to use remote procedure calls (RPC) to increase performance

• Asynchronous file opening, so that you can start working before loading is completed

• Better support for projects with developers in multiple time zones

• Better support for multiple languages and Unicode

Remember that Visual SourceSafe 2005 is intended for use by smaller teams, with perhaps no more than five users, and it's intended to be used for version control only. It doesn't have deep SCM support. For any medium-to-large teams (from 5 to 500 users), Team Foundation's version control is optimized for the job.

Build and Release Management

The term build refers to the compilation of all the files, libraries, or components into a new set of executables, libraries, or components. Team System's build management provides an easy, end-to-end solution to produce daily builds, with complete testing and automation. It will pull all the related project files out of Team Foundation Version Control.

Pressing F5 or using the Build menu option inside Visual Studio 2005 works great for smaller applications, where you have local access to all the source-code files and don't have any additional requirements. Larger projects tend to have many other tasks bundled with the actual compile process. Build automation allows for the following additional pre-build and post-build requirements:

• Check out version controlled files for the build

• Run static analysis, unit tests, or both

• Compile sources

• Save code churn, test, code coverage, and other build information

• Drop the binaries into a predefined location

• Generate reports

The Visual Studio Team System build Automation Tool provides an out-of-the-box solution to meet these requirements. Its wizard helps you create automated build scripts so that you can easily automate these tasks. Reports can then be studied to determine the general health of the project and the velocity of the development effort.

Team Build

The Team Build product uses MSBuild internally, which means that it has the flexibility to accommodate many scenarios. By creating and plugging in MSBuild tasks, you can customize your process and accomplish a number of custom tasks.

NOTE
You will learn more about Team Build in Chapter 6 and more about extending it in Chapter 9.