I suspect that Novell is thinking that Packages may be a way forward to
make staging easier.

I am so far, reasonably happy with using packages to stage right now.

Once you get to IDM4 you can start making your changes by including the
changing policies in a package. You can do this in two ways to move to

Make your package (V0.0.1), add it to your dev driver. It contains
nothing so far.

1) Find the content you wish to modify. Add it to the package. (Right
click in Outline view, it is an option, when the Tree is in Package
Development mode).

2) make a new version (0.0.2 Build a JAR of 0.0.1, and tick the release
2a) Update the package version on your driver to the new build.

3) Modify the content and sync to Package.

4) Build a JAR and release.

Now in Prod, you add the 0.0.1 package this takes 'ownership' of the
policies to be changed. But nothing changes.

Then you upgrade to 0.0.2 which has the changes in that policy and they
just apply.

Now you have delivered the changed content... Need another fix and
change? Ship it over as 0.0.3 build... And so on.

Slowly consume your driver into packages over time.

New drivers, use packages to deliver as well.

I think it can work.

On 5/17/2012 11:16 AM, ChrisReeves wrote:
> I'm currently looking into how we handle staged deployment.
> I've searched the forums and found the following posts where there has
> been some previous discussion regarding how to handle this:
> 'Best way to migrate drivers from lab to production?'
> (http://forums.novell.com/netiq/netiq...roduction.html)
> 'Release process for production environment'
> (http://forums.novell.com/netiq/netiq...vironment.html)
> 'Subversion - version control system'
> (http://forums.novell.com/forums/neti...ol-system.html)
> These suggest that standard practice is to maintain multiple projects
> (one for each environment) backed into subversion, with any changes
> copied and pasted or exported and imported between environments. We do
> things slightly differently here (I'm certainly not suggesting that how
> we do things is better than the standard approach, but it works well for
> us with our fairly linear development process) - I'd like to take a
> minute to explain how we have things set up in the hope of getting some
> suggestions on how to improve what we do.
> At the moment we maintain two environments - development and
> production. The development environment has a single IDM/eDirectory
> server and is linked to the dev/test environments of our various
> connected systems. The production environment consists of multiple IDM
> servers (one live with the others on standby) which share a replicated
> eDirectory tree (the identity vault) and are connected to the production
> environments of our connected systems. We maintain a single Designer
> project, backed into subversion, which we use to develop and store our
> IDM configuration. The configuration stored within subversion is that of
> the development environment, as this is the environment in which we
> spend the most time and in which we make most use of version
> comparisons, etc. The production environment is maintained in a
> separate, dedicated, Designer workspace, with updates checked out of
> subversion only when development and testing has been completed and we
> are ready to move to production. This works well for us at the moment
> because our development is fairly linear - we tend to work on one
> project at a time and release to production before moving on the next
> project - however it does suffer a little on occasions where we are
> required to work on multiple projects in parallel. We try to keep the
> differences between the development and production environments as small
> as possible, with the majority stored in per-server parameters/variables
> such as GCVs (which are less likely to get overwritten during an update
> from subversion). There are some small differences in policy between
> development and production, however these are slowly being eliminated
> and those that must remain (e.g. to ensure emails are sent to test
> addresses) have so far been handled by a conditional statement depending
> upon a GCV which determines the current operational environment. Because
> the production configuration itself is not actually stored in subversion
> (I know that sounds a little backward...) we store no history for the
> production environment, but since the differences are primarily in
> operational data such as connection information and passwords this
> doesn't particularly concern us. The production workspace is backed up
> nightly so we always have a recent copy of the current production
> configuration.
> In looking for ways to improve how we handle staged deployment I had
> wondered whether it would be possible to merge the production workspace
> into the main project by adding the production servers to the project
> and setting the GCVs appropriately (assuming these are the only
> differences between development and production). Unfortunately I don't
> see how this could work because there would be no way to control which
> servers (i.e. which environments) policy changes are deployed to, unless
> I've missed something...? Another thing that I'd considered was creating
> a production branch and synchronising with HEAD when changes are ready
> for production (or vice versa), however Designer doesn't support
> branching and merging natively, and given that performing branching and
> merging at the file level would probably break Designer I don't really
> think this is an option either. So does anyone have any suggestions
> regarding how to improve on what we're currently doing, or know where
> those wonderful folks that gave us Designer are at with regards to
> staging (or if they're even actively working on it at all)?
> It would also be good to hear from anyone who has taken a different
> approach from either the 'standard practice' of
> one-project-per-environment or the approach we've taken above.
> Finally, on a vaguely related note, do people tend to name their
> development and production trees differently, or give them both the same
> name? Is there best practice for this?
> Thanks,
> Chris