December 4, 2015

Single Source of Truth in Component-Based Development


A common theme with Component-Based Development (CBD) is that there must be a single source of truth for all manner of configuration information, including:

  • A list of products to deliver and the list of components from which each product is built
  • A list of active development streams to maintain, e.g. a mainline and two maintenance releases
  • A list of component versions needed for each stream
  • Workspace configurations for developers and official builds

When you consider that any of those items can change at any time, the need for strong configuration management is clear. A new version of a component may require a change in the tool chain if a newer version of a compiler is required. Supporting an old release of a product means seeing the list of components that were previously used, possibly including older compilers or older build systems.

One key to successful CBD implementations is tooling. There are a lot of opportunities for mismatching the various permutations of complex dependencies. In fact, it’s so difficult for a developer to get right that it must be made almost impossible to get wrong. The genius must be in the tooling so that developers can focus on the job at hand.  Helix Streams features go a long way to achieving that simplicity.  And Stay Tuned: 

Features coming soon in Helix 2015.2 will make that task a lot easier.

For a bit longer treatment on this topic, see Building Real-Time Apps via Component-Based Development published in Real-Time Insights.