An Online Community for Identity & Access Management Professionals

Maintaining and Migrating Between Environments

Quick discussion topic- what are people doing to maintain multiple security environments, and migrate changes between them? This seems to be something that's very custom from one organization to another, and we've yet to see a list of best practices emerge aside from the obvious (BACK UP EVERYTHING!). Are people using certain tools to handle diffs & migrations? Custom scripts? Please chime in with any info you can provide, and perhaps we can build a repository of tips and potential tools.

Tags: best, deployments, migrations, practices

▶ Reply to This

Replies to This Discussion

Permalink Reply by Daniel Jaffa on February 4, 2010 at 11:24am

I am very interested in this topic as we currently do not have a procedure to move changes from different environments. We are currently recreating each change in each environment in out stack but would like to script the changes.

▶ Reply

Permalink Reply by Andrew Reid on February 22, 2010 at 10:03pm

Interesting topic

Currently we are using the API to manage all changes. We setup our 'siteminder config xml' for an application, which contains all of the elements required for our configuration app to be able to setup the application in our lowest test environment.

Basic logic for how the config app builds the application realms/rules/policies/membership/responses based on our standards is as follows:
The config app checks CVS to see if a previous XML for that app has been checked in - if so, it checks it out of CVS and deletes all of the realms/rules/policies/membership/responses, if one does not exist it moves on and creates all of the realms/rules/policies/membership/responses as they are defined in the XML that the user submitted. When that is complete, it checks in the now latest version of the config XML.

When migrating through the rest of the states, there is an approval process that the config app enforces. The testing authorities for the state approve the migration of the configuration out of their test state (the approve the CVS version number) into the next one. Then the owner of the subsequent test state approves in the migration. The tool then checks out the approved version of the XML, and moves it forward.

The config tool is tied to a db to manage the versions of all the various configs in each state, as well as the approvals and migrations for some basic auditing.

Not fool proof, but is working fairly well for us right now in a somewhat controlled fashion.

I too would be interested to see how others deal with this, as there does not seem to be a perfect way to migrate between environments