If you’re running One Identity Manager, releases are often the riskiest part of the platform lifecycle. Manual steps, opaque transport packages, and environment-specific fixes create delays, rework, and audit pressure, especially as Identity and Access Management (IAM) teams adopt DevOps practices.

The problem with traditional OIM release processes

Managing releases in One Identity Manager has traditionally required significant manual effort, UI-driven processes, and careful coordination between environments. As development cycles shortened and DevOps practices became essential, these limitations became a bottleneck.

Deployment Manager was created to remove these bottlenecks and enable modern, pipeline-driven delivery for One Identity Manager.

What changes with Deployment Manager

In re-imagining how data and code is moved from a Development environment to Production, Deployment Manager brings the critical ability to describe in human-readable plain text files the changes which make a release. Each file has a logical purpose and clear sequencing, making releases easier to understand, review, and troubleshoot.

This is in stark contrast to the One Identity Manager method of bundling code and data into an opaque Transport package.

Deployment Manager enables simple automation with a script-free execution of the release pipeline from a single command. Inbuilt state history ensures that only changes to the pipeline are executed, saving time.

Environment specific data or configuration is securely held for reference by pipeline actions as it executes. This ensures the same actions are run on every environment, with relevant values substituted at runtime.

Why this matters in regulated environments

With plain-text files to describe the release, we can immediately leverage version control for our code and data. This brings change management, familiar to traditional developers, into proven and robust systems such as GitHub or Azure DevOps.

Change management with these tools allows for peer review and version history, along with branching and merging strategies to control exactly what goes to Test and Production.

By externalising the code into plain-text, and utilising automation, we can introduce code scanners to the release pipeline. Now we can provide a high confidence of quality for every release and fulfil regulatory requirements, for example systems within FinTech and Healthcare sectors.

Where test automation fits

Along with the actual movement of code and data, another important aspect of CI/CD pipelines is that of test automation. Once a deployment pipeline has run into a Sandbox, Test or Pre-production environment, leveraging test automation reduces the burden of manual regression testing while improving release confidence and overall solution quality.

By extending Deployment Manager’s secure credentials management and database connection with test automation, Intragen’s Test Assist provides a rich, high-level and behavioural-based set of interfaces to accelerate your test automation coding.

Who this is for

If you already use IntraSuite

Deployment Manager may already be part of your platform, but many teams still rely on manual or semi-automated release processes. Fully adopting pipeline-driven deployments unlocks:

• Faster release cycles
• Lower risk
• Stronger audit evidence

If you don’t use IntraSuite

Deployment Manager provides a purpose-built way to modernise One Identity Manager delivery without custom scripting or fragile tooling.

Conclusion

Deployment Manager transforms One Identity Manager releases from manual, high-risk activities into predictable, auditable delivery pipelines. Whether you’re already using IntraSuite or evaluating how to modernise your IAM delivery model, Intragen can help you assess where automation will have the greatest impact.