Two-Track Development: Part 1 - Establish a Process

Siebel projects often have lengthy development cycles, and enterprises often find that they need to manage overlapping releases where a development cycle is not complete before work begins on the next effort. Faced with such a requirement, project teams find themselves in the unenviable position of maintaining two Siebel development repositories at once, one for each project.

In the image to the left, you can see two development paths, one for Q1 and one for Q2. The Q1 path has an active development effort, with ongoing test cycles in QA and UAT. The Q2 path does not have a UAT environment, because only the Q1 path will be migrated to production. After the Q1 path deploys, Q2 will become the primary path, including DEV 2, TEST 2, and UAT. A new Q3 path can be created with the DEV 1 and TEST 1 environments.

To allow development to proceed on the Q2 path, the Q2 team must always be working with the latest version of the code from the previous project. The latest changes from the Q1 path must be merged to the Q2 path so that Q2 developers are working with an environment that looks like the one they will ultimately release. In other words, the Q2 repository includes a superset of Q1 and Q2 changes, just as the production repository will after Q2 deploys.

To successfully manage the process, it helps to have a regular merge schedule. At a pre-specified interval, such as once per week, a dedicated team member can discover changes to the DEV 1 environment, mediate conflict resolution between those changes and required configurations in the DEV 2 environment, and propagate those changes into the DEV 2 environment.

Once all changes have been merged into DEV 2, they will follow the normal promotion process to system test and, ultimately UAT and production.

How can this work? Over the next several posts I'll discuss some of the issues involved, along with some technical hints. I'll be relying especially on a process developed by a colleague of mine, Ashutosh Nigam.