®
®
W h i t e P a p e r
A u g u s t 2 0 0 7

Parallel and Variant Development Techniques with Borland ® StarTeam ®
Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Parallel and Variant Development – An Essential Management Process . . . . . . . . . . . . . .4
Using Borland ® StarTeam ® to Optimize Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
A Tailored Approach to Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
The First Step to Success: Asking the Right Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
Question 1: Variant Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Keys to Effective Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
StarTeam at Work: A Typical Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
Question 2: Parallel Release Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Keys to Effective Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
StarTeam at Work: A Typical Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
From Common Root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
Cascaded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
From Common Root and Cascaded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
The Advantages and Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
Question 3: Parallel Code Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
Keys to Effective Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
StarTeam at Work: A Typical Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
Change Set by View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
Change Set by Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
The Advantages and Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
Question 4: Conflicted Code Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Keys to Effective Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
StarTeam at Work: A Typical Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
Question 5: Common Code Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Keys to Effective Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
StarTeam at Work: A Typical Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
Combining Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
The Borland Advantage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
2

Parallel and Variant Development Techniques with Borland ® StarTeam ®
Effectively managing change throughout the software development process is critical to efficiently creating high-quality products – so it’s no surprise that it’s a top concern for developers, project managers, configuration managers, and IT directors.
The sheer volume of changes associated with developing a complex application can be overwhelming, making simplistic and serial methods of change management (whereby changes are tackled one after another) too costly and inefficient. Because most development organizations today are structured in a way that allows for more efficient approaches – ones that leverage multiple disciplines and an integrated approach to software development – they don’t need to settle for such outdated approaches.
Parallel development, when done correctly and supported by the right automation and tools, is the most effective way to manage change – especially once code for a new product branches. With a brand new system, there is little or no need for parallel development. The latest version of code is considered the only version of code. It is from only that version that development occurs.
But once code is base-lined and delivered to an environment, the code must be "branched." In other words, as developers continue to write code to create a next generation version, the code used in the delivered environment will also need to be supported. At this point, there is more than one version of code – a one live version and one in development. This branching may continue over time and become increasingly complex, requiring that development teams be broken up into sub-teams focused on specific software versions and functions. They tend to work in isolation relative to others, deploying variants on change requests and more. At times, these branches need to be "merged" to ensure that changes are not omitted or implemented differently in different branches. (As a general rule, a live fix must always be merged into the latest developments or the live issue triggering the fix will reoccur.)
As this discussion illustrates, every software development team supporting multiple versions of software is already engaged in some sort of parallel development process. It just can’t be avoided – though most development teams shy away from the idea of systematizing it because it seems too complex. The question, then, is how efficient and effective is their existing process today?
And how can the right software – implemented in tailored way – enable measurable benefits? An optimized parallel development process can significantly improve quality, time, and cost variables. At the same time, it increases visibility and control, streamlines release content management, tracks changes, accelerates time to market, and helps development teams meet quality and regulatory objectives.
This paper explains how development teams can use Borland ® StarTeam ® , a fully integrated, cost-effective software change and configuration management tool, to address all of their parallel development needs. Because every development organization and business model is different, there’s no one-size-fits-all when it comes to an approach to parallel development. For optimal results, the software needs to be implemented in a tailored way, which requires that organizations think critically about their existing processes, improve areas of weakness, and make informed choices regarding how the software is implemented.
This paper helps those planning on implementing Borland StarTeam – or considering investment in it – by proposing five key questions that will trigger the thinking and decision making required to ensure a successful implementation. The end result is an optimized approach to parallel development that delivers competitive advantage.
3

Parallel and Variant Development Techniques with Borland ® StarTeam ®
Every software development team supporting multiple versions of software is, by necessity, already using some sort of parallel development process. It just can’t be avoided. For example, if a problem is reported in version 1. 2 of a Windows-based application, developers not only need to fix the problem in version 1.2 for Windows, but also version 1.2 for UNIX and versions
1.3 for both Windows and UNIX. These changes – and versions – should be made in parallel.
The question, then, is not if a development team needs a way to approach parallel and variant development, but rather how efficient and effective are they doing it today? And how can they optimize this process for competitive advantage?
But many development teams have deep reservations – and even fear – about applying parallel development methods in any formal way. Implementing supporting software can seem too complicated, and they assume it can only lead to chaos and ultimately slow time to market, reduce quality, and increase development costs.
However, parallel and variant development does not have to be the nightmare that many people envisage. With the proper planning and implementation of people, processes, and technology, parallel and variant development becomes an essential practice that can give organizations significant competitive advantage in today’s software development market. Done correctly, companies can expect to realize the following benefits:
• Reduced cost of software development
• Faster time-to-market
• Improved quality of software deliverables
• Higher responsiveness to change
• Better collaboration across an entire organization
• More accurate and successful estimates for future development projects
• Improved visibility for project teams and stakeholders on defined business and technical criteria
Using Borland StarTeam to Optimize Processes
To simplify management of parallel and variant development activities, many companies today are investing in comprehensive software change and configuration management (SCCM) software – such as Borland StarTeam – to streamline, automate, and optimize related activities. Borland StarTeam is one of the leading SCCM applications available today that helps companies implement a flexible, tailored approach to parallel and variant development.
Borland StarTeam provides organizations with complete control over and visibility into assets (including code for different versions of software) and the changes affecting them. This fully integrated, cost-effective SCCM tool is designed for both centralized and geographically distributed software development environments. A robust platform for coordinating and managing the entire software delivery process, the software promotes team communication and collaboration through centralized control of project activities and digital assets. In addition, it provides support for integrated requirements management, change and configuration management, project and task management, defect tracking, file versioning, and threaded discussions – functionality that is streamlined through the use of automation, customizable workflows, and dynamic forms.
4

