Organization of work

The process of configuration management for a database is more complex due to the nature of a database and the complexity of delivering database upgrades. It makes the organization of work even more important. Considering the high cost of resolving database merge and especially merging conflicts it makes important to pay close attention to organization of work in order to make the configuration management process more efficient. Here are some recommendations:

  • Make teams of about 5-10 developers that work close to each other and can communicate verbally when having a question or can resolve any doubts that might arise. Good communication with promptly answers is of key importance for complex processes.
  • Divide all aspects of a database development into a set of areas according to the functionality and technical difficulty.
  • Make sure, that there is about 3-4 areas per developer. Assuming 5-10 person teams it divides a database into about 15-40 areas.  Then assign to every developer 3-4 areas of specialization, communicate and make the map of specialization available for the team.
  • Don’t change the assignments too frequently but keep it so the developers can learn and become experts in the assigned areas.
  • Make sure, that every area has at least two assignee: one the primary and another for backup. That will open more possibilities to assign tasks and help resolve issues e.g. when somebody is on vacations.
  • Assign work to developers according to the areas of expertise. When possible avoid assigning new tasks to developers that they are not familiar with unless it is a learning process.
  • Avoid scheduling multiple changes in the same area/component (e.g. package or table) at the same time.  In another words, the global perspective of changes made to the same area should reassemble serial order.
  • On the other hand changes that belong to different areas can and should be coded parallel when possible, that is when the changes aren’t conflicting – speaking in technical terms.
  • Perform merges of changes to other branches as soon as all changes in the given area are coded and verified.  Sure that is risky and would cause much work in case the changes should be recalled. Fortunately that doesn’t happened very frequently. On the other hand, it is more probable, that late merges will expose a project to potential merge conflicts that will cost the team much more work and time.

The consequences

  • It is not recommended, to make multiple changes to the same component simultaneously  in parallel branches by different developers.  The cost of merges might be much higher than the cost of making the changes in serial ordering. And the cost of merges is not specific only to a particular tool or repository (e.g. SVN or GIT) but mostly to the nature of a database. So even if there are two developers who potentially can work simultaneously on two different changes regarding the same area it is better to make the changes serial to save merging costs.
  • Should there be many changes in the same area and some of them should delivered sooner than the rest, make the more urgent changes a separate branch.  Start the work in the branch first and schedule work on the remaining changes in another branch after the urgent changes are coded and verified. This way, the preferred changes will be delivered first.
  • The goal is to avoid merge conflicts so merges become as easy as making copies of the changed components from one branch to another.  Assuming that developers are experts in their dedicated areas they can be trusted to make the merges themselves.  It will save a lot of config manager’s time, that can be used for something else, e.g. for reviewing the consistency of changes.  Again prompt communication is the key aspect here.

An example

The table on the left shows changes waiting to be assigned. Every change is associated with it’s area (by it’s own color). The cost is expressed in units of time. And there is the project that a given change belongs to.

The diagram on the right shows ordering of the changes in time withing each project. First the tasks are assigned to projects and then are globally ordered according to areas of expertise. There is one unit of time dedicated for the merge process (marked as m). The merges are triggered from Project I as shown by dotted lines. The symbol Ø represents idle windows of time, when no work is being performed in a given area.

The bottom line

Merging conflicts is costly, especially within a database project. It is worth to consider how tasks can be scheduled in order to avoid conflicts in a project. Without thinking ahead the costs of merging database changes could raise so high, that it will degraded the overall efficiency of teams working on parallel projects rendering the parallel strategy uneconomical. Experience is teaching that partially parallel projects with changes regarding the same area scheduled serially is much more economical even with some “idle” time. And the available time is not lost as it can be used for other important tasks like trainings.


International Conference, Lima 2012

We would like to extend our sincerely thanks to all speakers, participants and the persons from SCMupport and from Colegio de Ingenieros del Peru who prepared the International Conference in Lima that took place in May 19, 2012.

The picture shows the speakers and some of the people that worked to make it real: from left to right, Elba Manrique (our friend and supporter), Mg.Robert Berlinski (Specialist IT), Dr.Jorge Yrivarren (actual Chief of RENIEC), Mg.Marco Sotelo (BCRP Specialist IT), PMP Mercedes Gavilán (Organizer), Dr. Germain Pinedo (Moderator)

