Nobody who works in the field of Identity Management will deny the value of software development disciplines in this endeavor. Novell's embrace of Eclipse as the platform for Designer and integration with Sub Version (SVN) are examples of the value of these technologies. One that still needs attention, however, is staging.
Staging is the concept of taking a project through various stages between development and production. These can include QA and UAT but depending on the maturity of the project and the methodology of the client, no staging to many stages can been seen.
There have been some discussions of staging within Designer, but they have centered more around using features to copy projects, and add additional objects into the model which can be deployed along with the project.
What's needed is a more sophisticated approach which allows projects to be easily promoted from one stage to another, and to compare stages to each other. Although this might not seem like an appropriate forum for editorializing, in this case it is warranted. The methodology that will be discussed later in this article is intended to approximate how this process should operate, so the following "soapbox" is presented to provide context to the solution discussion.
Having had a brief stint a few years ago as a product manager, I cannot resist the temptation to list out some of the requirements for an ideal staging enhancement to IDM Designer.
First, Designer needs to provide a table, which has as its columns, the names of the stages of the project. Second, Designer should provide the ability to flag any parameter as "staged". This would place this parameter as a row in the staging table. Finally, a project should have a status as to what stage it is in. If the stages defined are Dev, QA and Prod, and the project is set as "Dev", the values in the staged parameters should be placed in the appropriate rows of the Dev column.
Ideally, when you change the stage to QA, for any parameters not filled in within the staging table, it would prompt the user to fill them in with a wizard. Once completed, the project could be moved at will from Dev to QA.
What I would like to see some day would be a right click on a parameter, and in addition to cut/copy/paste is a "stage" toggle, which when turned on would badge the control and add the parameter to the staging table. In addition, a staging view would maintain the relationship between projects representing multiple stages, allowing the projects to compare against one another, to allow a change in dev to easily be updated in the QA stage without stepping on parameters like server names, file paths or IP addresses.
CIS has developed a staging tool which provides some of the above functionality. Alas*, it is not in a conveniently packaged ready-to-eat form. Instead, we have a tool, plus a methodology which provides many of these capabilities.
* - thank you to Geoff Carman, for allowing me to borrow one of his favorite interjections, "Alas".
The Staging Tool
The tool is simply an Excel Spreadsheet with VBA Macros. Essentially, this is an overgrown search and replace tool. The columns of the spreadsheet are named for Designer Projects, and the rows represent parameters. The first column is a descriptive name to help the user remember what the parameter means.
Data in Designer is stored in discrete XML files, a whole lot of them. In my original versions of this tool, we did a simple text search and replace, which found most of the important parameters. However, we had a nagging suspicion that some important parameters might lie within B64 encoded CDATA sections; therefore when we updated the tool to version 2.0 we changed the approach to import the XML as a DOM and traverse through the tree that way, decoding and modifying any CDATA sections if they are decodable B64. So far it is unclear whether that will help us find more data to convert but we are still testing.
Using the tool
The approach make certain assumptions which can be challenging to adhere to. Since we are doing this via a global search and replace, parameter values, including the project name, need to be unique and distinct. This means that you cannot name one project ACME and the next one ACME-QA, you must make the first project ACME-DEV and the next ACME-QA so that there are no problems performing the search and replace.
Second, there cannot be ambiguity between stages. For example, you can't put your driver set on one server in DEV but on three servers in QA, as we cant translate SRVDEV1 to SRVQA1 and SRVQA2 and SRVQA3 (although the reverse may be possible). So what we recommend is to use the multiple instance capabilities of eDirectory to create multiple servers even if they are hosted on the same platform server, so that the footprint from DEV to QA to Production is identical.
Setting Up
The first step is to identify the names of the projects in Designer which represents the different stages. For our example, the initial project is called "ACME-DEV". We want to now create a new stage called "ACME-QA". In the staging tool, we will create an ACME-DEV and ACME-QA column.
Running the Staging Tool
Important: Designer should NOT be running while using this tool.
Your first task will be to create a new project which represents the new stage for deployment.
It is up to the implementor to identify what parameters need to differ between stages; generally I find these include server names, IP addresses, and file paths. Since this is a search and replace tool it will apply multiple changes so you can separate, for example, the base path for trace files. That way in the lab you can put traces in /var/log/SRVDEV1 but in production they might go to a log server at /mnt/idmlogs/SRVQA1. You might maintain separate parameters for the root of the path and the server name (in fact you MUST do this).
You then will fill in the same parameters for the elements of the project in the new stage.
At this point, enabling macros will cause the macros on the sheet to run.
You will be presented a dialog.
Pressing the ellipsis button will allow you to browse to your Designer workspace. The drop-down boxes represent the first row of the spreadsheet where the project name is listed. It should be noted that the project name itself is inside some of the files and therefore the name needs to match exactly (case sensitive) the name of the project.
Once you click the OK button, the macro will make a copy of the ACME-DEV project to a new project named ACME-QA. It will change the parameters of as specified in the spreadsheet. This project will not be integrated into Designer yet, however.
Importing into Designer
Importing the new stage into Designer is simple, go to Project ? Import Project ? File System…
Select from root directory, and browse to the new stage project in your designer workspace.
Remember to UNCHECK "Copy project into the workspace", the project is already there.
Assuming the infrastructure to support it is up and running, you should be able to now deploy the new stage to the new environment. In this example we are deploying to a QA environment. You should be able to proceed as with any other IDM project.
Passwords
Passwords which are saved in the project will carry over to the new stage. However if the passwords are not the same, you will need to manually change the passwords which are stored. Best practice is for the passwords to NOT be the same so this manual step is recommended.
What about Version Control (SVN)
If a project has been checked in to SVN, it would be a problem to create a new version which might conflict with it. Therefore, the macro will strip all the .svn folders from the project when it makes the copy. This will make it a new project not under version control; if you want the new project checked in you will need to do that once you have imported it into Designer.
Unfortunately this part of the solution is more cumbersome, although it is possible. If you make changes to DEV and want to then promote the changes to QA, you can follow this recipe:
It should be noted that both the DEV and QA projects should be in version control, and before and after performing this operation, changes should be checked in, so they can be easily reversed.
In the life cycle of a project, it goes through many stages which bring the project from development to QA to Production. This is often an iterative process and having a tool to facilitate this process is valuable.
Keep in mind that while the process here is convenient and can be reliable, it is also time consuming, so staging is something you do when you are ready, and not frequently. Perhaps if features like this appear integrated into Designer they will be able to be used more readily.
Support
Documentation
Learning Services
Partner Programs