Parallel and Variant Development Techniques with Borland ® StarTeam ®
As there is no one-size-fits-all approach to parallel and variant development, Borland StarTeam can be set up to support any process and approach. But with this flexibility comes some measure of responsibility; development teams should carefully evaluate the effectiveness of their existing processes before the implementation. Processes must be in place that will make parallel development not just manageable, but a way to improve development projects. This is essential to achieving the cost reductions, improved software quality, and accelerated time-to-market that parallel and variant development can provide.
Inefficient processes, as well as uninformed decisions, can result in the kinds of problems that have given parallel and variant development its less-than-favorable reputation, such as the following:
• Incorrect repository structure
• Inability to develop effectively, predictably and repeatedly
• Lack of management visibility and control
• Time and cost consuming overheads
• Quality reduction
• Reduced confidence in the management tool
• Reduced confidence in the development process
• Lack of understanding of roles and responsibilities
• Fragmented and uncoordinated team efforts
In working with its clients, Borland has developed a series of questions to help customers think through the approach to parallel and variant development that’s best for their business. How they answer these questions influences key implementation and configuration choices that are the key to a successful, long-term solution.
• Question 1: Is the organization developing more than one variant of a tool (for example, a Windows, Web, and Linux version)?
• Question 2: Is the organization planning parallel development of releases (for example, release 1 is live, release 2 is in testing, release 3 is in early development, and release 4 is in analysis and design)?
• Question 3: How is the organization going to control two developers making changes to potentially interdependent files in the same development system at the same time?
• Question 4: How is the organization going to control two developers making different changes to the same file at the same time?
• Question 5: How is the organization going to implement shared or common code repositories?
These questions should be answered separately and sequentially, as the issues raised in each build upon the next in subtle but important ways. Responses should then be looked at holistically to determine the best implementation and configuration approach for the business.
The following sections discuss the implications of each question in more detail, help organizations develop answers and make informed choices, and then describe how Borland StarTeam can be implemented to support the needs of any development organization.
5

Parallel and Variant Development Techniques with Borland ® StarTeam ®
Is the organization developing more than one variant of a tool (for example, a Windows version, a Web version, and a Linux version?)
This question explores issues around variant development. Variant development is the method of controlling changes to the basic functions so that change is applied consistently to all variants, where applicable, and where possible, with the minimum amount of effort or re-work.
For example, if we have three variants of a tool, one for Windows, one for Linux and one that is web-based. We require a change to the methods of data extraction for the reports. We want to make the change only once and to incorporate into the other variants, rather than develop the same change three times.
Making the effort three times means three times the expected development cost and time –as well as the potential for three different interpretations of the change. Clearly development organizations want to avoid such complication, cost, and potential sources of error.
Keys to Effective Process Management
To manage this common scenario effectively, organizations need to use a configuration management tool that enables them to:
• Control parallel development from a common source location
• Set access rights appropriate to the variant development stream and the responsible development team
• Enable the merging of source files and configuration content
• Perform a control change impact assessment, which assesses whether the change is common to all variants or applicable to only a certain variant
StarTeam at Work: A Typical Scenario
Consider the following example: developers are working on a base application, but the application is required to:
• Work on different operating systems or environments, such as Windows or Linux
• Operate as both a thick and thin client (for example, as a web-based variant)
• Be released as “lighter versions: with reduced functionality for specific situations, such as role-based variants.
In this case, the base requirements, operations, models and functionality of the tools are common. But the way they are implemented is variable. So the assets need to be managed centrally – yet with potentially diverse activity management regarding how the change is enabled in across the variants.
StarTeam supports this type of variant development by the use of views. In Figure 1, we can see that this StarTeam project has been created with a Root View that contains all of our base functions, models, and operations for the system.
Three variant views have been created for each of the expected variant types. Access rights will be set to allow only appropriate users to make development changes in the appropriate view, with read-only access to the other views.
6

