- Print
- DarkLight
- PDF
Creating & Maintaining Releases
This topic is related to the following sections:
About Creating and Maintaining Releases
A project may have multiple release dates. Examples of project organization to support multiple releases include company codes, sites (country/region), SAP modules, business units or product lines. The business users define the release schedule based upon which objects and when deliverables are implemented in the user's production system.
View the Project Setup page by navigating to Migrate > Project Setup on the Syniti Migrate Homepage to launch the Project Setup multi-panel page. On the Project Setup multi-panel page, the Releases panel is in the upper right of the Project Setup page.
The list of active Releases that have been added are on the Releases panel. The panel displays the following:
Heading | Definition |
---|---|
Name | Name of the Release, Ex: Release 1 or R1. |
Description | Long name or description of release, Ex: Release 1 - US or R1 - Master Data |
Start | Project Release start date. |
End | Estimated Project Release end date. |
options | Click this icon to select option for Edit Metric Thresholds |
Remediation | Indicates remediation is enabled for the Release report execution. Typically, a Release should expect to remediate one half of the Milestones during the first half of the Project, and turn it off for the second half to avoid masking any readiness errors late in the Release. |
Active | Toggle for status of the Release for future-state design mapping and migration.
|
Prerequisites to Creating a Release
The prerequisite to this process is building the Project within Project Setup.
Add a Release
On the Releases panel, click the Add icon to create a new Release and launch the Add Release window. From this window, fields values are entered (see below).
Note
If the Working Database Server is not setup prior to adding a Release to the Project, this action fails. A validation check ensures that the project has a valid Working Database Server in place.
See below for field definitions for adding a Release:
Field | Definition |
---|---|
Project ID* | The associated Project defaults, but can be changed with a drop-down selection. (Required) |
ETL Tool* | ETL Tool used for conversion of migration data. (Required)
|
Release Name* | Name of the Release. (Required) |
Description | Long name or description of release. Ex: Release 1 - US or R 1 - Master Data |
Start Date | Project Release start date. (see Note below) |
End Date | Estimated Project Release end date. (see Note below) |
Remediation Enabled | Toggle to indicate remediation is enabled for the Release report execution.
|
Active | Toggle for status of the Release for future-state design mapping and migration.
|
Copy from Release | A new release can be copied from an existing release, allowing all the Datasets, Targets, Sources, Reports and Mappings to be rolled forward into the new release. See section Copy a Release below. |
Release Owner | The Owner who is responsible for the entire project release.
|
Note
At this point the date range for Start and End Dates should be set, each level depends upon the level above date range to select the current date range.
Security Tab
Click the Security tab to select a security profile.
Security Profiles in Migrate allow users to extend role-based security settings on an individual asset or component, such as Datasets, Datasources, and Releases. When a security profile is applied to an asset, only users associated with user groups and roles designated on the security profile have visibility or access to that asset. For example, if a security profile is applied to a release, then the subject areas, datasources, reports, mappings, ETL Jobs, Metrics, and all the granular details of a release are restricted from other users.
Refer to Security Profiles and Security Profiles in Migrate for more information on implementing and managing security profiles.
When finished with edits, click the Save icon to complete.
Edit a Release
On the Releases panel, click the Edit icon on the selected Release record to Edit the Release and launch the Edit Release window. At this point, there are two tabs in the Release Details window - Definition and Relevancy Attributes. Definitions are the fields setup during the initial create process, while Relevancy Attributes are a list of relevancy fields for setting relevancy limits to the master data objects.
Release Level Relevancy Attributes
These fields are configurable and setup within Administer > Advanced > Relevancy Attributes section of the system. There are over twenty default relevancy fields that are delivered with the system, and they may be configured to add or delete as needed.
Note
The link Configure Relevancy Attributes opens the Administer > Advanced > Relevancy Attributes page.
When finished with edits, click the Save icon to complete.
The field values within Relevancy Attributes tab are stored in the MIG_RELEASE_RELEVANCY table in SRCCONSTRUCT database as a snapshot managed table in the Application Database and may be used in the ETL Rules. These values are refreshed using Snapshot Management Repopulation.
Refer to section Add a CONSTRUCT Snapshot Datasource for details.
Copy a Release
Within the same Project and Release, a new Release may be built and then updated with Subject Areas to match those in an existing Release of same Project. From this base, the New Release can then copy from the existing release the Subject Area details including Milestones. Within Mappings, this new releaseautomatically builds out the Subject Areas, Datasets, Targets, and Sources, with all mappings entered but marked as NEW.
Prerequisite to Copy a Release
This copy feature works successfully for situations where the following prerequisites have been completed:
The new Release is manually created by user within same Project as the Copy from Release.
New Deployments need to be added manually to the new Release as they all must be unique to the system.
The new Subject Area(s) is manually created with active Working Datasource ID and Working Datastore within same Project as the Copy from Release.
The new Subject Area already exists within the Copy From Release.
Note
Should the user add Subject Areas that are not stored in the Copy From Release, these are also extended out to the Mappings, but without the Datasets, Targets, and Sources. The user must manually import and set these up. Therefore, it may be best to copy first and then add any additional new subject areas.
This process works well when the project is migrating data within two or more releases for the same Dataset. In the image below, Release Rel2 DS is copied to add data to Subject Area = Master Addresses within a new Release to be built for Rel3.
Refer to section Migrate > Copy a Release for detailed instruction on this process and how it affects Project Setup and Mappings
Delete a Release
As with most sections of this application, the deletion process is allowed after a Release is created as long as there are no downstream processes associated to this Release. If the Release and Subject Area were included in a Mapping, then it cannot be deleted.
Option to Edit Metric Thresholds for Milestones
Within the panel for Releases, there is a column for options. This icon provides access to set the metric threshold values for the release.
Click the options icon to maintain the Metric Thresholds for Milestones.
Refer to section Edit Metric Thresholds for a Milestone within Administer > Metric Configuration for details of this update.
Subsequent Steps
The subsequent steps of this process are to build: