The Project Configuration module allows you to define and manage projects that group the resources required to build and run your applications. You can manage multiple versions of a project with specific revisions of the resources and launch them in different execution modes.
A project organizes all resources related to an application. It is the starting point for building the application and manages the application's lifecycle. The resources of an application may include web interfaces, processes, collections, composite APIs, custom lists, providers, connectors, and versioned files. For details, refer to Project Resources.
A project may include subprojects. A subproject is a separate project that is imported to the main project. Using subprojects reduces a project's complexity and enables you to reuse projects. The access rights for a subproject may differ from those defined for the main project. This enables you to build a highly refined access rights system. For details, refer to Access Rights.
Versions of a project are created to support the different stages in the lifecycle of an application. A version allows you to 'freeze' a project so that you can manage, deploy, and rollback applications.
A version is created at project level. It is based on a specific set of project resources that is saved at a given point in time. A project version does not necessarily include 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. When creating a version, you can individually select the resources to be included.
All types of resources are versionable, except for the following:
- Collections: A specific collection is used by the resources in all project versions and available in all three execution modes.
- Files stored with your project: 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.
When creating a version of the main project in a project hierarchy, you need to select the version of each subproject to be used. Versioning must be performed bottom up. Each subproject must be versioned before the main project can be versioned. 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.
Each time a versionable resource of a project is saved, a revision of the resource is created. When you create a version of a project, the latest revision of each resource is included by default. Yet, you have the option of individually selecting the revision to be included.
DigitalSuite supports an unlimited number of versions per project. The number of resource revisions, however, is restricted. The following revisions are stored and can be selected when creating a project version:
- All revisions that are already included in a version.
- All tagged revisions: A tagged revision is a revision that you have explicitly marked for any reason whatsoever.
- The latest 50 revisions of a resource: This revision history is limited to 50 revisions that are neither tagged nor included in a version.
To support the entire lifecycle of applications within a single, seamless environment, DigitalSuite provides for one-click deployment and automated configuration. The deployment of an application spans development, staging, and production. For this purpose, DigitalSuite distinguishes between three execution modes denoting the environment in which a specific version of the application is running: Test mode, Acceptance mode, or Live mode.
Initial development activities include designing and building the application. This already includes regular tests by the development team. The work of the development team is completed by creating the first version of the application.
For testing the first version, the development team deploys it in Test mode. In this mode, the only user involved is the user who initiates and performs the tests. All tasks are automatically assigned to this user and all email notifications are sent to this user, although the emails specify who would receive them in a production environment.
Once the development team is satisfied with the application, it can be rolled out for further testing by a wider audience. Typically a selection of end users is involved in acceptance testing to ensure that the solution meets their requirements. To proceed with acceptance testing, the application is deployed in Acceptance mode. Specifically selected users test the behavior and performance of the application from an end user's point of view, but without any impact on the production environment and data.
Once the selected end users have approved the application in Acceptance mode, it is ready for productive use. It is deployed in Live mode which makes it available for genuine business purposes in the production environment.
Ongoing day-to-day changes and enhancements to an application require upgraded or new versions to be released as part of maintenance activities. Each time an application is deployed in Test, Acceptance, or Live mode, a copy can be used for debugging, bug fixing, or continued feature development before pushing updates to the application in production.
Refer to the Lifecycle Guide for details on deploying applications to the three environments.
At a Glance
The diagram below shows the interrelations of project versions, resource revisions, and execution modes. It depicts the three isolated environments for deploying project versions and running the deployed applications. Three different versions of the project are deployed to Live, Acceptance, and Test. Each version includes different revisions of the resources.