Shared library versions and non-reproducible BAR overrides
Two teams deploy ACE applications to the same integration server. Team A owns OrderApp, which references a shared library named CommonLib. Team B owns BillingApp, which also references CommonLib. CommonLib 1.2 is in Team A's BAR; CommonLib 1.3 is in Team B's BAR. Both BARs were built from the same integration node workspace at different times. Last week Team B deployed BillingApp with CommonLib 1.3 and its flows passed. This week Team A redeployed OrderApp with CommonLib 1.2, and BillingApp began failing with class-loading and behavior errors. Separately, production endpoint URLs are changed manually with mqsiapplybaroverride after each deployment, but the override files are not stored in version control. A rollback last month restored the previous flow code but left the new endpoint URL in place, causing an outage.
1. Explain why Team A's redeployment broke Team B's application. What are the deployment options to prevent this?
Read the worked answer
A shared library is referenced by name, and an integration server hosts one deployed version of a shared library with a given name at a time. When Team A redeployed OrderApp with CommonLib 1.2, that deployment replaced the CommonLib 1.3 that BillingApp was using. BillingApp may then bind to the older library or fail to resolve classes and resources that only exist in 1.3. The BAR contents and deployment order matter; this is not a classpath isolation problem that a restart will fix.
Options: deploy the two applications to separate integration servers so each can have its own CommonLib version; or give the libraries versioned names, such as CommonLib_v1_2 and CommonLib_v1_3, and have each application reference the correct name. Versioned names make the dependency explicit but require application changes and a policy for retiring old versions. A third option is to standardize on one backward-compatible library version and enforce it through a shared release process, but that requires both teams to coordinate every change.
Do not rely on deploying BillingApp after OrderApp to fix it; that just reverses the breakage. Choose isolation or versioned names based on how often the library changes and whether the teams release independently.
2. Design an immutable, auditable build-and-deploy process for BAR files and environment-specific properties.
Read the worked answer
Build each BAR once per source commit and promote that exact artifact through environments. Store the BAR, its checksum, the source commit, and the property override file in an artifact repository. Environment-specific values such as endpoint URLs, credentials references, and queue names should be applied by a deterministic override step using a versioned property file, not by manual edits in production. If the override is applied at deploy time, record the resulting effective configuration alongside the deployment record.
Separate build-time from deploy-time configuration. Do not rebuild the BAR for each environment, because that creates untraceable differences. Do not use the BAR editor to change production properties. Use the same property file format for test and production where possible, with only values differing, and validate required properties before deployment.
Include a pre-deployment check that the BAR's shared library versions match the target server's policy, and a post-deployment smoke test. The deployment record should answer: which BAR, which override file, which target server, who approved it, and what the previous artifact was. That record is what makes rollback reliable.
3. What rollback strategy would you use after a bad BAR deployment, given the shared library and override failures described?
Read the worked answer
Keep the previous BAR and its exact override file as a matched pair, and roll back to that pair, not just to the previous flow code. Deploy the previous artifact to an inactive integration server or a separate server group, verify it with smoke tests, then switch traffic. If the bad deployment changed a shared library used by another application, a same-server rollback can still break the other application; that is another reason to isolate applications by server or use versioned library names.
Before switching, compare the effective configuration, not only the BAR name. Verify endpoint URLs, queue names, credential aliases, and shared library versions. After the switch, confirm that both OrderApp and BillingApp health checks pass, not only the application that was rolled back. If a same-server rollback is unavoidable, stop traffic, restore the previous BAR and override file together, restart the integration server if required, and re-run end-to-end checks.
Finally, add a rule that every deployment must be reversible within a defined window and that override files are never edited only in production. The outage occurred because code and configuration were rolled back independently; the fix is to version and deploy them as one unit.