Le GOLIVE fait passer le paramétrage d'une instance à la suivante : il se construit en développement, se valide en recette, puis part en production. Le passage est toujours tiré par l'instance qui reçoit (la cible) : la recette lit le paramétrage du développement, la production lit celui de la recette. L'instance qui fournit le paramétrage (la source) ne fait que se laisser lire ; elle n'écrit jamais chez la cible.
Ce que la source laisse lire
La source expose, en lecture seule :
- le catalogue des éléments de paramétrage qu'elle peut fournir, module par module ;
- les dépendances d'une sélection : choisir un élément entraîne ce dont il a besoin pour fonctionner ;
- le paquet de la sélection, que la cible applique ensuite chez elle.
Ne sortent jamais de la source : les comptes, les groupes et leurs membres, les droits, la valeur des secrets, les données métier qui n'ont pas été sélectionnées, ni ce qui est propre à l'instance (adresses de serveurs, comptes de connexion, licences, agents). Un élément qui en a besoin désigne seulement ce qu'il attend (par exemple le code d'un groupe), et la cible le retrouve chez elle.
Ce que la source propose
- les scripts (ScriptRunner) ;
- les formulaires (version publiée) ;
- les processus (version publiée) ;
- les catégories, articles et services du catalogue ;
- le paramétrage des tickets (Service Desk) : listes de valeurs, catégories, transitions, matrice de priorité, calendriers et politiques SLA, champs personnalisés, variables, macros, règles d'automatisation, étiquettes, politiques d'escalade, objectifs OLA, modèles de correspondance, vues et requêtes partagées ;
- les réglages de configuration prévus pour passer d'une instance à l'autre, les modèles de courriel et de notification, les traductions personnalisées et les langues ;
- les requêtes, les menus, les tableaux de bord partagés, les redirections et les pages vitrine.
- les tâches planifiées (déclencheurs et cron) et les fenêtres d'exclusion des tâches.
- les types d'objet, types de relation et fiches de la CMDB, et les correspondances de champs des sources GLPI.
- les types de changement et périodes de gel, le modèle de checklist et les instances cibles de mise en production, les règles de supervision et fenêtres de maintenance, les types de rattachement d'organisation.
- les bases de connaissances, leurs catégories et étiquettes, et les articles avec leurs pièces jointes.
- les règles de synchronisation AD (sans leur connexion), les sources et correspondances de groupes Microsoft 365, et les filtres des boîtes mail.
Choisir un service emporte tout ce dont il a besoin : sa catégorie, ses articles, ses formulaires, ses processus et les scripts de ces processus. Choisir une règle d'automatisation emporte ce qu'elle utilise (statuts, catégories, champs, variables…). Les vues et requêtes personnelles d'un agent restent dans la source. Un module qui n'est pas couvert par la licence de l'instance ne propose rien.
Un élément promu garde dans la cible le même identifiant que dans la source. Un élément déjà créé à la main des deux côtés est retrouvé par son code ou son nom, et l'aperçu le signale.
Donner l'accès à la cible
- Sur la source, connecté avec un compte administrateur, ouvrez Mon profil › Clés API et créez une clé en cochant Clé de lecture GOLIVE. Nommez-la d'après l'instance cible (par exemple « GOLIVE vers la recette »).
- Copiez la clé : elle ne s'affiche qu'une fois.
- Confiez-la à l'instance cible, qui la range dans ses secrets.
Cette clé ne sert qu'à lire le catalogue et les paquets : toute autre demande faite avec elle est refusée. Révoquez-la dès que la cible n'en a plus besoin.
Tout cela se fait aussi par l'API, sans écran (c'est ainsi que le Portail relie les environnements d'un client) : création et révocation de la clé sur la source, déclaration et test de la source sur la cible, aperçu, application et historique. La clé se crée depuis une connexion par mot de passe : une clé d'API ne peut pas en créer une autre.