This page describes how the Adeptia Migration Utility integrates with a DevOps tool, for example, Jenkins, to automate the export and import process for the migration of the objects from one environment to another, for example, development to production environment.
You can run the Migration utility in noninteractive mode, also referred to as silent migration, to perform export and deploy functions. You can run noninteractive migration both in Windows and Linux environment.
This page contains the following information:
Prerequisites
Before you start, ensure that you meet the following prerequisites:
- A DevOps tool such as Jenkins.
- DevOps tool having access to Adeptia Connect Server. However, it does not necessarily have to be on the same server.
- Adeptia Migration Utility.
Guidelines for migration
Below are some key guidelines which you need to account for when you are going to perform objects migration:
- Identify key stakeholders and their roles and responsibilities involved in migration/promotion tasks. Typical roles are Developers, QA, and Production Support.
- Most organizations have their own release management process and are adopting DevOps style processes. Adeptia recommends to include object/migration and promotion utility (Migration Utility) within their release management process as applicable.
- Migration utility can be effectively used in non-interactive mode with scripts to automate exporting and importing objects in different environments. However, on Linux Operating System, Adeptia supports only non-interactive migration/promotion.
- Before upgrading it is recommended to take a backup of objects from production environments for roll-back or recovery. It is important to maintain a separate repository for backup and latest copy of export zip file, preferably in a version controlled repository like TFS or GIT.
- Ensure while promoting objects the number of users allowed as per the license is adequate. For example, Development/QA environment may have different number of users allowed than Prod environment which can give rise to issues while executing transactions in production.
Key steps for migration
Below are some high level key steps to migrate the objects from development to production environment using automated scripts. You can refer to the illustration given below for detailed understanding of the migration flow.
- Admin creates a release directory in “DevOps Repository Manager”.
- Developer uploads the applicable export.xml file to the “DevOps Repository Manager” directory with a standard naming pattern.
- DevOps detects that there is an export.xml in that release directory and the automated scripts invoke silent migration utility to create export.zip file and import.xml in the same DevOps directory.
Developer reviews the export.zip to verify and ensure that no objects are missing. This is an optional step.
If export.zip is not created for any reason, an email is sent to developers along with the migration log.- On the day of staging in migration process, the automated script picks up export.zip and import.xml to move objects to staging environment.
- Upon successful testing in staging, the objects from DevOps are moved to production environment using the automated scripts.
The following image illustrates the process of migration objects from development to production environment using Jenkins (automated scripts):
