GOLIVE moves the configuration from one instance to the next: it is built in development, validated in testing, then goes to production. The move is always pulled by the receiving instance (the target): testing reads the development configuration, production reads the testing one. The instance that provides the configuration (the source) only lets itself be read; it never writes to the target.
What the source lets the target read
The source exposes, read-only:
- the catalog of the configuration items it can provide, module by module;
- the dependencies of a selection: choosing an item brings along what it needs to work;
- the package of the selection, which the target then applies on its side.
Never leave the source: accounts, groups and their members, rights, secret values, business data that was not selected, or anything specific to the instance (server addresses, connection accounts, licenses, agents). An item that needs one of them only names what it expects (for example a group code), and the target finds it on its side.
What the source offers
- scripts (ScriptRunner);
- forms (published version);
- processes (published version);
- catalog categories, items and services;
- ticket settings (Service Desk): value lists, categories, transitions, priority matrix, SLA calendars and policies, custom fields, variables, macros, automation rules, tags, escalation policies, OLA targets, correspondence templates, shared views and queries;
- the configuration settings meant to move from one instance to another, email and notification templates, custom translations and languages;
- queries, menus, shared dashboards, redirects and showcase pages.
- scheduled jobs (triggers and cron) and job blackout windows.
- CMDB object types, relation types and records, and the field mappings of GLPI sources.
- change types and freeze periods, the release checklist template and target instances, monitoring rules and maintenance windows, organization relationship types.
- knowledge bases, their categories and tags, and articles with their attachments.
- AD synchronization rules (without their connection), Microsoft 365 sources and group mappings, and mailbox filters.
Selecting a service brings everything it needs: its category, its items, its forms, its processes and the scripts those processes run. Selecting an automation rule brings what it uses (statuses, categories, fields, variables…). An agent's personal views and queries stay in the source. A module not covered by the instance's license offers nothing.
A promoted element keeps the same identifier in the target as in the source. An element already created by hand on both sides is matched by its code or name, and the preview says so.
Give the target access
- On the source, signed in with an administrator account, open My profile › API keys and create a key with GOLIVE read key ticked. Name it after the target instance (for example "GOLIVE to testing").
- Copy the key: it is shown only once.
- Hand it to the target instance, which stores it in its secrets.
This key only reads the catalog and the packages: any other request made with it is refused. Revoke it as soon as the target no longer needs it.
All of this can also be done through the API, without any screen (this is how the Portal links a customer's environments): creating and revoking the key on the source, declaring and testing the source on the target, preview, application and history. The key is created from a password sign-in: an API key cannot create another one.