Parallel and Variant Development Techniques with Borland ® StarTeam ®
A CR has been raised for this system that must be put through a workflow. A key workflow step is the impact assessment.
Figure 1: CR Raised in Root View
In Figure 2, we can see that is the CR is deemed to be a change that is required across more than one variant. So the change is applied to the common source in the Root View and then the configuration content merged into those views, or variants, for which the change is applicable. This ensures that the change is applied consistently to all variants and there is a reduction in the amount of development effort.
Screenshot 1: Comparing views in StarTeam
When the merge is made, new files are added to the configuration, redundant files are removed and changed files are merged using a defined merging tool. Note that only ASCII based files can be merged.
7

Parallel and Variant Development Techniques with Borland ® StarTeam ®
Figure 2: Change Content Merged to Appropriate Variants
If, however, the change is deemed to impact only one variant, then the CR is moved to the appropriate variant view where the change can be applied, as seen in Figure 3.
Figure 3: CR Applied to Windows Variant Only
It may be that at some later time, the variant change is deemed as required to all other variants. Rather than re-engineer the change for the other variants, we can apply the same change back into the base functionality, as shown in Figure 4. At the same time as merging the code, it should be noted that the change should also be moved to reflect the view where the change principally resides.
Figure 4: Change Merged into Root View
As seen previously, the change must now be merged from the Root View into all other appropriate variant views, as described previously for Figure 2.
8

Parallel and Variant Development Techniques with Borland ® StarTeam ®
Is the organization planning parallel development of releases (for example, release 1 is live, release 2 is in testing, release 3 is in early development, and release 4 is in analysis and design)?
This question addresses issues related to parallel release development. For example, a project may involve a staged or an iterative release of a project, as is common when there are many agile developments over short periods of time or with Unified Process
(UP) or Waterfall developments over longer periods of time.
With agile developments, there is not as much of an issue with overlapping development between iterations, as the iterations will occur serially. However, for organizations operating a more rigid UP, and especially in a Waterfall approach, there is generally a higher need for overlapping development in order to provide time to market and rapid delivery of developments. In other words, the development organization must manage a continuous stream of development through the application lifecycle.
Keys to Effective Process Management
To manage this common scenario effectively, organizations need to use a configuration management tool that enables them to:
• Control parallel development when using branching and merging code
• Set access rights appropriate to the release development stream and the development team that’s responsible
• Enable the merging of source files and configuration content
• Release changes in order of priority
StarTeam at Work: A Typical Scenario
There are three principal ways in which StarTeam can be configured to support parallel release development. This is through the creation of branched views in three different formats that can be grouped into the following categories:
• From common root
• Cascaded
• From common root and cascaded
Each of these formats is explained below, along with discussion regarding the advantages and disadvantages of each.
The structure of the views in a common root structure is shown in Figure 5. In this, each release is branched from a common root view and so is dependent only upon a common source for code and not upon each other. When a change is raised, it is typically raised in the Root View until a decision is made on which release, or releases, the change is applicable to.
9

Parallel and Variant Development Techniques with Borland ® StarTeam ®
Figure 5: Common Root Structure with CR Raised
When a decision is made on the release into which the change is to be applied, the CR is moved to the respective branched view where the change is to be made.
Figure 6: CR Applied to Respective Release
On completion of the changes to the code, the changes are merged into the common root view location.
Figure 7: Change Applied to Common Root
Further release decisions are then made according to the release schedule to determine which further releases are to be made live after the release in which the change has been applied. The CR then needs to be shared to those respective release views and the code and files merged from the common root as shown in Figure 8 on the next page.
10

Parallel and Variant Development Techniques with Borland ® StarTeam ®
Figure 8: Change Merged into Subsequent Releases
In the cascaded structure, as seen in Figure 9, each release is branched from a parent depending upon the order in which the releases are scheduled. As in the previous structure, CR’s are raised in the Root View until a decision is made on the release to which the change will be applied.
Figure 9: Cascaded Parallel Release Structure with Raised CR
When the scheduling decision has been made, the CR is moved to the respective view and the change applied.
Figure 10: CR Applied to Scheduled Release
11

Parallel and Variant Development Techniques with Borland ® StarTeam ®
Completion of the CR requires the change to be merged into subsequent releases. The order of the releases is determined by the parent-child relationships. That is, all child release views must have the CR shared in and the code and file changes merged, as shown in Figure 11.
Figure 11: Change Merged into Subsequent Releases
This method incorporates both of the previous solutions to mitigate any issues that can arise from either of those architectures.
As can be seen in Figure 12, this architecture uses a Common Root structure for major developments and the Cascaded structure for any patches, maintenance releases or live support fixes to these releases. As with the other structures, any CR’s raised are created in the Root View until a decision on the release is made.
Figure 12: A common Root and Cascaded Structure with New CR
In the example shown, the CR is to be applied to a patched release as shown in Figure 13. The CR is moved then into the patch release view.
Figure 13: CR Applied to Patch Release View
12

