Using a version control system to manage RedPrairietm source code

RedPrairie Architecture Overview

RedPrairie provides a sophisticated mechanism that allows the users to make enhancements to the system such that the changes are preserved on upgrades and can take advantage of the software updates and upgrades.  Such an offering is quite unique in the space of such systems.  This open architecture empowers the RedPrairie user community to create enhancements themselves and they often do that because the risk on upgrades is minimal. 

Managing the Customizations

Even though the architecture supports creating the customizations it does not provide a mechanism for managing the customizations.  The “usrint” folder becomes hard to maintain where there is no control over the components.  Often times the only reliable way of moving a change from test to production is to copy everything under the LES folder.

The problem is compounded for the customizations that aredone using data.  This includes customizations like database changes, client side modifications, policy changes, and integrator changes.  While moving the LES folder is relatively easy taking the data from the database becomes messy. 

Oracular Approach

We view the problem as two-fold:

1. Manage the customizations
2. Build packages for the customizations

Manage the customizations

We consider code and critical data such as policies, integrator mappings, and client side configurations in the same set of “customizations”.  Our methodology dictates that same principles should apply to all of these – just because a change is realized through code in a text editor in one case and through integrator explorer in another case should not imply that the customizations are to be managed differently.  Following concepts are central in our methodology:

·         Customizations (code and data) must be controlled through a version control system.

·         Issues that lead to customizations must be controlled through an issue tracking system.

·         Every customization should be made only as a result of a specific issue.

·         Every object (code or data) should be checked in to the version control system such that the revision ties to a specific issue.

This is an industry-accepted approach – we have extended it to the RedPrairie code base in an open manner so that the RedPrairie user community can take advantage of that.

Build packages for the customizations

Once we have put appropriate discipline and procedures in place for managing the customizations it becomes possible to build packages (commonly referred to as rollouts) for the customizations.  Since every affected object is tied to an issue, we can build a package for a set of issues.  This greatly simplifies the overall task of deploying customizations to the various environments.

Oracular Solution

Our approach is based on industry recommended practices and is not unique in principle.  We have adapted  this approach to a solution so that RedPrairie customers can take advantage of the solution without significant investment.  Our solution is made up of the following components:

SVN Version Control System

We have created an SVN repository that can be used by the RedPrairie user community to manage their customizations.  This will empower them to take advantage of these concepts with minimum overhead.  Our version control repository is provided through secure “https” protocol along with appropriate authentication model to secure the investment of our clients.  

Bugzilla Issue Tracking System

We have deployed “bugzilla” – a leading open source issue tracking system for managing the issues.  Just like SVN, this is provided to the users over secure “https” protocol along with an appropriate authentication model that is consistent with the SVN model.  

Integrated Issue Tracking and Version Control

We have created hooks in SVN that tie the individual revisions in the version control system to issues in bugzilla.  This implies that we can look at the affected objects for any issue and similarly we can link to the issue information when viewing the revision log of an object.  Our hooks ensure that every check-in is done against valid issue # so that our data is consistent for creating packages.

The above figure shows affected objects in the repository from bugzilla

The above figure shows  a repository item linking back to an issue in Bugzilla

Create packages

Once the issues are tied to the affected revisions, we are able to create RedPrairie compatible rollouts from this data.  We allow the user to select a set of issue numbers or change-sets so that she can then create a rollout package from that.  When creating the rollouts we save the information about the issues that were added to that package.  We also tag the objects with the rollout name in the version control repository so that we can reproduce the rollout at any time – an essential component for a complete system.

Conclusion

Our solution allows the RedPrairie user community to take advantage of the open architecture so that they can create enhancements or customizations.  By having the objects in a version control repository along with suitable change control it enforces a methodology for the developers without compromising their productivity.  The productivity gain by following this approach is quite significant.  For more information about this solution and pricing please contact Saad Ahmad (saad.ahmad@oracular.com)

Copyright Notice

·          RedPrairie is a registered trademark of RedPrairie (http://www.redprairie.com)

·          Oracular is a registered trademark of Oracular (http://www.oracular.com)

·          This document contains information about the RedPrairie software.  It is assumed that recipient has legal access to the said software.