At the start of a deployment, it is a good practice to conduct an initial compare between the DEV environment and PROD to make sure the development effort is starting with a good baseline. It is often the case that the customer has made data model changes directly to the PROD environment. These typically include changes to code sets, profiles, taxonomies and hierarchies. If the DEV environment is not first "refreshed" from PROD, there are two possible consequences:
- The development and testing will be invalidated when deployed to PROD, meaning the lack of those changes could result in different behavior when testing in DEV. This of course depends on the nature of the changes and the planned development. For example, code sets not directly associated with the development pose a lower risk than changes to a Profile that is being modified for the development.
- The deployment itself may risk a regression in PROD and undo those changes. For example, if a datatype of and attribute is changed in PROD and the same repository is updated on DEV as part of the development, the migration of the profile could result in the datatype being reverted back to the old datatype.
If the scope of the discrepancies between DEV and PROD are small, it may be quickest to simply make the same changes on DEV via the UI or import separate export files generated from PROD. The EnterWorks Migration tool should be used if there are many changes and in different areas. Similarly, changes to SQL objects (such as temp tables, stored procedures, or views) that are likely to be maintained by the customer should be checked and if altered, they should be extracted and the source version control for the project be updated so subsequent changes are based off the newer versions. The updated scripts should then be applied to the DEV environment to get it in sync with PROD.
If there is a QA environment, it too should be updated with the changes being made to DEV to match PROD. This ensures that when the deployment to QA is run, the outcome will match what will happen when the deployment is applied to PROD.
For the EnterWorks data model objects, configuration repositories, database objects, and EPX workflows, the compare extract SQL scripts should be used to identify the discrepancies between DEV and PROD. Most of the time it can be assumed that the values in PROD should be used to update DEV. However, sometimes the discrepancy reflects a change made to DEV that was not deployed to PROD. When there is doubt, it is best to first check with any Professional Services personnel who may have been involved with the project previously, then if needed, take the questionable discrepancies to the customer.
Once development for a deployment has begun, it is easy to focus on just making the changes and not keeping the deployment folder and document up-to-date. It is strongly recommended to maintain both the deployment folder and the document as development progresses. This reduces the burden when it is time to create the deployment package and increases the likelihood that all aspects of the deployment have been captured and are under source control.