Preparation - Precisely_EnterWorks - EnterWorks - 11.0

Typically before a deployment is started, the contents of the deployment are already known. However, the list of changes often grows during development which can happen over a long enough period of time that some of the details of what has changed are forgotten. This can be mitigated by following best practices and preparing for each deployment by creating a Deployment Document (from a template) and creating a deployment folder on the DEV server in the EWSoftware folder.

The Deployment document should contain the following elements:

• Name and date of the Deployment.
• Customer or Project the Deployment is for.
• Overview that includes a summary of what the deployment contains, for example, a bullet list of the deployment contents. If the deployment includes a patch, an aggregate list of all changes since the current patch should be included, with the ones that potentially affect the target implementation highlighted.
• Pre-deployment instructions, such as clearing work items from workflows being deployed.
• List of files in the deployment folder on the server.
• Sequence of steps to run the deployment, grouped by physical area (some or all of the following):
  • Back up the current configuration
  • Copy Files
  • Install Patches
  • Update Configuration Files
  • Update EPIM Database
  • Update EnterWorks Data Model
  • Update Configuration Repositories
  • Update EPX Workflows
• Sequence of steps to verify successful deployment
• Sequence of steps to roll back the deployment should it become necessary

In general, the more detail that is included in the deployment document the more likely the execution of the deployment will be successful.

Every time a new change is made in DEV for the deployment, the deployment document should be updated to cover that change. This practice takes some effort to develop into a habit, but it will pay dividends in the long-run – especially if the development period is spread over a larger amount of time.

If the development is a group effort, the deployment document should be placed in a shared location such that concurrent updates are possible. If the development is being done by a single person, the deployment document can be maintained locally.

The deployment folder on the server should contain any files that are part of the deployment. This does not include existing files that are only being modified (such as values in the EnterWorks.properties or sharedConfig.properties file) and not replaced. A deployment script (named to indicate its purpose, such as deploy.bat) should be defined in the same folder to move the files to the appropriate locations and run any deployment scripts (the DeployServicesJar.bat and CopyEpimJarsToEPX.bat). Instead of manually copying the files to the target locations, any updates to the files should be placed in the deployment folder and the deploy.bat script run to copy them for you. This accomplishes several things: first, it ensures that the files are always placed in the correct location with the least amount of effort and second, it provides an opportunity to test the deployment process in a limited fashion in the DEV environment.

Except for the deploy.bat script, the files in the deployment folder should never be modified "in-place". Instead, they should be modified and maintained in your source control/development environment, then copied to the deployment folder each time they are changed (and the deploy.bat script run to copy those files to the appropriate locations). This ensures that a file changes are captured in the source version control.

Since some files (such as JARs) require running of other scripts and restarting services while others (such as JSPs) can be copied while EnterWorks services are running, it may be beneficial to define several deployment scripts and have the deploy.bat call all of them. For example, the script deployFilesOnly.bat can be defined to copy the files that do not require a services restart. The script deploySqlOnly.bat can be defined to load any SQL scripts into the database. The main deploy.bat script would call these two as well as perform the operations that require a services restart. It may seem redundant to copy all files anytime one of them changes, but the time required is negligible and it ensures that nothing is missed (i.e., copied to the deployment folder but then not actually deployed).