Deployment Package Creation - Precisely_EnterWorks - EnterWorks - 11.0

EnterWorks Guide

Product type
Software
Portfolio
Verify
Product family
EnterWorks
Product
Precisely EnterWorks
Precisely EnterWorks > EnterWorks
Version
11.0
Language
English
Product name
Precisely EnterWorks
Title
EnterWorks Guide
Copyright
2024
First publish date
2007
Last updated
2025-01-07
Published on
2025-01-07T07:44:20.997000

Once the development for a deployment and its unit testing in DEV have been performed, the final deployment package needs to be created. The contents of the deployment folder should be reviewed to ensure the latest versions of all files have been copied to it (which should be the case if the best practice of always updating the files their and running the deploy.bat script has been followed). The deployment document also needs to be finalized. The level of detail produced mostly depends on who will be performing the deployment.

A final compare should be done between the DEV and PROD environments. In general, the only differences between the environments should be the ones included in the deployment. However, it is possible that subsequent changes have been made directly to PROD by the customer or that DEV has parallel development that will be included in a later deployment. If differences that are not attributed to a future deployment are found, an assessment must be made as to whether those differences will interfere or overlap with the deployment. If they will, those changes should be made to the DEV environment followed by whatever regression testing is appropriate before completing the deployment package.

There are some deployment artifacts that will not be created until the deployment package is being created. This includes exports from configuration repositories, and the EnterWorks and EPX migration files. The comparison between DEV and PROD can be very helpful with ensuring the all the necessary objects are exported or migrated out of EnterWorks and EPX.

When exporting records from configuration repositories, the user preference "Deploy Export" should be used to ensure only the fields that should be migrated from one environment to another are included. If this user preference does not exist, one should be created. Most of the attributes should be included in the user preference. Ones that should not are typically auto-sequenced attributes (the IDs will likely not match between environments and are excluded from the comparison extracts) and state or timestamp type of attributes.

It is possible that the configuration repository records included in the deployment will contain environment-specific settings. For example, a Scheduled Export may have an FTP server as a target and the FTP server or target directory are different for each environment. Each of the exported repository files should be reviewed to ensure any environment-specific values are updated to reflect the target environment.