LinkedIn
Copied!

Table of Contents

Configuring an application

Version:

Only available versions of this content are shown in the dropdown

There are a few requirements and recommendations for structuring an application that is being managed using Deployment Manager. See this brief overview to get started with configuration.

Add PegaDevOpsFoundation as a built-on application

The PegaDevOpsFoundation application provides the capabilities to execute pipeline tasks and adds pipeline integration to the Dev Studio and App Studio. Any application that is being managed by Deployment Manager must include it as a built-on application.

Use the major version of the application so patches and minor versions can be taken without updating the application. For example, include PegaDevOpsFoundation:5 as a built-on instead of PegaDevOpsFoundation:5.1.1.

For new applications

New applications only need to be updated on the development environment. Deployment Manager is capable of migrating the whole application to new environments as part of deployment pipelines.

For applications that have already been deployed to all environments

If the application has already been deployed to all environments, it is required to manually update the application record on each environment to be built on PegaDevOpsFoundation. The next deployment will sync up the application changes and will result in an aged update message on Deployment Manager.

Create a development layer

The target application is regularly packaged and promoted to higher environments so it is important to exclude branches and any other work in progress. A development layer consists of:

  • An application that is built on the testing, or target application. Consider following the naming convention: {TargetApp}Dev.
  • An unlocked ruleset for any developer tools, or work that is never intended to be promoted to higher environments.
  • An access group that logs into the development application.

Development layers can be assigned to developers as needed, whether it is one per application, team or developer.

Using a development layer also allows you to keep the target application locked to prevent unintentional changes.

Create a test layer

Testing assets are managed by Deployment Manager pipelines, but they are only deployed to a subset of environments. To manage and run test cases it is necessary to create a test layer. A test layer consists of:

  • A locked application that is built on the target application. Consider following the naming convention {TargetApp}Tests.
  • A ruleset for all test cases and test assets.
  • An access group that logs into the test application.
  • A product rule that defines which assets get promoted by the pipeline.

Summary

If you have followed all the recommendations in this article, you should end up with an application that is structured like the one seen below.

Configured application

Configuring the development system for branch-based development in 5.1.x

If you are using branches in either a distributed or non-distributed branch-based environment, configure the development system so that you can start deployments when branches are merged. Configuring the development system includes defining the URL of the orchestration server, creating development and target applications, and locking application rulesets.

  1. On the development system (in nondistributed environment) or the main development system (in a distributed environment), create a dynamic system setting to define the URL of the orchestration server, even if the orchestration server and the development system are the same system.

    1. Click Create Records SysAdmin Dynamic System Settings .

    2. In the Owning Ruleset field, enter PegaDevOpsShared.

    3. In the Setting Purpose field, enter OrchestratorURL.

    4. Click Create and open.

    5. On the Settings tab, in the Value field, enter the URL of the orchestration server in the format http://hostname:port/prweb/.

    6. Click Save.

      For more information about dynamic system settings, see Creating a dynamic system setting

  2. Complete the following steps on either the development system (in a non-distributed environment) or the remote development system (in a distributed environment).

    1. Use the New Application wizard to create a new development application that developers will log in to.

      This application allows development teams to maintain a list of development branches without modifying the definition of the target application.
    2. Add the target application of the pipeline as a built-on application layer of the development application by first logging into the application.

    3. In the header of Dev Studio, click the name of your application, and then click Definition.

    4. In the Built-on application section, click Add application.

    5. In the Name field, press the Down arrow key and select the name of the target application.

    6. In the Version field, press the Down arrow key and select the target application version.

    7. Click Save.

  3. Lock the application rulesets to prevent developers from making changes to rules after branches have been merged.

    1. In the header of Dev Studio, click the name of your application, and then click Definition.

    2. In the Application rulesets section, click the Open icon for each ruleset that you want to lock.

    3. Click Lock and Save.

  4. Copy the development repository that you configured on the remote development system to the source development system.

  5. If you are managing test cases separately from the target application, create a test application. For more information, see Managing test cases separately in Deployment Manager.

  6. Optional:

    To rebase your development application to obtain the most recently committed rulesets after you merge your branches, configure Pega Platform so that you can use rule rebasing.

    For more information, see Understanding rule rebasing.

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.