DTAP: Environment Planning Guide
Introduction
Setting up a priint:suite project requires system architects to carefully plan the environment architecture. This document provides a structured methodology with examples and best practices for implementing a multi-environment setup. It explains how to configure environments correctly, covering server identification, licensing, and troubleshooting.
A proper DTAP implementation (Development, Testing, Acceptance, Production) supports smooth transitions across environments, minimizes errors, and enables efficient collaboration between teams. Whether starting a new project or improving an existing setup, the principles outlined here help maintain stable and scalable systems.
Overview
When planning the infrastructure for a priint:suite installation, several factors must be considered. DTAP is a standard release management cycle used in software and configuration development. Each environment runs separate instances of the publishing server, database, and rendering server.
The number of environments depends on project needs and internal processes. While four environments are typical, some projects may use three or more.
Environment Configuration
Each publishing server uses a unique PUBSERVER_INSTANCE_ID value to identify its environment. This configuration is essential for transferring configurations between environments since all comet configuration objects use environment-specific IDs.
Standard Environments
| Environment | ID | Purpose | Network Location |
|---|---|---|---|
| Production | 0 | Live publishing server used by end users with real data. Highest requirements for safety, stability, and availability. | Customer's local network |
| Acceptance | 1 | Identical to production environment for testing prior to deployment. Requires customer confirmation. | Same network as production but with limited performance |
| Testing | 2 | Separate environment with sufficient test data to validate all relevant cases. | Customer or partner network |
| Development | 3 | Shared development environment for code, data mapping, and plugins. Uses simplified data. | Partner network, typically on virtual machines |
| Local Development | 4+ | Isolated environments for individual developers, demos, or showcases. | Partner network, often on developer machines |
Example Scenario
| ID | Purpose | Abbreviation | Network | Machines | Comment |
|---|---|---|---|---|---|
| 0 | Production | PRD | customer | sql-prd, ps-prd, pim-prd, ids-prd, mam-prd | |
| 1 | Acceptance | ACC | customer | sql-acc, ps-acc, pim-acc, ids-acc, mam-acc | pim-acc is nightly mirror of pim-prd |
| 2 | Test | TST | partner | sql-tst, ps-tst, pim-tst | All on VMs. PS, IDS, MAM on one VM. MAM emulated by local filesystem |
| 3 | Development | DEV | partner | ps-dev | SQL, PS, IDS, MAM on one VM. PIM data from same connection as pim-tst (readonly). MAM emulated by local filesystem |
| 4 | Single developer | Max | partner | PC17-Max | (Laptop) |
| 5 | Single developer | Erika | partner | PC54-Erika | (Laptop) |
Installation and Configuration
During publishing server installation, you'll be prompted for the PUBSERVER_INSTANCE_ID. This value becomes a Payara Server property. While it can be changed via the Payara web console, this is not recommended. Instead, perform a new installation to create a clean repository.
Important Payara Server Properties
| Property | Description | Default Value |
|---|---|---|
| PUBSERVER_NAME | Name of this server in a group of servers for one project | Name of the local machine |
| PUBSERVER_INSTANCE_ID | ID of this server in a group (0-31) | 1 |
| PUBSERVER_NUM_INSTANCES | Maximum number of instances in the group | 32 |
| graphviz.binpath | Local file path to graphviz executables | C:/devstack/tools/GraphViz/bin (in devstack) |
Configuration in domain.xml
<servers>
<server name="server" config-ref="server-config">
<system-property name="graphviz.binpath" value="C:/devstack/tools/GraphViz/bin"></system-property>
<system-property name="PUBSERVER_NUM_INSTANCES" value="32"></system-property>
<system-property name="PUBSERVER_INSTANCE_ID" value="8"></system-property>
<system-property name="PUBSERVER_NAME" value="KONTOSO"></system-property>
<application-ref ref="jackrabbit-jca-2.5.3" virtual-servers="server"></application-ref>
<application-ref ref="PubServerKernel" virtual-servers="server"></application-ref>
<!-- ... -->
</server>
</servers>
ID Conventions
For multi-person projects or multiple server instances, assign a unique integer value to each person or server:
- 0: Production
- 1: Acceptance
- 2: Testing
- 3: Shared development
- 4+: Individual developers
Licensing Requirements
Each publishing server needs a valid license:
- Production environments: Full license fees
- Acceptance/Test environments: Reduced fee (small percentage of full license)
Troubleshooting
When multiple servers create placeholders used together in the same comet project, duplicate IDs may occur, causing issues like:
DEBUG c.p.pubserver.config.PluginConfig - unexpected CustomConfig type: expected=class com.priint.pubserver.comet.entity.template.CometTemplate, found=class com.priint.pubserver.comet.entity.CometIndex
or
'Unable to persist configuration list, reason: 'CONFIGMANAGER: Check-in failed: Exception thrown from PlugIn: PLUGIN: Unable to process updated configurations, reason: 'ProjectCache: ERROR! Found conflicting IDs in
To prevent this, ensure each server's PUBSERVER_INSTANCE_ID is unique from all other "co-creating" servers.