Best Known Method - Using Test to Live

Version 14

    Verified Product Versions

    LANDESK Service Desk 7.6LANDESK Service Desk 7.7.xLANDESK Service Desk 7.8.xLANDESK Service Desk 2016.xLANDESK Asset Central 2016.xLANDESK Service Desk 2017.x

    Introduction

    The purpose of this document is to cover the best known methods for using the LANDesk® Service Desk Test to Live tool when migrating a design from one environment, for example 'Test' to another, typically 'Production'.

     

    Scope

    This document is designed to provide an experienced LANDesk® Service Desk Administrator with the information they need to ensure that they can migrate a design successfully and with the minimum of system disruption. It should be used in conjunction with the latest version of LANDesk® Service Desk documentation.

     

    This document will cover:

    1. The data that is migrated by Test to Live.
    2. Planning/implementing your design migration.

    Assumptions

    This document assumes that:

    1. The reader is familiar with LANDesk® Service Desk and its over-arching concepts and use.
    2. There are two seperate instances of LANDesk® Service Desk; typically 'Test' and 'Production'.

     

    1. Data that is Migrated

    During the migration of your 'Test' environment into your 'Production' environment, all changes to the following items are

    migrated:

    • business objects
    • windows, views, and copy rules
    • templates
    • processes
    • system queries
    • shortcuts, including publishing details
    • system dashboards, including publishing details
    • system preferences
    • CI Exception Reporting configuration
    • MI configuration
    • Event Manager configuration
    • Data Import schedules
    • License information
    • other parts of your database schema that are not deliberately excluded, such as stored procedures

     

    The following rules are also applied when you migrate your Test system into your Live system:

    • attachment data (tps_attachment_data) is not migrated from test to live
    • groups and roles (and their associated privileges) in the live database are not changed or deleted when you use Test to Live – only new groups and roles that have been added to the test database are migrated to live
    • reference lists, ordered lists, and categories in the live database are not changed or deleted when you use Test to Live – only new items that have been added to the test database are migrated to live
    • agreements and response levels in the live database are not changed or deleted when you use Test to Live – only new agreements and response levels that have been added to the test database are migrated to live

     

    In addition, you can choose to migrate changes to the following items:

    • connections created in the Data Connections component
    • connections created in the Desktop Manager component
    • settings in the Mail component

     

    These changes are optional so that you can configure these components to connect to 'Test' systems, and then choose not to migrate these changes to your 'Production' environment. If, however, you have created a new data connection that you want to use in your 'Production' environment, you can choose to migrate it.

     

    Migrating Users

    It is best practice to avoid referencing specific users in your database design. For example, when designing a process that assigns a change to a change manager; use a 'Change Manager' support group rather than an individual analyst. Then add the relevant individual(s) to these groups. However, if you refer to specific users in your updates deisng, Test to Live will identify this and present two options:

     

    1. Add the new users to your 'Production' database as part of the migration.
    2. Update the references in your updated design to refer to an existing user in your 'Production' database.

     

     

    2. Planning/Implementing your Design Migration

    When using Test to Live to migrate design changes all design changes from your 'Test' environment are created in your 'Production' environment. As such, it is vital that the design changes you make are made to an exact copy of your 'Production' database. Do Not make changes in your 'Production' environment to data that is migrated by Test to Live.  For example, creating a new category; as Test to Live synchronizes this data, and as a result will delete or overwrite any changes that you have made in 'Production'.

     

    In addition, the 'Production' environment should not be available while the Test to Live application is migrating the design changes into the 'Production' environment.

     

    To ensure a successful migration between your 'Test' and 'Production' environments the following steps in the order shown should be followed:

     

    1. Stop any data imports that may be creating items such as groups, categories etc. on your 'Production' environment.
    2. Implement a complete change freeze on your 'Production' environment. The system can be continued to be used to raise and action incidents, for example.
    3. Backup your 'Production' database and restore it to your 'Test' environment.
    4. Make the required updates to your 'Test' environment and follow your documented User Acceptance Testing process.
    5. Backup your 'Production' environment database.
    6. Connect the Test to Live application to the two databases and migrate your design changes into the 'Production' environment. This is shown in the video link below.
    7. Follow any relevant testing procedures ensuring that the migration has been successful.
    8. Restart any data imports that you stopped in step one.
    9. Make your 'Production' environment available.
    10. Release the change freeze on your 'Production' environment.