Application Lifecycle

Unqork applications move through a series of environment levels before reaching end-users. Understanding this lifecycle helps Creators work safely, avoid Production mistakes, and recover quickly when issues arise.

Environment Levels

Unqork organizations operate across multiple environment levels. Each level serves a distinct purpose, and resources move between them through a process called promotion.

The standard progression is: Staging → Quality Assurance (QA) → User Acceptance Testing (UAT) → Production.

For detailed environment descriptions, see Environment Levels.

Promotion Pipeline

Promotion is how resources move from one environment to the next. A Creator with the appropriate permissions uses the Promote action to move a module, service, style, or other resource to a higher environment.

How Promotion Works

1. Creators configure and test a resource in Staging.
2. The Creator promotes to QA, where QA engineers verify functionality and quality.
3. After QA passes, the Creator promotes to UAT, where business stakeholders or product owners accept the build.
4. After UAT sign-off, a release manager promotes to Production.

Each promotion is a deliberate action. Resources do not move between environments automatically.

Promotion Limitations

Promotion moves the resource but not its dependencies. If a module depends on a service, style, or another module, those dependencies must be promoted separately before promoting the module. Promoting a module without its dependencies can cause issues in the target environment.

Before promoting to Production:

• Verify all services the module calls are promoted to Production.
• Verify all styles the module uses are promoted to Production.
• Verify all modules the module depends on are promoted to Production.
• Confirm environment configuration in the target environment matches expectations (authentication settings, session management, integrations).

Important: Environment configuration does not transfer when resources are promoted. Each environment has its own independent configuration, managed in Environment Administration.

Working in Production

Production is the only environment where live client data is stored and where end-users access the application. Following software development best practices, development should never take place in Production.

Production Designer Access

Creators with the appropriate permissions can open modules directly in Production. However, Production blocks draft-based development, which is the standard workflow in pre-production environments. Any changes saved in Production go directly to the live published version with no draft buffer and no automatic rollback.

Important: There are no warnings or confirmation dialogs when editing in Production. Saving a change in Production immediately updates what end-users see.

Recommended Approach

All development should begin in Staging and move to Production through the promotion pipeline. This ensures changes are tested before they reach end-users. It also preserves a known-good version in lower environments for restoration if needed.

Common Mistakes

Editing Directly in Production

What happens: A Creator opens a module directly in Production, makes changes, and saves. The changes go live immediately, with no testing, no review, and no automatic rollback. If the change breaks the module, end-users encounter the broken version in the production application until the issue is resolved.

How to avoid it: Always verify the current environment before making changes. The environment name displays in the platform navigation. If in Production, close the module and open it in Staging instead. Making changes in Staging ensures the update moves through the full promotion pipeline (QA, UAT, and then Production), the same as any other change.

Forgetting to Promote Dependencies

What happens: A Creator promotes a module to Production, but the service it calls is still on an older version in Production. The module references functionality that does not exist in the Production service, causing issues for end-users.

How to avoid it: Before promoting any resource, audit its dependencies and promote them in sequence. Promote services and styles before the modules that use them.

Assuming Configuration Transfers

What happens: A Creator configures an integration or authentication setting in Staging and promotes the module through the pipeline to Production. The integration fails in Production because the configuration (API keys, allowed origins, session settings) was never set up in the Production environment.

How to avoid it: Treat each environment's configuration as independent. After promotion, verify that environment-level settings in the target environment are correctly configured for the promoted resource.

Promoting Incomplete Work

What happens: A Creator promotes a module mid-development, intending to finish later. The incomplete module reaches Production and causes issues or exposes an unfinished interface to end-users.

How to avoid it: Only promote modules that are fully tested and ready. Use QA and UAT environments to prevent incomplete work from reaching Production.

Recovering from Production Issues

Accidental Edit in Production

If a Creator saves a change directly to a Production module:

1. Identify the last known-good version in a lower environment (Staging or UAT).
2. Promote the known-good version from the lower environment back to Production. Promoting overwrites the accidental change with the correct version.
3. Verify the restored version by checking the module in Production before end-users encounter issues.

Important: Do not attempt to fix the module by making additional edits in Production. This compounds the problem. Restore from a lower environment instead.

Broken Module After Promotion

If a module breaks after promotion to Production:

1. Promote the previous working version from the lower environment to Production.
2. Investigate the issue in Staging or QA, not in Production.
3. Fix and test in the lower environment before promoting again.

Dependency Missing in Production

If a module fails because a dependency is missing or outdated in Production:

1. Identify the missing or outdated dependency (service, style, or module).
2. Promote the correct version of the dependency to Production.
3. Verify the module after the dependency is in place.

Best Practices

• Never develop in Production. All changes begin in Staging.
• Always check the current environment before saving. The environment name displays in the platform navigation.
• Promote dependencies first. Promote services and styles before the modules that depend on them.
• Test at every level. QA and UAT exist to catch issues before they reach end-users.
• Keep lower environments in sync. Staging should always reflect what is in Production so it can serve as a reliable restore point.
• Never assume configuration transfers between environments. Verify environment settings after every promotion.