Refactoring the VCAP Repo

May 17, 2012 Mark Lucovsky

featured-cf-genericIn my previous post, I talked briefly about the vcap repo refactoring effort. This week, I want to walk you through the process in a little more detail.

If you look closely at the vcap repo, you can see that it’s a collection of major system components (dea, cloud controller, health manager, etc.). This structure is not a scalable structure for the long haul on a number of fronts.

For instance, when building releases we often find ourselves wanting different components at different stages of completion. Within the cf-release repo, we currently have a single sub-module pointer to vcap (src/core). Given the component diversity under vcap, we often find ourselves wanting to be able to manage one launch schedule for each component (e.g., manage the dea and health manager release cycles differently). The singe sub-module pointer approach was too constraining.

Moving forward, we are pulling the major components out of the vcap repo, and into their own repo. In the cf-release repo, under src, we add a new sub-module pointer to point to the new component, adding it to the release. With this structure in place, each major component can publish its own release stream of blessed changes.

The other major change that’s part of this effort is the formalization of shared vcap-common repo and how components formally link to this component.

Walking thru in in more detail in the context of the dea component: The dea repo is the long term location of the dea component’s code and test cases. This component previously lived in the vcap repo as a sub-directory.

The cf-release repo contains a sub-module pointer called “dea”, which links to the new dea repo. See: and note the sub-module pointers for core, dea, etc. Over time, as we complete the repo refactoring work, we will have additional sub-module pointers (for health manager, cloud controller, etc.).

This repo also contains the package definitions for the various components. In the case of the dea, the packaging in cf-release now refers to the new dea repo, and not the dea sub-directory in the old vcap repo.

And finally, with this round of changes, vcap components formally link to vcap-common as a gem and using a git url in their Gemfile. For example, see the below gem reference to vcap_common from the dea’s Gemfile.

gem 'vcap_common', '~> 1.0.8', :git => 'git://', :ref => '9673dced'

The repo refactoring work is moving along and if you have some cycles to help, engage with Jesse on The dea specific change has been a work in progress over the last few weeks. The final piece is to launch on That step is in flight as we speak.

About the Author


Building a Real Time Activity Stream on Cloud Foundry with Node.js, Redis and MongoDB – Part I
Building a Real Time Activity Stream on Cloud Foundry with Node.js, Redis and MongoDB – Part I

Cloud Foundry provides developers with several choices of frameworks, application infrastructure services a...

Introduction to Dart
Introduction to Dart

Dart is more than a new structured web programming language. Google’s Dart Developer Advocate, Seth Ladd, t...

SpringOne 2021

Register Now