The Deployment Group That Left Its Dependencies Behind
A retail company runs Informatica PowerCenter 10.5.2 with separate DEV and QA repositories. In DEV, folder SHARED holds three reusable transformations: seq_order_id, lkp_customer_current, and exp_std_address. Twenty-two mappings in folder SIL reference them through shortcuts. QA was populated five months ago by copying objects rather than shortcuts, so QA has independent copies. Last week a developer added two ports and changed null handling in exp_std_address, then created a deployment group containing only m_load_order and deployed it to QA. The QA session fails immediately with an invalid-mapping error and a port-count mismatch on the address expression. A second developer cannot determine which version of lkp_customer_current is in QA. Versioning is disabled on all folders, and there are no labels. Release is in three days, and the QA team does not want its unrelated objects overwritten.
1. Diagnose the QA failure. What should the deployment group have contained, and how would you confirm the dependency chain before redeploying?
Read the worked answer
The failure is a dependency-resolution problem, not a mapping-logic problem. m_load_order in DEV uses shortcuts to reusable objects in SHARED. The deployment group contained only the mapping, so QA received a mapping whose referenced objects were either absent or still at the old port layout. The port-count mismatch on exp_std_address is the signature: the mapping expects the two new ports, while QA resolves the old copy.
Before redeploying, open m_load_order in Repository Manager and use Show Dependencies recursively. Capture every reusable transformation, mapplet, source definition, target definition, and shortcut target. Build a new deployment group that includes m_load_order, exp_std_address, lkp_customer_current, seq_order_id, and any other dependent objects at the same version. If QA must keep its own copies, deploy the objects as copies and then validate the mapping in QA; do not assume the import resolved shortcuts.
Also compare the QA and DEV versions of lkp_customer_current before overwriting. If QA has local changes, merge them deliberately rather than replacing the object. After import, open the mapping in QA and run Validate; a clean validate plus a session dry run on a small file is the acceptance test.
2. Recommend repository controls to prevent this class of failure, including how to handle the three-day release.
Read the worked answer
Enable versioning on SHARED and SIL before the release, even if only a few objects are under change. Versioning lets the team check out exp_std_address, see who changed it, and revert or compare versions. Create a label such as REL_2024_03_01 on the exact object versions that make up the release. Labels turn a set of independent objects into a reproducible baseline; without them, QA cannot answer what is deployed.
Use deployment groups as the unit of promotion, not individual mappings. A group should include the mapping plus its dependent reusable objects and definitions, and it should be tested by importing into a clean QA folder or repository. Store the exported XML with the release ticket. For the current release, freeze SHARED changes after the label, deploy the group, validate, and run a row-count reconciliation. If QA has unrelated local objects, deploy into a new folder or use a controlled merge; do not overwrite the whole QA folder.
The key distinction is between isolating QA and freezing its contents. Isolation should come from a clean target folder and a complete dependency list, not from hand-copying objects and then losing track of versions.
3. The team debates replacing all shortcuts with copies in DEV to simplify deployment. Give your recommendation and the trade-offs.
Read the worked answer
Replacing shortcuts with copies would make each mapping self-contained at export time, but it creates 22 independent copies of the same address logic. A defect fix would then require 22 edits, and the copies would drift. That is the opposite of reuse and is how the QA mismatch arose.
Keep shortcuts in DEV for objects that are genuinely shared, but make the shared layer an explicit deployable unit. Put the reusable transformations in a SHARED folder and deploy that folder, or a deployment group containing it, before any mapping that references it. In QA, if isolation is required, import the SHARED objects as copies once and then promote only the shared layer plus changed mappings. Document the rule: shortcuts within a repository, deployment groups across repositories, and no hand-copied objects.
The trade-off is that shortcut-based deployments need dependency checks and a defined promotion order. That cost is lower than maintaining duplicate logic across 22 mappings. Validate the approach with one pilot mapping before applying it to all 22.