Project Versions in Execution Modes

New projects initially do not have any versions. Versioning is not required for developers and designers to perform their tasks. However, as the applications the projects belong to go through their lifecycle, multiple versions will be created.

Project Lifecycle

A project version is always created in Test mode and then usually pushed forward from Test to Acceptance to Live or directly from Test to Live. Multiple project versions may exist at the same time in Test mode as well as in Acceptance mode. In Live mode, only one version is available for productive use.

Project versions can also be pushed in the opposite direction, i.e. from Live to Acceptance to Test or from Live to Test:

• Going back from Acceptance to Test may be useful, for example, to solve issues reported in acceptance testing.
• Moving the Live version to Acceptance or Test should be considered very carefully. It means that no version is left in production for access by the end users and makes sense only when closing down the application completely. During the application's lifetime, the Live version is rather replaced by pushing new project versions from Test or Acceptance to Live. This automatically changes the execution mode of the previous Live version to Test, even if process requests and web interface instances are still running. See Lifecycle with Predecessors and Instances below for more details.

The execution mode of a subproject is independent of the mode of the main project. An application that is already staged for acceptance may, for example, include subprojects that are still in development.

When launching a web interface, process, composite API, or connector, users can choose the desired revision of the resource as well as its execution mode. A resource revision which is included in the project version deployed to Live, can be launched in Live mode as well as in Acceptance or Test mode, which may be useful for analyzing and fixing issues. Similarly, resource revisions of project versions in Acceptance can be executed in Acceptance and Test mode. For resource revisions which are not part of any project version or are included in project versions deployed to Test, only execution in Test mode is possible.

Project Version Characteristics

Project versions have different configurations and characteristics depending on the execution mode they are deployed in:

Test Mode Characteristics

A project version running in Test mode is characterized as follows:

• Only users with Designer access rights are authorized to modify the project's resources and launch its web interfaces, processes, composite APIs, and connectors in Test mode.
• The designer who launches an application in Test mode is assigned all manual tasks and receives all notifications, although the emails specify who would receive them in a production environment.
• The Live content of the defined roles is used.
• The Test contents of collections are used.
• The Test connector configuration is used.

Acceptance Mode Characteristics

A project version running in Acceptance mode is characterized as follows:

• A set of selected users is authorized to access the version.
• Manual tasks are assigned to users according to their roles, and notifications and emails are sent to the users specified as recipients.
• Each user in Acceptance mode has the same permissions as the end users will have in Live mode.
• The Acceptance content of the defined roles is used.
• The Acceptance contents of collections are used.
• The Acceptance connector configuration is used.

Live Mode Characteristics

A project version running in Live mode is characterized as follows:

• The version can be accessed by the end users.
• The web interfaces can be made available on the custom homepages customers have configured for desktop and mobile devices.
• Manual tasks are assigned to different users according to their roles, and notifications and emails are sent to the users specified as recipients.
• The Live content of the defined roles is used.
• The Live contents of collections are used.
• The Live connector configuration is used.
• If no mode parameter is set when launching the application, the Live mode is used by default.

Lifecycle with Predecessors and Instances

Pushing the first version of a project from one execution mode to another does not pose any problems. Careful consideration is required, however, if a predecessor version of the project has already been deployed in the target mode, and in particular if process requests and web interface instances launched with the predecessor version are still being executed:

• No process requests and web interface instances are running in the target execution mode

  The new project version can be pushed to the target mode without any concern. Process requests and web interface instances launched afterwards are based on the new version.

• Process requests and web interface instances are running in the target execution mode:

  The execution of these instances can be continued with their current project version or with the new project version being pushed. 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.

  If the decision is to change the project version, running instances are automatically migrated to the new version with the next execution step. The changes are recorded in the project's Version Management Log.

  Continuing with the current project version may result in instances of multiple versions running in the same execution mode, since new instances will be based on the new project version being deployed. If desired, existing running instances can still be upgraded explicitly to the new project version later on.

In the Test and Acceptance execution modes, a new project version is added to the existing ones. In Live mode, the project version being pushed replaces the existing one, whose execution mode is automatically changed to Test. The execution mode of running instances remains unchanged.

At a Glance

The diagram below shows the interrelations of project versions, resource revisions, and execution modes. Three different versions of the project are deployed to Live, Acceptance, and Test. Each version includes different revisions of the resources (green, yellow, blue). As development continues between project versions or following the latest version (2.1 in Test mode), more resource revisions are created, which are not or not yet included in any project version. The last revision of each resource is shown in red.