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. 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. Test Suite and Demo Environment --- The following describes how to run the Test Suite, which doubles as a demo environment for CBD. 1. Install Oracle Virtual Box or some other virtualization engine, e.g. VMware Fusion for Mac, that is supported by Vagrant. 2. Install Vagrant from vagrantup.com. 3. Get the CBD software by cloning from The Workshop. Following is a Mac/Linux example of how to do this. ``` mkdir -p ~/pub/cbd cd ~/pub/cbd export P4CONFIG=.p4config.local export P4ENVIRO=/dev/null/.p4enviro p4 -u sdp_reader clone -p public.perforce.com:1666 -r perforce_software-cbd_main ``` 4. Then do the rest in one magic command line: ``` cd test vagrant up ``` 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. 5. If you want to do demos, a bit more is in order: ``` vagrant ssh 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: 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.md file (this file, previously README.docx), 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, and had been tested up to P4D 2017.1. Coming Next --- Documentation is needed. 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 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 Dependencies --- Python 3.3+ is required. P4Python 2016.2 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](https://swarm.workshop.perforce.com/projects/perforce-software-cbd)! 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](https://swarm.workshop.perforce.com/projects/perforce-software-cbd/jobs). Or you can get that from the command line: ``` p4 jobs -e "Project=perforce-software-cbd ^Status=closed" ``` * 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.