×

Please give details of the problem

Skip to content

Resource Revisions and Project Versions

In DigitalSuite, a project organizes all resources related to an application. The projects as well as most of the resources are versionable. Versions of resources are called revisions.

Resource Revisions

All types of resources are versionable, except for the following:

  • Collections.
  • Non-versioned files. In contrast to versioned files which hold code or data for the application, these files can, for example, be uploaded via a web interface to a running process request, downloaded from a web service, or created by end users during process execution.

Each time a versionable resource of a project is saved, a revision of the resource is created. In DigitalSuite Studio, the list of revisions can be seen in the resource's settings.

All resource revisions are read-only and cannot be modified directly. Changes to a resource are based on its most recent revision and then saved to a new revision. In order to implement changes based on an older revision, this revision first needs to be made the most recent one by reverting to it.

The number of resource revisions is limited. DigitalSuite stores and keeps revisions of each resource according to the following criteria:

  • Any revision that is included in a project version (see below).
  • Any tagged revision. A tagged revision is a revision explicitly marked with a specific color for any reason whatsoever.
  • The latest 50 revisions that are neither tagged nor included in a project version.

Project Versions

Versions of a project can be created to support the different stages in the lifecycle of an application. A version 'freezes' a specific state of the project, which can be managed, deployed, or rolled back.

A project version is created explicitly by a user. It consists of a specific set of the project's resources that is saved at a given point in time. In contrast to resource revisions, the number of project versions is unlimited.

Version Identification

The following settings identify a project version in DigitalSuite:

  • Name: The name of the project version.

    It is a good practice to use consecutive numbers allowing to identify major and minor versions, such as 1.0, 1.1, 1.2, 2.0. The number before the dot denotes the major version, the one following it the minor one. If the version is configured with the keep updated option for all resources (see below), the number should be followed by a corresponding abbreviation, e.g. 1.0 KU.

  • ID: A generated number used to uniquely identify the project version.

  • Description: A short description of the project version, including major changes compared to the previous one.

Version Configuration

The configuration of a project version specifies what is included in it:

  • Resources: A project version does not necessarily comprise all resources that belong to the project. For testing purposes, for example, resources might be included that are not required for a version in production. However, problems will occur if a resource included in a version requires access to another resource which was excluded.

    Versionable resources included in a project version can no longer be deleted.

  • Revisions of versionable resources: By default, the latest revision of each resource is used. However, a different revision of each individual resource can be selected. Non-versionable resources like collections are used in their current state by all project versions.

    Through options, DigitalSuite can be told to automatically keep the revisions of all or specific resources in a project version up-to-date. Whenever a new revision of a corresponding resource is created, it automatically replaces the previous one in the project version. These options should be used with care as the may cause compatibility issues and unintended effects within the project version. In particular, keeping all resources updated should be applied solely for projects which only contain providers and connectors that are unlikely to be modified, or to projects which are subject to small changes like password updates only. The automatic update of single resources can be employed, for example, to ensure that a project always uses the latest contents of a custom list.

  • Versions of subprojects: In a project hierarchy, versioning must be performed bottom up. Each subproject must have at least one version before it can be included in a version of its parent project.

Project versions can be duplicated, for example, for analyzing and correcting problems. The duplicates may include the same resource revisions as the original project version, or the most up-to-date ones. Dictionaries created with the App Translator standard portal application can also be copied to the new version.

Project Versions and Instances

When launching a web interface, process, composite API, or connector, users can choose the desired revision of the resource. This may be the latest revision or a revision included in a specific project version.

Running process requests and web interface instances, which have been launched and persisted with a specific project version, can be upgraded explicitly to a different version. The migration is performed instantly when it is requested, it does not wait for a user activity or for the continuation of a process. The execution mode the instances are running in remains unchanged.

The upgrade of running instances to a new project version should be considered carefully. The decision depends on the changes made for the new version, which may be incompatible and lead to unintended results or even break the execution. A classification of changes and their effects is available here.

Any changes of the project version for running instances are recorded in a project-specific Version Management Log.