Thank you!

Software Configuration Management before and today

It used to be that cards served to handle code in the old days of computer “dinosaurs”.  And not the type of medium is important here, but the point that programmer delivered it personally hand-to-hand. Later, in time of floppy disks the process haven’t changed much.  One programmer works on one program and then delivers it on a floppy. It was simple to ask and find answers to the questions who and when will deliver a new version of a program. And with only one computer available there wasn’t any separate environment for tests. The process was think-code-test-think again and repeat until the computer calculated it right. Of course the  expectations from computer owners were different too.  Nobody expected to calculate millions of customers’ transactions over one night or served a database for an Internet store with thousands of products and millions of clicks working 24/7.

But the technology and the business expectations changed over time and we need to deal with that. Now the business requires reliable production system to work 24/7 and serve multiple concurrent users. For the reason the business is ready to pay the test team and pay for hardware, licenses, etc. And the business requires complex, heterogeneous systems that no longer can be developed by one programmer.  There are teams developing complex systems and then improving the systems.

The one think that doesn’t change are the questions that business ask: what and when you can give us and how much it will cost? And the business would like to hear that it will be available just the same day and will cost less, the best next to zero.

The expectations place the developers managers in an uncomfortable situation. Some might think, that the solution is to hire different developers who will do the same and more job for less. But it is walking on thin ice. The quality of good work must cost and there is no doubt about it. What usually is possible to improve are the procedures.

Since there is a long way from developers to the production there are many places for improvements. And that is the area where Configuration Management is especially significant today. Configuration Management is not only to control how the changes are coded, tested, fixed and delivered to Production. Good Configuration Management helps  developers to work in teams more efficiency and then smoothly deliver their work through all phases  into production.

The Configuration Management have some important functions today.

The first is to control who is making what change and when the change was committed into code, then control when the change got into tests, when it was tested and then when delivered  to pilot and to production. All this helps to manage the changes and helps business to plan the time for tests and confirm delivery. And should something go wrong, it will give a chance to speak with people working on the change and learn lessen and then improve to avoid problems in the future.

And there is much more today about controlling the changes.  To plan and know that all is according to schedule is not enough.  Controlling means to actually be possible to change what will be delivered to test and then to pilot and production. The world is changing and it is not unusual, that Business might ask to change the priority of changes,  maybe drop one change to make place for another more important. And the Configuration Management should be flexible enough to allow that kind of changes and should be efficient to make it for cost acceptable for the business.

For the flexibility and reasonable costs we need adequate structures and procedures. One path of workflow is not sufficient  to support flexible Configuration Management system. It takes many parallel paths that can be implemented by parallel branches in revision control system. Multiple parallel branches makes it possible to move changes between them when it is required by the business.  And the move operations is not free, it will take time and will cost. But sometimes the business is willing to pay the cost.

Another very important aspect of modern Configuration Management is the team work. Good Configuration Management not only makes it possible but makes it efficient.  Efficient in assigning tasks to developers and then coding, unit-testing and committing changes. But it also must be efficient in resolving conflicts when two developers changed the same file. And it must allow more complicated operations like withdrawing changes or retrofitting changes to other branches.

There are many elements for the Configuration Management process to consider.  And somebody could ask what is the best way to make it working? Well, the one way that is recommended it to apply the trunk and branches structure for revision control system and then carefully follow the procedures…

CMToolBox RC1 Trial

The published the CMToolBox plugin for PL/SQL Developer on April 24, 2012. It is a public and free RC1 Trial version available from

The CMToolBox plugin allows to automatically save objects from database to local SVN branch and intermediates between SVN server and the local SVN directories in order to provide SVN operations: update, commit, browse, diff, status, log and add.


  • Supports multiple branches/databases representing multiple versions and projects.
  • Provides automated option to saves database objects to local SVN directories.
  • Incorporates easy access to commit, update, browse, diff, status log and add functions by TortoiseSVN.
  • Automatically concatenates PACKAGE with PACKAGE BODY and TYPE with TYPE BODY respectively when saving database objects.
  • Optionally reduces diacritic characters to ASCII equivalents for compatibility with UTF-8.
  • Straightforward installation, configuration and easy to use pop-up menu and toolbar icons.

