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
Conclustion:
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.
Sorry for formatting.
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.