Are there alternatives to building multiple region-specific artifacts for IIQ?

Which IIQ version are you inquiring about?

Version 8.4

Share all details related to your problem, including any error messages you may have received.

Hello! I am not an IIQ developer, I’m working on a CICD pipeline for IIQ. I’m currently focused on the ‘build’ portion of the pipeline, where it will run the commands to invoke the SSB build & store the generated artifact(s) in our artifact repository.

Based on the content in the ‘Services Standard Build User Guide’ (e,g, sections such as ‘Setting up environment-specific properties files’ section, ‘Using the SPTARGET environment variable to specify the build environment’, ‘Configuring target.properties files’), I see the standard build setup generates an artifact with a particular region’s build configuration ‘baked into’ the artifact. With multiple regions, this results in building multiple region-specific artifacts and storing each of them in our artifact repository.

Since per-region artifacts increases the storage needs in the artifact repository by the # of regions, is there an alternative approach where 1 artifact can be generated? For example, is there some way to defer the region-specific properties replacements to later in the pipeline and do them just before deployment time?

Thank you for taking the time to read this! I’d appreciate any insights you can provide.

Don’t know if i get correctly what you want to achieve. Do you want to make build for example to dev, test, acc, prod environments but create only 1 war file with build?

@kjakubiak is asking the right question. What do you mean by region?

Sorry for using jargon internal to my company. Looking at the documentation, when I said ‘region’, I’m thinking that is what the documentation calls ‘environments’ (where each environment has it’s own iiq.properties file). I’ll plan use the term ‘environments’ going forward.

That’s correct, does SSD/SSB have an option where we can build 1 war file & do the environment configuration (e.g. the substitutions from the .iiq.properties files) at a later step as part of the deployment? The development team I’m working with is creating an artifact per environment currently. My team is wondering if there is an alternative approach provided as part of SSB/SSD, or if 1 artifact per environment is the only supported option.

In theory - yes
In practice - don’t think so :slight_smile:

Generaly I can imagine process where you build war file once and than apply tokenization to this file (as this is the only difference between environments) but that would also mean that you need to build your own fully custom build process for that.

OoTB SSB works in the following way that ant builds the war file and includes there all IIQ libs, compiled classes and XMLs after tokenization. That means you can just take this war file, deploy it to you tomcat and you have working environment.

What you would need to do would be to build war file with IIQ libs and compiled classes (because this is common for all environments) and than during deployment process you would need to do tokenization - that means you would need to replace all %%TOKEN%% values with correct values read from environment.target.properties (which you would need to have btw on your deployment server).

Just to summarize - if you have enought knowledge and experiance to create your own custom build process for IIQ like I explained above than for sure it is possible - it might cost you some work but should solve your problem.

3 Likes

Thank you, that answers my question. I appreciate your taking the time to respond!

@DougMac , just a further thought here…

I’m not sure how you are planning to implement the SSB, but here is an overview of what we have running in Prod:

Basically, we have two repos in GitLab - one to house the SSB and build the WAR and then one more “downstream” repo that we pass the WAR to. The downstream repo pipeline then pushes the WAR to the IIQ servers and does a bunch of other server configuration automation using Ansible.