Parallel and Variant Development Techniques with Borland ® StarTeam ®
On completion of the change, code and files are merged into the Root View. This view may then be representative of released code.
Figure 14: Released Change Merged into Root View
If the change were to be applied to the principal release view, any change should be applied to all children. For this example, with the change applied to a patch release view, the change should be shared into any subsequent release and the code and files merged in, as seen in Figure 15.
Figure 15: Change Merged into Subsequent Planned Releases
The table shown below in Figure 16, shows how each of the three options provides both advantages and disadvantages in supporting parallel release development.
This shows how the Common Root strategy is has inherent problems in Release Management overheads, requiring significant effort to monitor the order and dependencies on releases. This strategy can be troublesome unless there is either significant effort in this area or the amount of parallel change occurring is low. This structure works well with more Agile development methods.
The Cascaded strategy is far more rigid in defining the order of the releases, meaning little maintenance to release schedules.
However, this can lead to issues if there are any delays in the implementation of a release and potentially huge effort in rolling back changes. This structure is typically used in Waterfall or UP based approaches.
13

Parallel and Variant Development Techniques with Borland ® StarTeam ®
Screenshot 2: Merging Views in StarTeam
The combination method is usually considered a much better practice, requiring some Release Management maintenance and merging discipline, without significantly advanced knowledge or administration required. This solution works well independent of the development methods used.
Option
1 Common Root
2 Cascaded
3 Common & Cascaded
Advantages
• Root View used for Promotion
States
• No date dependency of releases
• Release dependency hard to follow
• Change Administration more difficult
Disadvantages
• View merging less frequent
• Easier impact assessment
• Release dependencies defined
• Date dependency only in certain conditions
• Structured branching
• Root View used for Promotion
States
•
•
•
Complex view structure
(many branches)
Tied to dates – Release Impact
Some effort required in change dependency
Figure 16: Advantages and Disadvantages of Options
14

Parallel and Variant Development Techniques with Borland ® StarTeam ®
How is the organization going to control two developers making changes to potentially interdependent files in the same development system at the same time?
This question explores issues around parallel code development. For example, Developer A and Developer B each have respective change requests (CRs): CR1 and CR2. Each is working on a current release in development. As each makes a change, how do we ensure the work effort of one developer causes minimal impact on the other developer?
This kind of activity is fundamental to the operation of any IT project where more than one developer is expected to be working on the implementation of a project at the same time. The methods for controlling and managing this increase even more when the project is operating in geographically disparate locations, or with GDD (Geographically Distributed Development).
In the end, parallel code development is really a matter of controlling assets requiring more than one change to be applied and ensuring that the activity is managed in a way that provides the best results respective of time, cost, and quality targets.
The impacts of improper control of parallel code development can be far reaching and cumulative. Companies experience the following inefficiencies and challenges:
• Contradictory code changes
• Rollback of required changes
• Incorrect prioritisation of effort
• Increased development times to incorporate multiple changes
• Unexpected coding results
• Reduced functionality
• Reduced understanding of code functionality
• Quality reduction through improper communication
• Increased multiple rework efforts and cost increases
Keys to Effective Process Management
To manage this common scenario effectively, organizations need to use a configuration management tool that enables them to:
• Control branching in a common source location:
– From release view (Change Set by View)
– In one view (Change Set by Label)
• Define rules or conditions under which changes can be legitimately made
• Lock source files and configuration content
• Control change impact assessment and the prioritisation of changes
• Enable the integration of applied changes through build management practices, or through continuous integration
StarTeam at Work: A Typical Scenario
Using the example stated with 2 developers working on different changes within the same code base, we can show how this can be applied. There are two key methods to consider and the decision on the one to use is heavily influenced by the development methods being practiced.
15

Parallel and Variant Development Techniques with Borland ® StarTeam ®
This method is typically used with UP or waterfall development scenarios, as its level of structure and definition is such that it would be unfeasible for it to be used in an agile environment.
Figure 17, shown below, shows the base point – a common release view – in which changes are to be applied.
Figure 17: Release View for Source Code
When a change request (CR) – in this case CR1 – is raised and scheduled against a release, a respective branched view is created for the change from the release view, as shown in Figure 18. This view is defined as the ‘Change Set’, the location to where the
CR is to be developed exclusively. The content is based upon the release view content.
Within this view, the code can be developed and unit tested in isolation without affecting the content of the release view or being impacted by changes applied by other developers.
Figure 18: Change Request View Created as Change Set
Once the change has been implemented within the exclusive view, tested, and proved to be stable and operational within the release, it is then merged into the release view, the release view source, and file content. From this point, the release view content can be distributed to more formal test regions.
16

