Introduction:
This article is concerning the planning and preparation of a Vault configuration migration deployment.
Keeping track of configuration changes in a Development Sandbox
Use the Vault Compare report to automatically generate a list of components that have a different configuration than the target Vault or are missing from the target Vault. This report allows the review of components and their differences to determine which ones are needed to include in an outbound package.
Keep a log of the component types and names that are being modified in the Sandbox Vault as this helps with analyzing the compare report and resolving any cross-project dependencies.
Review the Vault Compare report for differences and missing target components. Review the component names and differences and isolate the components to be migrated. In shared development Sandbox environments, it is necessary to discuss differences with other project team members.
When generating a Vault Compare report, there may be some expected differences that can be ignored:
- Order attribute differences for Object fields: These attribute values do not impact the behavior of the Vault
- Differences referencing users: Since users are generally not the same between Vaults these values can be ignored when analyzing the report
- Domain differences: Values representing domain level or Vault information such as Vault names and URLs are expected to be different between Vaults
Reference: Using Vault Compare Report
The Vault object Vault Components (vault_component__v) acts as the Component Directory and keeps track of all components in the Vault that are available to migrate. The Component Modified Date (component_modified_date__sys) field in this object represents the date the component is last modified by an admin making configuration changes. This field can be used to determine which components are needed to migrate based on when they were modified. This field can be seen in the list of available components to add to the outbound package or by making this object available in business admin. Veeva does not track which user modified the component so it is necessary to review the component configuration details to understand if it needs to be migrated.
Maintain a deployment checklist
Maintaining a detailed deployment checklist that has step-by-step instructions for a Production deployment is critical. This is because these steps can be a combination of manual steps such as enabling a feature setting or turning on configuration mode as well as steps that are automated by tools such as package deployment. Writing down these steps, keeping them updated, and following them precisely can make the deployments proceed much smoother.
Creating the outbound package from a Development Sandbox Vault
Migrating from a shared Development Sandbox Vault:
In a shared Development Sandbox Vault, multiple project teams may be making configuration changes in the same Vault. Keeping track of all changes. Use the Vault Compare report to manually add the components to the outbound package to help isolate changes and ensure that the right components are migrated for the project’s deployment.
When the list of components to migrate is determined, include them in an outbound package. When the outbound package is created, include all the components to migrate in a single package. This allows Vault to automatically set the correct deployment order of the package’s components there is no worry about deployment sequence. The Vault-generated deployment order also factors in the interdependencies between components and component types to ensure dependent components are deployed in the correct sequence.
Migrating from a controlled Development Sandbox Vault
When migrating from a more controlled Sandbox (the user is the only person making changes in the Sandbox Vault) and migrating all the changes made, generate a Vault Compare report. Be sure to click on the option for Generate Outbound Packages. This automatically creates outbound packages with all components that have a different configuration from the target Vault and automates the package creation process. Review the contents of the outbound package to ensure its accuracy as there may be some expected differences from the report included in the package that need to be removed because they are not needed for the deployment. Remove all components that do not need to be migrated.
References:
Include all dependent components
Be sure each outbound package contains all interdependent components that do not exist in the target Vault and can block the deployment or cause your deployment to fail. Add dependent components to the outbound package by accessing the view. Add dependencies action in the action menu. Specify the target Vault for the outbound package as this will filter out any dependencies that already exist in the target Vault.
If the configuration has dependencies on data records such as application roles, groups, or Vault template object record data, migrate those data records into the target Vault prior to deploying the component updates. This can be done by adding those objects records to the outbound package through the data set configuration section.
Migrating data and configuration in a deployment
Migration outbound packages can include data from the source Vault as well as components. Project requirements likely include new or updated object records in the sandbox Vault that support the needed configuration. Or, the configuration depends on such as Application Roles, Groups, or template object data. Including this data in the outbound package as datasets helps automate more of the deployment tasks and reduces the risk of component deployment errors to due missing dependencies. It may be necessary to re-order deployment steps after the inbound package is imported to ensure that data steps are ordered prior to component deployment steps when data dependencies exist.
Reference: About Datasets
The deployment may also require updates to data in the target Vault to enable incoming configuration changes.
Example: Remove data from an object field prior to removing the field in the updated configuration. This requires Vault Loader steps in the deployment checklist to extract data from the target Vault, update the CSV file, and load the data back in.
Reference: About Vault Loader
Limit outbound packages to 200 components
Outbound packages are limited to 200 components. If the deployments contain more than 200 components, create separate outbound packages for picklists, reports, dashboards, security profiles, and page layouts. These components are often the most numerous and have fewer dependencies. Components or data that is not changed and is the same as the target Vault should not be included in the outbound package.
Validate outbound packages before production deployments
Deployments cannot be rolled back and all successful changes are committed to the Vault. To reduce the risk of the Production deployment, perform a test or dry run deployment of the outbound packages to view the success or failure messages that occur with an actual Production deployment. This helps validate the deployment process. The dry run Vault should be refreshed prior to validation.
Plan deployments around the Vault release schedule
Plan the deployment activities around the Vault release schedule for both the Production and Sandbox Vaults. Be sure that Sandboxes are refreshed, designed, configured, tested, and deployed without the added risk of a simultaneous Veeva-introduced update.
Delete or rename components using the Web interface
Outbound packages cannot be used to delete or rename components. To delete components, use the Web interface. To rename a component, do the following:
- Delete the component on the target Vault.
- Deploy the new component in an outbound package.
Document the deployment
Use Vault Compare and Configuration Reports to document and validate the configuration state of the Vault before and after the deployment.
References:
There may be some expected differences in the Vault Compare report that do not have any impact on the deployment or the Vault and can be ignored:
- Order attribute differences for Object fields: These attribute values do not impact the behavior of the Vault
- Differences referencing users: Since users are generally not the same between Vaults. These values can be ignored when analyzing the report.
- Domain differences: Values representing domain level or Vault information such as Vault names and URLs are expected to be different between Vaults
Maintain deployment documentation in a Project Vault or PMO Vault. This is important for change management and in the Project or PMO Vault include the:
- Planning documentation
- Deployment checklist
- Your VPK files
- Validation documentation such as test scripts
- Vault Compare and configuration reports
Related Documentation:
Send us your feedback: We're always looking for feedback to help improve our Knowledge Base! Please let us know if this article was helpful or provide feedback on how we can improve your experience here.