Can someone help with best practice managing customer application configurations (not environment configs)?

Glenn Batson's picture
Glenn Batson asked on December 23, 2013 - 4:07pm | Replies (2).

Question title may not be specific enough and I feel like I could right a book but I'll try to keep it concise.


Configuration example Freight configurations (3 tables)


First process attempt:


Resource took BA configuration Word document that came out of system study


Resource wrote SQL and XML patches and checked them into source control


Above step was initial configuration of the customer's application data


Patches were packaged up into Release Package with source and schema changes and were installed by install utility


Over time developer adds configurations as features were implemented.  These were also SQL and XML patches checked into source control


Over time QA adds configurations as features were implemented or new application configurations were discovered


Problem is what happens when the application is installed in UAT and the client uses the UI to make application configurations (Note: client cannot be expected to track their own changes and

sometimes they are comprehensive enough such as menu reconfigurations they don't want to do by hand to promote to PRD)


Second process attempt:


Instead of creating SQL and XML patches a Config tool was established.  Required application to be installed and running.


Resource took BA configuration Word document that came out of system study


Resource installed the app and manually made configurations through application UI (some configs don't have UI interface and those were done manually in the DB)


Developer uses the configuration file resource put together to get his development going


Over time developer documents configurations and doesn't patch them.  Developer and QA manually applies configurations with feature changes.


Over time QA adds configurations as features were implemented or new application configurations were discovered.  This configuration file was used to promote.


Client gets in UAT environment and makes configuration changes via the UI.  Just need to recreate the configuration file


Problem is the configuration xml file (just more than freight, it was just an example) is hard to compare between environments to figure out the differences.  Not sorted and displayed well 

for text XML comparison tools.  Configuration handles adding but no deleting.  Configuration tool requires app to be up and running.  Configuration doesn't account for configurations that

were in place for only testing and don't want those to be promoted to PRD.


Third process attempt:


Sort of did second process but then went to just completely manually updating and tracking changes via UI, saving off Configuration as a backup.  Problem is very manual and error

proned missed settings





Looking for process of how to handle this sort of thing through ALM and CM, considering the challenges mentioned above.  Can fix the configuraiton tool to present data for better XML

comparision tool.  Can make configuration tool run as a utility outside of the app running.  can use something like Redgate SQL Data Compare (but must setup views, note keys can be different

between promotion environments).  What should be done process-wise to manage and track "real/wanted" configuration changes.


Hope this is making sense.


Bob and David,

Looks like I missed the mark with my question/explanation.  Bob, I can model the process we have today but that process (by expereince) has issues and was hoping I could be pointed to somewhere that has model of what someone is doing to more effectively manage customer changes (specifically application and not environment configurations).  I guess I see tools like Release Management for VS2013 (InCycle's InRelease) which to me speak to promitions of the application files and environment setups.  So I'm wondering what sort of things are there for managing the application configurations.  Now maybe that is very specific to the application itself but that is why I tried describing ours and how we dealt with them.

David, changes occur over the life of the project.  Initially our BA group does a good job of getting the initial configurations defined so we can get those in early.  But a lot of times the projects occur in stages and many interations within those stages.  As those occur the client gets a better understanding of our application and change the application configurations.

After mulling over it I think I'll focus on he following:

1) Goal is not speeding up the process but obtaining and maintaing clarity of the configurations being promoted.

2) Take the initial BA document and make it more of a living document that defines all the approved configurations. Make this visible to the client.  Currently has only been internally.

3) Going back with scripting the configurations so that when promoting to PRD it will be simple for IT to role it out.   Plus among all environments there is less human error.

4) Going with Redgate data compare and our Config tool compare approach and also take advantage of an application feature where we audit changes.  We'll just work our way with these tools and use them as they best fit and hopefully a single tool/approach will eventually shake out. 

5) Work on documenting and disemminating that information on the processes we will follow.  Internally and with the client.  As part of this add in some approval processes for what are the accepted changes (not just emails).

Finally we may also restrict the configurations within the application, so forces us to make all the changes so they get done properly and we can review the changes and make sure they are fully understood.

Thanks you so much for taking the time to respond.  I will continue to look to this site.  If there is anything you see in my update that you want to know more on just let me know.

2 Answers

Bob Aiello's picture
Bob Aiello replied on December 29, 2013 - 12:31am.

Hi Glenn,

I am struggling a bit to understand your question but let's take a shot at it and see if we can narrow down exactly what you are asking for. The ITIL v3 framework does discuss creating a logical model of the deployment that is intended to help all of the stakeholders understand what is required to build, package and deploy changes. These logical diagrams are typically experessed in entity relationship diagrams.

This is usually an iterative processes and intended to help development and operations work out the key details required to make changes quickly and safely (which is the whole point of the DevOps movement).

So I think that you are asking us how to model and understand what is going so that you can come up with a good CM strategy. Do tell more...

Bob Aiello, Technical Editor.


David Day's picture
David Day replied on December 30, 2013 - 11:43am.

Sounds like to me that if the client has to change so many things in UAT for testing, that the original product could be configured more like the end product to begin with. User Acceptance shouldn't require a lot of changes and setup, in my opinion. Configure the app more in line with the production usage and then move the configuration and deploy with the rest of the app and let the client do the minimal "personalizations" on their own. 

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.