Parallel and Variant Development Techniques with Borland ® StarTeam ®
Figure 19: Change Content Merged into Release
Once completed, the Change Set can be removed. This is the basic operation by which any one operator will work. However, further consideration must be given to situations where more than one change is occurring at the same time (in other words, there is more than one change set).
Screenshot 3: Code Comparison and Merging in StarTeam
Figure 20 on the next page, shows a scenario where three changes are being implemented at the same time. We shall simply look at a situation like the example given previously, where two developers are making two changes at the same time, CR 1 and CR 2.
As the changes are raised, the appropriate Change Set views are created. All of these are based upon the release content.
17

Parallel and Variant Development Techniques with Borland ® StarTeam ®
Figure 20: Multiple Change Sets from Single Release
For our example, we shall say that Developer B, working on CR 2, completes development and unit test first. The result is that the CR 2 content is now tested against the release build and is merged into the release view.
Figure 21: CR 2 Content Merged into Release
The Release view, Release 1.0, is now includes the CR 2 change.
If Developer A now completes development and unit testing of CR 1, they are in a position to merge this change into the release view. However, this should not be done, as the content of the release view has changed since the CR 1 change set was created.
This means that the content of the CR 1 change set is now invalid.
The change set containing the CR 1 change does not contain the CR 2 change made by Developer B. The result of this change may impact the work performed by Developer A and the operation of the coded changes. Therefore, the CR 1 change needs now to be retested with the CR 2 change incorporated, as this forms part of the release view source code.
18

Parallel and Variant Development Techniques with Borland ® StarTeam ®
Figure 22: Source from Two Different Changes Can Destabilize the Release View
Instead, once the CR 2 change has been closed and merged into the release view, all other parties involved in change sets and the implementation of changes need to be informed that the CR has been merged into the release. Developer A now has the option at any time to merge the CR 2 changes into the CR 1 change set from the release view to bring the change set up to date. This will allow Developer A to still develop and test the change in isolation.
Figure 23: CR 2 Change Merged into CR 1 Change Set View
Once the change has been developed and tested, it can then be merged up into the release view, as shown in Figure 24.
Figure 24: CR 1 Change Merged into Release View
19

Parallel and Variant Development Techniques with Borland ® StarTeam ®
It should be apparent at this point that several critical factors need to be implemented and considered in order to manage this process effectively.
First, the priority order of CRs must be very carefully considered. In the example given, if CR 1 was the higher priority change, then it must be allowed to merge into the release view first. The CR 2 change must be prevented from being merged into the release view until all higher priority changes have been merged. Otherwise, it may cause a delay in having a critical change be implemented because of the additional development time required to merge in and retest against lower-order changes.
This can create a problem because the changes can be developed and tested in isolation and in parallel, but the final merging of the changes into the release view for the final build can only occur in a serial fashion.
If not correctly managed, then it’s possible that a high-priority change may never be implemented into a release because a stream of lower priority changes are being implemented and need to be merged in. Effectively, development and testing on the high-priority change never stops due to continuous merging requirements.
However, this practice does ensure that any developer working on a change cannot have their development corrupted accidentally by another developer’s change.
Change Set by Label
This method is typically used for Agile development practices, but can be easily adapted in a more structured and defined approach. Rather than making use of multiple views, this process makes use of the label functions in StarTeam, specifically
Revision and View Labels, what are defined as follows:
• Revision Labels identify the specific configuration items created or modified by a change (such as a Change Set)
• View Labels identify the complete stable configuration of the system, identified as creating a quality build that can be released as a new iteration.
Figure 25 below shows 15 files within a single StarTeam view that represent a configuration of a system. All of the files, except one, have multiple versions held in the version control repository. The versions of the files that can be integrated to provide a stable build of the system are identified by a View Label, shown in the diagram by the yellow surrounding box.
Figure 25: Files in View with ConFigured View Label
For this scenario, we shall use again our example of Developer A working on CR 1 and Developer B working on CR 2.
Developer A commences work first on CR 1. They check out the files by the View Label to establish their working environment with the last stable build known to work – the version against which the change will be made.
20

Parallel and Variant Development Techniques with Borland ® StarTeam ®
Files identified as requiring modification will be locked, the changes made, and then the files checked back in. As the files are checked back in, they are given a Revision Label. In Figure 26, the new versions of the changed files are represented by the red boxes. They are given a Revision Label noted by the green surrounds.
Figure 26: CR 1 Change Made and Revision Label Applied
At this point, it should be noted that the View label does not change from the versions of the files that it is applied to. This means that a stable build can be recreated at any time. The CR 1 change is, at this point, still classed as unstable, as the change has not yet been assured for quality against the build.
The developer can recreate his working environment at any time by checking out by the View Label and then by the Revision
Label.
In Figure 27, we see that Developer B has now commenced changes for CR 2. This has required changes to two existing files and the addition of one new file. These are highlighted in blue.
This change has a second, different revision label to associate the changes with CR 2, as represented by the purple surrounding box. Through this method, neither change is affecting the other developer’s work, the development environments, or the stable build.
Developer A’s working environment will contain the View Label (yellow surround) plus the CR 1 Revision Label (green surround)
Developer B’s working environment will contain the View Label (yellow surround) plus the CR 2 Revision Label (purple surround)
A stable build environment will contain the View Label (yellow surround) only.
21

