Deployment Strategy for On-Prem

Good Morning,

We typically use three environments:

• INT (Integration) for development and integration testing.
• VAL (Validation) for user acceptance testing and release validation.
• PROD (Production) as the production baseline.

In our process, PROD is always considered the reference baseline. When preparing a release package, we build and validate it against that baseline to minimize the risk of deployment issues in production.

Before each release cycle, we perform a database refresh of the INT and VAL environments by restoring a backup of the PROD database. This ensures that testing is performed against a configuration and dataset that closely matches production.

Once the environments are refreshed, the new package is deployed and tested in INT, then promoted to VAL for validation. After successful validation, the package is deployed to PROD using either the Aras Import/Export tools, Solution Packages, or a custom deployment pipeline, depending on the level of automation in place.

This approach has worked well for supporting regular release cycles while keeping environments aligned and reducing deployment risks.

One important point to keep in mind is that any changes made directly in INT or VAL, such as creating users, test data, or configuration records, will typically be lost during the next database refresh from PROD.

If you need a reusable test dataset, I would recommend:

• Creating and validating the test data manually to ensure the data model, business logic, and UI behave as expected.
• Exporting the data using Nash or another suitable extraction method.
• Modifying the generated AML so the records can be safely re-applied after a refresh, typically by using action="add" or action="merge" where appropriate.
• Including these data scripts as part of your deployment or post-deployment process.

Be especially careful with:

• Dependencies between items and relationships.
• Data model changes between releases.
• References to IDs that may differ between environments.
• User, identity, and permission-related data that may already exist in the target environment.

In general, treat configurations and customizations as deployable packages, and test data as a separate, controlled artifact that can be reloaded after each database refresh. This helps maintain consistent test scenarios while still benefiting from regular PROD-to-INT/VAL refreshes.

One final recommendation: if your solution uses files stored in the Vault, don't forget to refresh or synchronize the Vault when performing a database refresh. Restoring only the database without the corresponding Vault contents can result in missing file references and testing inconsistencies.

Regards

Michael