Here is a demo from YouTube:


What is the Config Manager function?

Config Manager or if you prefer Configuration Manager is a key role in the middle of the Configuration Management process. The CM supports all phases of a project, from starting a new branch, through testing, delivery and support for production.

However the functions and responsibilities performed by the CM depend on the current phase of a project, the position of CM remains the same, located between three groups: developers, project management and administrators. CM is somehow like a glue that connects the work of developers, managers and administrators.

The CM’s relations include:

  • Works with managers to deliver application/changes according to the schedule.
  • Provides development environments for developers, resolves code conflicts, merges code, builds and develops applications, and in generally assists and gives developers a head start, so they can focus mainly on code changes.
  • Works with administrators to deliver and deploy applications in tests/pilot/production environment, resolve any unexpected issues, might also communicate unscheduled issues with deploying/starting/stopping applications.

The start

CM prepares workspaces for developers and prepares corresponding branches in version repository. Depending of the environment it is recommended to prepare scripts that will automate the process for developers and will help them to load and build developer’s workspaces from repository branches. It is recommended to keep any configuration files for the workspaces in the corresponding branches.

Once the configuration is ready and is the time to start development, the CM communicates the procedures and technical specification of the new workspace and branch to deve


Developing & tests

When the developers are busy building an application and commit changes to a repository, the CM collects code from the repository and builds the application according to a scheduled set by project manager. Should there be any issues like conflicts or compiling errors, the CM works close with developers to resolve the problems.

After building an application CM sends it to administrator with request for deployment to a specific region according to project manager requests. In some cases the CM might be given a sufficient privileges to deploy an application to a Test region, so the CM can perform limited administration tasks with regards to an application in a test region.

Production delivery

The production delivery is significant for CM not only due to the importance of the production environment. There are also special tasks for CM that are part of the process. Some time before the production delivery the CM communicates with project manager and developers to confirm the final date when the development will finish and then CM closes the development branch used by developers for committing changes. And at the time of production delivery CM merges the development branch to trunk..

Production support

After delivering to production CM keeps track of fixes that project manager approved for production. CM has to build the updated versions, send request for delivery to administrator and keep track of the changes in branches performing retrofit merges to another branches when necessary and merging to trunk.


The function of CM requires a unique combination of professional skills. It should be a person with high professional standards and good culture of work, capable to resolve technical issues but primary thinking ahead to avoid them, familiar with technical aspects of coding and with technical knowledge of server side aspects for delivering application, person with good communication skills, who can work under stress and be patient for repeating technical tasks with high accuracy, person who can pay attention to details.

SCM for Oracle benefits by examples

The software configuration management process worked in a company and proved many benefits in the 2011.

Over 120 patches were build for 5 deliveries. The automatic  processes for building patches and upgrades saved on average between 1-2h for each build. It makes about 180h saved of the config manager time. And besides that, the build process can be driven by an average IT employee, who don’t need to be a configuration management expert. The same is true for administrator’s skills.

Additionally the automatic processes allow to eliminate human errors.  Assuming 5% human error rate out of 120 patches it makes 6 issues that hypothetically will required additional time of the config manager, maybe developers, administrator etc.  It sums up to about 20h and eliminates costly  delays when business would wait for fixing problems.

Simultaneous  work on multiple versions (represented by parallel branches in version repository) allows the manager of the IT team to assign more efficiently tasks to developers avoiding idle times. The developers can share their time to work on a few different changes in different branches – maybe closing support with regards to the current unit tested version and kicking-off the next version. It also gives the team manager more flexibility. It means maybe a few (let’s say 2) days saved for each developer. Assuming a team of 5 developers it makes 80h.

From the business perspective, the automated process of building patches on demand allowed changes to be delivered more frequently and more closely to the business schedule. On the other hand unit tests can be executed simultaneously with regards to different versions. And the IT can address new issues and deliver fixes on timely basis.  It means that more versions can be tested and delivery in one year.  It helped to deliver about 20% more changes and improvements to production for the company in question.  In fact it is a scalable solution that depends on the available resources and the range of up to 50% sounds reasonable.

And least but not last. The process helped to organized work and relations between many employees reducing the stress situations.  It added more understanding and supported positive culture of work.