Parallel and Variant Development Techniques with Borland ® StarTeam ®
Figure 27: CR 2 Change Made and Revision Label Applied
As can be seen in Figure 27, Developer A can continue to make changes to files as he assures the quality of his changes against the build, without interference from other development work.
At some point, the developer, or unit tester, will ensure the quality of the change being applied and be confident that it does not break the build. At this point, the developer will freeze the revision label in question, as shown in Figure 28.
Figure 28: CR 2 Revision Label ‘Frozen’ by Developer B
Then, according to the security rights defined in StarTeam (which supports role-based permissions), the CR 2 change is integrated into the build, (in other words, it is made part of the stable build by applying the view label to all files and versions of those files with the CR 2 revision label, as shown in Figure 29). It is recommended that revision label rights be held by the developer making the change, and view label rights be held by a build management authority.
While this operation is performed, Developer A is continuing with work according to CR 1. Developer A should be informed of the completion of CR 2 through the workflow, and if Process Rules are enabled, see the linked files from the CR (in other words, the files that have changed or been added as a result of CR 2). Developer A should also see a status on these files of ‘Out of Date’ or ‘Missing’ in comparison to the working environment.
Developer A can then choose at an appropriate time to incorporate this change into the work effort by recreating the working environment as noted previously – by checking out the view label and then the appropriate revision label, or by selecting the individual files and checking out the version with the view label attached.
22

Parallel and Variant Development Techniques with Borland ® StarTeam ®
Figure 29: CR 2 Change Incorporated into Stable Build
Once Developer A has assured the quality of the CR 1 change against the stable build, the same process can be performed by freezing the CR 1 revision label, as shown in Figure 30.
Figure 30: CR 1 Revision Label Is Frozen
The View label for the affected files is then moved to the version of the file with the respective revision label.
Figure 31: CR 1 Incorporated into the Stable Build
Once all scheduled changes for the iteration have been made to the build, the build itself can be frozen to prevent any further changes being applied to the stable configuration. This configuration can then be released to more formal testing areas.
23

Parallel and Variant Development Techniques with Borland ® StarTeam ®
Figure 32: Stable Build Frozen for Release
A new view label should immediately be generated for the next iteration based upon the frozen label, thus allowing the next iteration of development to commence. As shown in Figure 33, this then allows further changes to be made and either iteration to be retrieved as a known working configuration.
Figure 33: Previous Frozen, Released Configuration and the Next Development Iteration
The table shown below in Figure 34 shows how each of the change set options provides both advantages and disadvantages in supporting parallel code development.
The method of generating change sets by View has many advantages when it comes to ensuring control and reporting on development progress by CR, However, this control can become restrictive, particularly when team members need to develop changes and iterations rapidly. For large-scale projects where time constraints are minimal, but quality issues are paramount, this method is extremely effective. It should, however, only be only used in a UP or waterfall environment. It can also lead to huge amounts of overhead in administration of the configuration management system, in particular, the creation of views and appropriate access rights. Administration of the actual changes also becomes more difficult, as CCBs (Change Control Boards) must make the right decisions regarding change priorities, and effort estimation must be comprehensive.
Generating change sets by Label is far more effective when changes must be made quickly and effectively. None of the quality assurance on the code is compromised, however, as process management and control is delegated more to the users and is less in the control of the tool. However, this flexibility means that there is much less administration of views, less merging required, easier change administration, and less complexity for the user to manage.
It is strongly recommended, however, that before starting operations in this environment, that roles and responsibilities be clearly defined, access rights be set up accordingly, and development methodologies and proper workflows already be implemented.
24

Parallel and Variant Development Techniques with Borland ® StarTeam ®
1 By View
2 By Label
Option
•
•
•
Distinct development locations isolated by Access Rights
Isolated Unit Test region
Easy view/reporting of file changes by CR
Advantages Disadvantages
• Change Impact assessment difficult against release
• Change Administration extremely difficult with cross change impact assessment
• Large amount of view merging required
• Large amount of View administrations required
• View merging less frequent
• Easier impact assessment
• Simple cross change impact assessment
• One view for all – less administration and complexity
Figure 34: Change Set Options
• Difficult to report file changes by CR
• Requires strong access rights on labels
How is the organization going to control two developers making different changes to the same file at the same time?
This question addresses issues around conflicted code development. Using an example similar to the one used in question three, we can assume that Developer A and Developer B each have respective CR’s, CR7 and CR8. Each is working on a current release in development. As each makes a change, but the changes require the same source file to changed. How do we ensure the work effort of one creates minimal impact on the other?
This kind of activity is common to any development work where more than one developer is expected to be working on the implementation of a project at the same time. The need for proper methods for controlling and managing this type of changes increase even more when a project is being worked on in geographically disparate locations, or with GDD (Geographically
Distributed Development).
Success requires effective management of assets and activities for this kind of development. If the controls are not in place, then inefficiencies or issues that can arise, such as:
• Contradictory code changes
• Rollback of required changes
• Incorrect prioritisation of effort
• Increased development times to incorporate multiple changes
• Unexpected coding results
• Reduced functionality
• Reduced understanding of code functionality and incorrect coding
• Quality reduction through improper communication
• Increased multiple rework efforts and cost increases
25

