[Trigger Pipeline] How to automate Database Catalog selection in CI/CD pipelines via LifeTime API?

Back to Forums

Pedro Pereira

Question

Forge

Lifetime

OutSystems 11

Deployment

Hi everyone,

We have recently integrated OutSystems CI/CD into our Azure DevOps pipelines using the Python-based approach and LifeTime APIs. However, we are facing a recurring bottleneck when deploying modules that do not yet exist in the target environment.

The Issue: Every time a new module is deployed, the pipeline pauses because manual intervention is required in LifeTime to select the appropriate Database Catalog. Since we have multiple catalogs (e.g., Main and Secondary), the deployment doesn't "guess" the destination, blocking the pipeline and impacting our release frequency.

We already attempted to associate the catalog to the module directly in Service Center, but LifeTime still prompts for manual selection during the deployment plan creation.

Our Goal: We want to force the "Main" catalog automatically via the pipeline script, ensuring a zero-touch deployment even for new modules.

Questions:

How can we define the TargetCatalogKey using the LifeTime API during the DeploymentPlan phase?
If an API-based solution is not feasible, is there a way to define a "Default Catalog" per environment in LifeTime so that it stops asking for manual input?
Is it possible to make the pipeline dynamically inherit the catalog from the source environment?

Thanks in advance for the help.

5 days ago

Saugat Biswas

Hi @Pedro Pereira

The answer to all your three questions is NO.

Answer 1: The LifeTime APIs:

Allow you to create a deployment plan
Allow you to execute a plan
Do not expose any parameter to override or inject catalog selection

Note: The catalog decision is outside the API contract and must already exist in the target environment.

Answer 2: Lifetime:

Has no environment‑level default catalog
Has no global catalog mapping rules
Has no auto‑assignment behavior

Note: Every new module must be explicitly mapped once per environment.

Answer 3: Catalog bindings are:

Environment‑specific
Not portable
Not part of the application metadata

Note: LifeTime intentionally avoids copying this configuration to prevent accidental cross‑catalog deployments.

Solution: Unfortunately, no solutions exist at present, but workarounds are there:

Workaround 1: Pre-bind catalog in target environment.

Before a module is ever deployed via CI/CD:

Go to Service Center in the target environment
Import the module once (manual or scripted)
Assign it to the Main catalog
Never touch it again

From that point onward, LifeTime no longer prompts and CI/CD becomes fully automated.

Workaround 2: Seed deployment

Pattern:

Maintain a bootstrap pipeline or manual step that:
- Deploys empty or initial versions of new modules
- Assigns them to the correct catalog
Your main pipeline only deploys updates, never first‑time modules

Think of it as: Environment provisioning vs application delivery for a module.

Hope this helps.

Cheers,

Saugat

4 days ago

1 reply

4 days ago

Show thread

Hide thread

Saugat Biswas

A better approach could be to use architectural constraint:

If possible:

Use one catalog for deployable application modules
Reserve secondary catalogs for:
- Legacy schemas
- External DB integrations
- Non‑LifeTime‑managed objects

This may completely eliminate the issue. You may need to test this out.

Cheers,

Saugat

4 days ago

Dorine Boudry

MVP

I personally wasn't involved in this, but at one of my clients, i know they had a robot log in to lifetime and do the assigning of the catalog when needed for new modules.

4 days ago