Application Versioning is a unique development style for Unqork teams. Creators and managers should consider and evaluate their need to migrate to a versioned application. Discover if application versioning is right for your team by reviewing the following requirements.
Prerequisites and Considerations for Application Versioning
While using Unqork’s Application Versioning, it’s important to understand the prerequisites and considerations:
Application Versioning for the 7.10.0 release supports only module-type applications. Your environment must be on a later release to use versioning with workflow-type applications and will require the feature flag to be turned on.
Once an application is converted into a versioned application, it cannot be reverted to an unversioned application.
You must set and manage any dependencies from unversioned and versioned applications.
Library modules cannot be used with Application Versioning and must be moved to be accessible.
Application Versioning can be enabled on an application-by-application basis.
Versioning Application Dependencies
When enabling Application Versioning, any modules used by the application, but located in other applications, are considered dependencies and will be versioned. These are commonly imports, like services, handoffs, and so on, where one application ingests modules from another. Creators can think of this other application as the child application. The child application must be set as a dependency on the main (or parent) application. That way, it can access the child application's modules. The child application must have any dependencies located and set. Repeat this process until a child application exists without any dependencies. Application Versioning supports dependencies that are both versioned and unversioned applications.
This model ensures that a given element executing in an application runs as the same version each time.
Copy all Library modules into a new versioned application and add it as a dependency, or move the Library module into an existing application. Copying all Library module definitions requires additional configuration changes and updates.
Below are some other considerations when using dependencies:
Application Settings: If a header, footer, login, or logout module used in your application is located in another application, that application must be set as a dependency in your versioned application.
Module Builder: Panel and Plug-In components allow references to other modules. If Creators want to import or execute a module from a dependency, the relationship must be created.
Workflow Builder: Only modules from the parent application or its dependencies can be used in a Task node. Creators can only hand off workflows from dependency applications. If no relationship exists, modules are not available to select from Task and Handoff nodes.
Dependency Versions: When you set a versioned application as a dependency, you must select either a specific version of that dependency or the default. Choosing a specific version is a controlled way to ensure that there are no inconsistencies or unexpected behavior. You might have cases where a dependency is maintained separately in each environment, and it’s beneficial to use the default for the environment. When you set an unversioned application as a dependency, it acts as the default, always using the current state of that dependency in the environment.
Discover more about child applications (dependencies) in our Introduction to Dependencies article.
Considerations for Proceeding With Application Versioning
Before deciding to enable Application Versioning on existing or new applications, you must understand the required overhead by reviewing the considerations below:
It’s important to understand the technical considerations before enabling application versioning by exploring demo videos and frequently asked questions provided on our Community Hub.
If your environment is on 7.10.x release, you cannot enable Application Versioning on workflow-type applications. You must have the feature flag enabled.
It’s advisable to test Application Versioning on a new application before enabling it on an existing application.
It’s important to discuss as a team how application development will change with Application Versioning enabled:
Choosing a branching strategy.
Determining who is responsible for publications and promotions.
Determining how you want to publish and promote applications. For example, whether to use a primary application for an entire workspace, multiple applications, and so on.
You must modify your applications in the following ways:
Add all dependencies for any imported application element to your versioned application.
Move all Library modules into a new or existing application, and add it as a dependency.
You must use the Application Versioning Promotion feature when promoting the versioned applications. Versioned applications cannot be promoted using the Release Management Dashboard tool.
Ready to use Application Versioning? Learn more in our Getting Started With Unqork’s Application Versioning article.