Parallel and Variant Development Techniques with Borland ® StarTeam ®
As this list suggests, the impacts of improper control in a fundamental development approach can be far reaching and cumulative.
Keys to Effective Process Management
To manage this common scenario effectively, organizations need to use a configuration management tool that enables them to:
• Define rules or conditions under which changes can be legitimately made
• Lock source files and configuration content
• Perform control change impact assessments and prioritize changes
StarTeam at Work: A Typical Scenario
In this example, we will assume that Developer A is making changes to the view as a result of CR 7. Work has already commenced, as shown in Figure 35, when a serious issue is raised – CR 8 – that takes precedence because it is a higher priority.
This change requires work to be done on the same source file.
Figure 35: CR 7 Change Applied
The CR 7 change is shown with the blue box, and the red surround denotes an appropriate revision label related to the change.
As Developer B makes the change for CR 8, they do so against the file that is part of the stable build – specifically, version 1.1 for this example, as shown in Figure 36. This is to ensure that implementation of the high-priority change is not delayed because of a lower priority change (CR 7). Therefore, the CR 7 work performed by Developer A is not yet included in Developer B’s efforts.
Figure 36: CR 8 Change Applied to Same File
The CR 8 change has been checked in, as shown by the red box, with an appropriate revision label attached, as noted by the orange surround.
26

Parallel and Variant Development Techniques with Borland ® StarTeam ®
The change is tested against the stable build, and if it passes, then the revision label is frozen; the view, or build, label is moved to this version; and the CR 8 change is not considered part of the stable build.
Although the change for CR 8 is in a later version of a file, the CR 7 changes themselves are not contained in this version, so they are not part of the stable build (as is required to ensure the quality standard).
Figure 37: CR 8 Change Included into Stable Build
As the CR 8 change is incorporated into the build, work on CR 7 with Developer A continues uninterrupted. Through workflow notification and file status updates, Developer A should be aware that other changes have occurred to this file. The status will appear as ‘Merge’ and when the user attempts to check this file in, he or she will be prompted to merge the file contents.
If the changes are not to be merged, then a ‘forced’ check-in is required. The recommended operation at this point is to not check in the resulting merged file, but rather to keep the merged contents in the working area. This way, the file can be tested with not only the CR 7 change, but also with the merge to CR 8. Any issues resulting from the merge can be corrected.
The file can then be checked in as version 1.4, with the appropriate revision label attached. This file can then be checked in a unit test against the stable build.
Figure 38: CR 7 Changes Merged with CR 8 to Create New Version
With the tests performed, the file can be included as part of the build. The revision label is frozen and the view label is moved to indicate that the file is now part of the stable build.
27

Parallel and Variant Development Techniques with Borland ® StarTeam ®
Figure 39: Merged File as Part of Build
The final build now contains both changes. For the individual file:
• Version 1.1 is the file version prior to CR7 and CR 8
• Version 1.2 contains CR 7 only
• Version 1.3 contains CR 8 only
• Version 1.4 contains both CR 7 and CR 8 and any efforts required to ensure the two changes can be applied without issue.
How is the organization going to implement shared or common code repositories?
This question explores issues around common code development, which occur when organizations want to centralize of libraries and components to provide standardization and support code re-use. The aim is reduce development effort, particularly around areas that are developed multiple times. It is also a method for providing a common interpretation, method, business flow, or
GUI representation to developed software. The ability to re-use assets also helps to reduce time required to model, architect, and test solutions, as well as develop them, and it can result in significant cost savings, improved quality, and faster time-to-market for development projects.
The identification of common code libraries and their controls should be driven by the project requirements. Where two or more systems have the same requirements, then there is a need for a common set of source code and a common code repository. This repository must be very closely controlled to ensure that it does not develop into bespoke systems unnecessarily, as this limits the commonality and re-use of the assets.
Keys to Effective Process Management
To manage this common scenario effectively, organizations need to use a configuration management tool that enables them to:
• Define rules or conditions under which changes can be legitimately made
• Lock source files and configuration content
• Perform control change impact assessments
• Create common repository locations with appropriate access rights
• Implement change control workflow controls
28

