This is the home of the Component Based Development tool set, CBD.
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.
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 various 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.
The following describes how to run the Test Suite, which doubles as a demo environment for CBD.
Install Oracle Virtual Box or some other virtualization engine, e.g. VMware Fusion for Mac, that is supported by Vagrant.
Install Vagrant from vagrantup.com.
Get the CBD software by cloning from The Workshop. Following is a Mac/Linux example of how to do this.
mkdir -p ~/pub/cbd
p4 -u sdp_reader clone -p public.perforce.com:1666 -r perforce_software-cbd_main
Then do the rest in one magic command line:
That’ll take ~25-30 minutes and generates a lot of output. When done, presto, you’ve got a ready-to-use demo environment, complete with a built-from-the-ground CentOS 7.2 machine, the Server Deployment Package installed with the Helix Installer, complete with the Sample Depot data set, Python, Perl, P4Python, and P4Perl build and made ready, and CBD installed, configured, and tested.
At the end of all the output should be an indication that the test is complete, with an indication of the number of tests passed/failed.
sudo su -
service firewalld stop
Shutting down the firewall on the VM allows you to connect to it with P4V.
The P4PORT will be 172.30.30.31:1666 (helix-01.p4demo.com:1666). That IP is a non-routing IP address, only valid on the local box. When you do the ‘vagrant up’, it appends to the end of your local /etc/hosts file on a Mac, creating a local host alias for the name helix-01.p4demo.com:
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.
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.
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."
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:
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.
There is limited technical documentation for the publicly available CBD System, in the form of a README.md file (this file, previously README.docx), plus comments within the code itself.
An installation guide and other technical documentation are planned.
This version of the CBD System is known to work with 2013.2 and later Perforce servers, and had been tested up to P4D 2017.1.
Documentation is needed. An installation guide will be created.
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 on all platforms that have functional Perforce client software. This sophisticated server-side solution results in greater ease-of-use and platform compatibility for end users.
The server side backend is tested on Linux RHEL/CentOS 6 and 7. It should work on Ubuntu and other Linux variants, too. It was once proven to work on a Windows Helix server, using a particular port of bash for Windows
Python 3.3+ is required. P4Python 2016.2
Please contact Perforce Consulting (mailto:Consulting@Perforce.com) for more information.
All registered Workshop users have open access (but not write) to the CBD, specifically to this path:
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.
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 for CBD Updates by your_name.
Edit, test and submit changes in your branch. Then when you are done, merge your changes back into our mainline, shelving them for review.
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.
p4 jobs -e "Project=perforce-software-cbd ^Status=closed"</code>