Using noninteractive migration with DevOps
- Akash Kumar Jaiswal (Unlicensed)
This page describes how the Adeptia Connect 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 the 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 environments.
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 Connect 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 the 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 the latest copy of the 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, the Development/QA environment may have different number of users allowed than the Production 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 a 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.
It is recommended that you set up an email notification in Jenkins to receive an email in case of success or failure of a deployment.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 the migration process, the automated script picks up export.zip and import.xml to move objects to the staging environment.
- Upon successful testing in staging, the objects from DevOps are moved to the production environment using the automated scripts.
The following image illustrates the process of migration objects from development to production environment using Jenkins (automated scripts):
