Component Based Development (CBD) System

Welcome

This is the home of the Component Based Development tool set, CBD.

Introduction

The CBD System is a tool set for managing CBD in Perforce. The CBD System can be deployed by a Perforce administrator to enhance Component-Based Development workflows at their site. It consists of a set of broker and trigger scripts.

Component based development (CBD) adopts production line techniques for software development. A complex product may be composed of tens or hundreds of component building blocks. Each component may be developed by a specialized team, working on an independent iteration cycle. A product architect defines how the complete product is assembled from specific versions of the necessary components. The CDB process provides some insulation from the vagaries of scheduling such a complex effort, just as a car may be shipped with the latest stable version of a GPS navigation system in order to maintain the overall delivery schedule.

Just as changing manufacturing specifications require close coordination of the production line, the components of a complex software product must be compatible at some interface level. Additionally, in many industries a finished product can be configured in specific ways for particular customers. In the cellular communication industry, a chip set may be tailored for different networks and carriers, resulting in a complex feature matrix.

Key Elements of CBD in Perforce

Component Configuration File

The core idea behind CBD in Perforce is that a regular versioned file that defines the configuration for a component. In simplest terms, this configuration is just a set of paths. One path represents the source code for the component itself. Additional paths with explicit revision specifiers represent other components upon which the current component depends.

This versioned component configuration file is used to define what versions of which files are included in a Perforce workspace for any given component, or for a product (which is simply a collection of components). A configuration change, any change to the dependencies of a component, is represented as a submitted update to the component configuration file.

As a regular versioned file, the component configuration file is subject the same sorts of process that apply to regular source code changes. This can include code review, access controls, notification, and the Merge Down/Copy Up branching process.

Workspace Management

When a configuration change occurs, developer's workspaces are updated accordingly. Typical configuration changes include adding new components, updating versions of consumed components, or removing components.

Magic Sync

In a CBD world, a p4 sync is transformed from meaning "Get me the latest versions of files mapped in my workspace" to "Get me the defined versions of files mapped in my workspace."

If you go back in time to look at older version of your component, you want the system to ensure that 'p4 sync' delivers the correct versions of not only your own component's files, but also of dependencies as they were defined "back then."

History and Future of CBD in Perforce

Perforce has always provided strong version and configuration management capabilities that made it ideal for supporting complex software development processes like CBD. Many customers built CBD solutions around Perforce since the 1990s.

Some of the goals of the CBD reference implmentation were to:

• Capture key aspects of how various Perforce customers addressed the specific needs of the CBD challenge
• Demonstrate how a Perforce broker could be employed to make a more transparent CBD solution that worked as well with the Perforce GUI (P4V) as with the command line.
• Provide a usable implementation.
• Through actual usage, capture better requirements for CBD that could be translated into Perforce product features to better support CBD workflows "out of the box."

Since the reference implementation was presented in 2013 at the Perforce "Merge 2013" user confernece, a productionized version has been deployed for at least one major customer. Others have explored the reference implementation to influence their own custom solutions. Further, the reference implementation has proven a helpful source at capturing requirements that have lead to built-in Perforce features to reduce and eventually eliminate the need for custom scripts, at least for common CBD needs.

Technical Documentation

There is limited technical documentation for the publicly available CBD System, in the form of a README.docx file, plus comments within the code itself.

An installation guide and other technical documentation are planned.

P4D Compatibility

This version of the CBD System is known to work with 2013.2 and later Perforce servers.

Coming Soon

A continuous integration test suite for CBD is being developed and will be deployed.

An installation guide will be created.

Platform Support

Due to the broker-based implementation, which runs only server-side where the Perforce broker and Perforce servers run, CBD supports and any all client interfaces. The trade off here is that a more sophisticated server-side solution results in greater ease-of-use for end users and client programs.

The server side backend is tested on:

• Linux/CentOS 6.4
• Windows 7 (32 and 64 bit).

Initial testing was done for CentOS 6.4 and Windows 7, 64 bit. However, this should work on a wide variety of Linux and Windows platforms.

Dependencies

Python 3.3 is required. P4Python

Contact Us

Please contact Perforce Consulting (mailto:Consulting@Perforce.com) for more information.

Contributing by Shelving

All registered Workshop users have open access (but not write) to the CBD, specifically to this path:

//guest/perforce_software/cbd/main/...

The open access level confers the ability to edit and shelve changes for a pre-commit review process. We'll review the change, and either incorporate it or provide feedback. Be sure to provide a detailed change description, and also include the tag/text "[review]" in your changelist description to initiate a Swarm code review.

Contributing by Branching

Optionally, you may also branch the cbd folder, or some subset of it, into your own guest area. Creating a branch spec is recommended for this purpose, e.g. with a branch spec something like this:

Branch:     your_name-cbd

Owner:      your_name

Description:
    Branch for CBD Updates by your_name.

Options:    unlocked

View:
    //guest/perforce_software/cbd/main/... //guest/your_name/cbd/main/...

Edit, test and submit changes in your branch. Then when you are done, merge your changes back into our mainline, shelving them for review.

Guidelines for CBD Contributors

• Communicate using Swarm! Let folks know what you're planning before you work too hard on something that might already be underway.

• File a job. Name the job CBD-N, where N is the next available job number which you must assign manually. We are working on improving that process. To see the next available job number, add one to the biggest number you see when running:

  p4 jobs -e 'Job=CBD-*'

Then set the Project value to: perforce-software-cbd

Filing a job is not strictly required, but increases the transparency of what you're doing, and helps promote it.

• We prefer changes that are generic, and have a wide appeal.

Guidelines for CBD Contributors

• Communicate using this Swarm page! Follow this project, comment on features, and let folks know what you're planning before you work hard on something that might already be underway. Or take your own crack at it!

• Review the list of non-closed jobs. Or you can get that from the command line:

  <code>p4 jobs -e "Project=perforce-software-cbd ^Status=closed"</code>

• File bugs or feature requests. Use the 'p4 job' command, setting Project=perforce-software-cbd, and also set Type field to Feature or Bug.

• Filing a job is not strictly required for features you want to work on yourself. Doing so increases the transparency of what you're doing, and helps promote it.

• Changes that are generic and have a wide appeal are more likely to get implemented.