When we create a new driver we use base package, and all other customization is done through adding custom policies on the drivers, this gives us the faster way of developing test and verify, easy to export drive configuration files, and making it lightweight, portable, (sharing common code functionality is achieved using policy linking), and we use GIT for versioning of our driver configurations files,
but development using packages experience compared to developing with driver configuration files is much confusion and feels unnecessary many "manual " steps when developing "package" based development using netiq designer. looks like netiq idm package development has influenced by java developers but in java, you have proper build (a compiled code) and release (CI/CD) pipelines processes which automates from "build" to "release" your solution to different environments which I don't see how this model fits within netiq designer and if it has automted CI/CD pipeline process for driver package based development. all the driver package development is done in the form of traditional Dirxml-Scripting "scripting" using a so-called "development" driver and adding its content to package.
so some thoughts:
- When to use the package "build" option? (you have to deploy driver to identity vault before you can completely verify integration tests not just simulating xds documents within the designer simulation will verify it. since the build process is not required before you deploy a driver, then why I need to actually create a build for my driver package? , if this is required for release of the driver package but then releasing driver package will make package "read-only" anyways :), so not sure what is the purpose of the build here.
- Deployment of driver again must have correctly linked attributes DirXML-pkgGUID to latest package build version, looks like a driver uses build version of driver package version to link package, not package version?
- Driver package management ?, these driver package files (.jar) , how to manage them and their ownership and where to store them? one can not lock driver packages to a specific designer project and its ownership to a specific developer on a specific local machine.
maybe someone shed some light on the driver package development process here? Tasks step by step, what others do for internal development for drivers using driver packages?
we are not vendors, we only develop drivers for our own company.