Parallel and Variant Development Techniques with Borland ® StarTeam ®
StarTeam at Work: A Typical Scenario
The key to ensuring the integrity of common code libraries is to treat the code as an individual project or development effort.
The resources allocated to make the changes will be from multiple development teams that in many cases, are geographically dispersed.
Changes that are raised that impact common code should be studied carefully for their impact. If the statement of the change covers both common and bespoke code, it should be separated in some manner, either by creating new CRs as “children” or through task management. Our example assumes the creation of CRs specific to either common or bespoke code.
Figure 40: Common Code Library Architecture
When a CR is raised against common code, it should be held in the common code project. Changes made should then follow standard process rules to provide descriptive work justification, file locking to protect for parallel code development, and change request workflow to ensure that notifications are sent to responsible owners. Throughout this processes, StarTeam automatically creates audit trails.
As with any other project, as the changes are applied, they should be applied according to a release. This means that releases of common code, when needed to support bespoke development, should also be planned as part of the release management strategy. This will mean the creation of parallel release views, as described for question two, within the common code repository.
When development in a release view is complete, or a stable build has been generated from a View/build label, the label should be frozen and a ‘Read-only’ snapshot view should be created based upon the label. This view, containing a stable and tested quality baseline of the common code, can be then shared from the common code library project into the bespoke development project, as shown in Figure 40. This makes the common code available for the project team to use when creating releases of the bespoke development.
These common code releases, or read-only views, can then be re-used to accelerate the development of other projects.
29

Parallel and Variant Development Techniques with Borland ® StarTeam ®
After working through the previous five questions, development organizations then need to look holistically at their answers, address dependencies, and make informed decisions about how to tailor the deployment of Borland StarTeam for their business. The example configurations discussed previously not are mutually exclusive. Rather, they must be considered in various combinations to understand exactly how the five chosen methods will work together.
For example, consider the importance of looking at answers to questions one and two together.
• Question 1: Is the organization developing more than one variant of a tool (for example, a Windows, Web, and Linux version)?
• Question 2: Is the organization planning parallel development of releases (for example, release 1 is live, release 2 is in testing, release 3 is in early development, and release 4 is in analysis and design)?
The larger question generated from a combined view is, will the organization be developing releases of variants, or variants of releases? The difference between the two, apart from the different structures it creates in StarTeam (as shown in Figures 41 and
42) defines the release strategy (for example, when developments are to be released, are they to be released as variants of a product, or as a single product with multiple variants, and so on).
For the example shown in Figure 41, we have three variants, and each of the variants will have their own release strategy. So
Release 1.0 of the Windows variant may have a different release date to the Release 1.0 of the Web variant. This can be useful as a release strategy, as it prevents any issues that may occur in one variant from holding back another.
Alternatively, in Figure 42, we have variants of releases. So in this strategy, all variants will have a common release date.
Although this will mean issues in the development one variant will potentially delay the others, it does make the merging of code between variants easier where common code is used. This also potentially keeps in line with the most common release strategy anyway, which is to deploy all variants of a new release at the same time.
Figure 41: Releases of Variants Figure 42: Variants of Releases
30

Parallel and Variant Development Techniques with Borland ® StarTeam ®
This example illustrates the importance of considering questions together, or in combinations. Organizations that run ahead with the deployment of Borland StarTeam without taking the time to both consider these questions and look at them in relation to one another run the risk of unsuccessful deployments.
Parallel development is not a simple practice, but it is both a powerful and unavoidable one. If managed properly, it can be implemented in a way that boosts the turnover capabilities of modelling, development, analysis, and testing teams. At the same time, it can reduce the number of quality issues raised in projects, which enables component re-use and reduces rework effort.
And it can prevent unnecessary actions and allow easier planning and strategizing for the delivery of software.
A key element to ensuring that parallel and variant development does not become onerous, a costly administrative overhead, or cause for quality concerns is to implement a management tool that supports, automates, and streamlines all related change processes in a way that is easily followed and understood by all. In other words, the software should enable and enforce asset and activity management across all projects and teams, regardless of their location.
Borland StarTeam provides a comprehensive package to make parallel and variant development easier and asset and activity management achievable. It does this by providing:
• Process rules to provide work justification
• Change control workflow to provide communication and ownership
• File locking to ensure change prioritisation
• Code sharing between project to provide re-usability
• Role based permissions to control proper actions
• Integrations into merge tools, build utilities, and comparison tools
• Labels to identify configurations (small or large)
• Views to isolate workstreams
Borland is the leading vendor of Open Application Lifecycle Management (ALM) solutions - open to customers' processes, tools and platforms – providing the flexibility to manage, measure and improve the software delivery process.
Copyright © 2007 Borland Software Corporation. Borland and all other brand and product names are service marks, trademarks, or registered trademarks of Borland Software Corporation or its subsidiaries in the United States and other countries. All other marks are properties of their respective owners. 25694 www.borland.com