Content |
|||||||||||||
|
Introduction |
|
|
|
CMT Overview |
The Configuration Management Transfer tool (CMT) offers Build Managers and System Configurators the ability to collaborate when making configuration changes, in a controlled environment. Configuration changes typically include changes to configuration properties or master data. These changes might be the result of implementing a new feature, or applying a fix. Once changes are complete, a transfer package can be created allowing a group transfer to another system. CMT can be established as the transfer tool (with or without Change Control) for all Export/Import operations providing flexibility when transferring data from one system to another.
CMT consists of two major components:
An environment under Change Control will require that any changes made to a controlled SDC are associated with an individual or Department. Each time an SDI is added, edited, or deleted the Change Control process is initiated and changes are tracked.
As changes are made, the system tracks and collects the details of each change. Changes can be grouped together to create a "transfer package". CMT Transfer is highly configurable allowing for control over what is included in each transfer and flexibility during import.
Following is a high level diagram that illustrates how you might associate a group of changes with a Change Request, then use the Change Request to initiate transfer of those changes to another system.
High Level Definitions |
The following terminology is used throughout this document:
| Term | Description |
| Change Request | Change Requests are used to detail the changes to be made as well as identify who is responsible for making the changes. A set of changes can be grouped under a Change Request then easily transferred to another system. |
| Check Out | Before any changes can be made, an SDI must be checked out. At checkout, assign a User or Department to the change(s) and specify a Change Request. While checked out, the SDI is unavailable to Users not eligible to make changes. |
| Change Log | At the time of Check Out, a Change Log event is generated. Changes are tracked within that Change Log (for the SDI) until checked back in. |
| SDI Snapshot | SDI Snapshots are a "logical" representation of an SDI, at a given time during the change control process. SDIs might be simple, containing only primary details (such as a Parameter), or complex, containing references and links to many additional SDIs (such as Studies or Schedule Plans). SDI Snapshots are built (using CMT Policy) to reflect the logical content of an SDI.
An initial SDI Snapshot is generated at Check Out to preserve the state of the SDI (before any changes are made) and stored within the Change Log. At any point within the change control process the initial SDI Snapshot can be compared to the current configuration (after changes have been made). A final SDI Snapshot is taken at Check In to reflect the final changes. |
| Check In | Check In the SDI when changes are complete. A final (after image) SDI Snapshot is generated and added to the Change Log. The SDI is made available to other Users. |
| Transfer Package | A Transfer Package is a collection of SDI Snapshots. The Transfer Package may include a collection of SDI Snapshots associated with one or more Change Log(s), a Change Request, or an SDI Snapshot built for an SDI Export.
Choose to perform a "Minimum" transfer (includes only the SDI Snapshot), or a "Full" transfer (includes the SDI Snapshot and any additionally defined data to be included in the SDI Snapshot). |
CMT Configuration |
CMT configuration involves SDC definition and CMT Policy configuration. OOB, certain SDCs (such as those that represent instance data) are not typically included in Change Control, while changes to configuration or Master Data are. With this in mind, options have been pre-defined for each SDC.
A given SDI contains information stored in various tables defined within LabVantage. To configure the information included in the logical SDI Snapshot, the data within these tables have been determined (OOB for each SDC) to be either:
| • | Embedded within an SDI and are therefore always included in SDI Snapshots and transfer. |
| • | Optionally added (as defined by the CMT Policy definition) and included in the SDI Snapshot and transfer. |
| • | Included only when performing a Full Transfer. |
The following table details the approach taken to configure SDCs accordingly.
| Table | Example | Included in the SDI Snapshot | Included in the Transfer |
| Primary | These are the primary details of the SDI. Examples include Keyids, Descriptions. | Always | Always |
| Embedded SDCs | These SDCs are determined by LabVantage to be an embedded part of the logical SDI and are always included in the SDI Snapshot.
An example would be embedded Specifications, or Sampling Plans on a Product. |
Always | Always |
| Detail Tables | These are SDIs associated or linked to the primary SDI.
This includes:
Detail Tables These are the detail tables (or one side of the many to many tables) defined in the SDC definition (Tables detail). For example, the paramlistitem would be included with the ParamList SDI Snapshot. Reverse FK Child SDIs (acting as Details tables) These are the detail SDIs that have a Foreign key relationship back to the parent SDI. For example, the QCMethodSampleType that is included with the QC Method SDI Snapshot. |
For most SDCs, always included. However in come cases, detail tables may be excluded. Which child tables are included in the SDI Snapshot is determined by the CMT Policy. |
When included in the SDI Snapshot |
| SDIxxx Detail Tables | These are a collection of detail tables that can be associated with any SDI. Some examples are Attachments (sdiattachment) or Approval Types (sdiapproval). | Configured in the CMT Policy. Included when defined. | When included in the SDI Snapshot |
| Additional SDIs | These are standalone SDIs that you might want to associate with the primary SDI.
For example, you might want to include the SchedulePlan and SchedulePlanItems with the Stability Protocol. |
Configured in the CMT Policy. Included when defined. | When included in the SDI Snapshot |
OOB each SDC is configured to include what would be considered typical content and transfer options for that SDC. Should you want to include additional information or exclude certain information you can do so by further configuring the CMT Policy. See Configuring CMT for more information.
Identify and Define a CMT Administrator |
Consider identifying an individual or individuals as a CMT Administrator ("CMT Admin" Role). The CMT Administrator has the authority to Check In any SDIs that have been checked out by any other User. This ensures that if the individual who checked out an SDI is unavailable, someone within the organization will be able to check it back in. See CMT Policy, Global - CMT Administrator Role for more information.
Identify and Define Development Teams |
When Change Control is enabled, changes are associated with an individual or a Department. Choosing to associate changes with a Department allows multiple Users to collaborate when making changes to the same group of SDIs, over a period of time. This team can work simultaneously, globally,
To differentiate a group of individuals responsible for making changes in a change controlled environment from a typical LabVantage Department, create a Department with the "Development Group" designation. Departments with this designation are for CMT purposes only. These Departments are excluded from use by Department Security.
To create a development group, add a Department and check the "Development Group" option. When checking an SDI out to a Department, the list of available Departments is restricted to those with the "Development Group" option checked.
Define a Remote Change Control Server (Master Repository) |
|
|
CMT provides an option to remotely Check Out, Check In and transfer directly from a remote server. You can also view comparison SDI Snapshots between the local system and remote server. See Remote Server (Master Repository for more information.
