3.1 Ongoing Build and Deployment

Ongoing Build and Deployment

Objective 1.4, understand ongoing build and deployment of IdentityIQ, covers the time after installation: new rules, workflows, applications, and Java code must move safely from a developer sandbox to production. The exam expects you to know what the product offers for moving objects and how SailPoint's standard build tooling packages them.

What Actually Gets Deployed

An IdentityIQ implementation has four kinds of change, and each moves differently:

Moving XML Objects Between Environments

The IdentityIQ console (section 14.3) has the core commands:

• export writes all objects of one or more classes to a file. For example, export -clean workflows.xml workflow exports every workflow.
• checkout writes a single object, for example checkout rule "Cert Signoff Approver" certrule.xml.
• -clean removes values that do not transfer between installations. With no qualifier, it clears id, created, modified, and lastRefresh. You can also list specific fields.
• import loads an XML file. import -noids removes all ID attributes before parsing. -noroleevents suppresses role-change events for role propagation.

Removing IDs matters because every database generates its own object IDs. References between objects should use names, which stay the same across environments. An object exported with its development ID can clash in production.

The first tag in an import file tells IdentityIQ how to process it:

• <JasperReport> is a Jasper report.
• <sailpoint> (the IdentityIQ import wrapper) can hold many objects plus an ImportAction that directs processing: merge (combine with an existing object, often used for UIConfig or SystemConfiguration entries), include (pull in another file), execute, or logConfig.
• Anything else is treated as a single object.

Administrators without console access can use Global Settings > Import from File for the same XML import in the UI.

The Services Standard Build (SSB)

SailPoint's Services team publishes the Services Standard Build (SSB), a set of Ant artifacts used on most professional implementations. The companion Services Standard Deployment (SSD) adds deployment helpers. What to know:

• One source tree for all environments. A base folder holds the IdentityIQ release (ga), plus any patch and efix archives. config holds your custom XML (applications, rules, workflows, task definitions), src holds Java, and web holds UI overrides.
• build.properties records the IdentityIQ version and patch level to build.
• Environment selection. Set the SPTARGET environment variable (for example, sandbox, dev, test, or prod) or map a machine name to an environment in servers.properties.
• Tokenization. Custom XML uses placeholders such as %%AD_HOST%%. At build time, SSB replaces them with values from that environment's <env>.target.properties file, so one rule or application definition can serve every environment. <env>.iiq.properties supplies the environment's iiq.properties, and <env>.ignorefiles.properties excludes files that must not ship to that environment.
• Outputs. build clean removes old output. build war produces build/classes (compiled Java), build/extract (the expanded application with tokens replaced), and build/deploy/identityiq.war. A deploy target can expand the WAR into a local IdentityIQ home and run the custom import. The generated import manifest (sp.init-custom.xml) lists the custom objects to load.
• Check the extract. A leftover %% token in build/extract shows that a target property was never defined for that environment.

Operating Practices the Exam Rewards

• Keep XML in source control. SailPoint's own console documentation describes storing workflows and rules in source control and importing them with import.
• Restart only when needed. Importing a rule or workflow takes effect without a restart. A new JAR, a compiled class, a changed .hbm.xml file, or a replaced web file needs the application server restarted, and in a cluster every host must get the same build.
• Build once per environment and test it. Promote the same source to test and production. Do not hand-edit objects in production's Debug pages, which have no rollback.
• Keep patch levels identical. Because the build includes the base release and patch, every environment should run the same IdentityIQ version and patch level before objects are promoted.