Le multi-instance
Pourquoi utiliser plusieurs environnements Iterop ?
Travailler sur plusieurs instances permet de réduire les risques lors du développement de processus sur une instance de production. Voici quelques exemples des aléas que cette méthode permet d’éviter :
- Rendre une instance indisponible à cause d’une erreur de développement
- Avec un environnement de qualification ou de préproduction, les boucles infinies ou autres erreurs ne paralysent plus l’instance de production.
- Mettre à jour des données directement sur la production
- Une erreur dans un ID de liste ou de référentiel métier dans un script est vite arrivé.
- Avoir recours à des artifices de développement
- Commenter des blocs de script pour éviter d’actualiser les données de production, c’est risquer d’oublier de les supprimer après les tests.
- Avoir des données de tests sur une instance de production
- et surtout d’oublier de les supprimer pour ne pas fausser les KPI.
Qu’est-ce que le multi-instance ?
Le multi-Instance consiste à utiliser 2 ou 3 instances au lieu d’une seule pour réduire les risques cités plus haut. Pour cela, il faut disposer d’au moins deux instances et potentiellement intercaler une autre instance pour profiter d’un espace de validation des développements.
Les instances sont reparties comme ceci :
- Développement
- Recette
- Production
| Développement | Recette | Production |
|---|---|---|
| Nouveaux processus ET amélioration d’anciens processus | Validation des développements | Marche courante des processus |
| Données de tests | ISO PRODUCTION sauf services | données de production |
Développement
Cette instance est un espace réservé au développement des nouveaux processus et à l’évolution des anciens. Les données (listes, tables et référentiels) sont factices. Elles sont généralement remplies de fausses lignes écrites arbitrairement ou non par les testeurs.
Tous les processus sur cette instance sont au moins autant avancés que leurs homologues de production.
Recette
L’instance de Recette est l’endroit sur laquelle les futurs usagers peuvent tester les nouveaux processus avec des données réelles, sans risquer de perturber aucun autre outil ou utilisateur.
Il est possible de ne pas posséder cette instance, surtout depuis la nouvelle fonctionnalité du mode Test qui permet justement de recréer ces conditions.
Dans cette instance prévue pour le test, les services doivent être des services vitrines pour ne pas risquer de mettre à jour des données en dehors de l’application ou d’envoyer des mails de tests. Aussi, un nombre réduit d’utilisateurs est préférable (généralement uniquement les testeurs des processus qui sont en train d’évoluer).
Production
L’instance de Production est l’instance sur laquelle les authentiques utilisateurs exploitent les véritables processus, avec de vraies données. Elle est l’instance qui ne doit en aucun cas être altérée.
Il est préférable de n’utiliser l’onglet « Design » de l’instance de production qu’en dernier recours. En cas de bug urgent, il faudra effectuer le correctif sur les autres instances.
Configuration et mise en production
Configuration
Afin de faciliter la mise en production, il est recommandé d’appliquer l’une de ces règles :
- Les objets (listes, tables et refs) portent les mêmes noms et IDs sur toutes les instances (difficile à assurer)
- Les objets ont les mêmes noms sur toutes les instances et les IDs seront déterminées grâce aux méthodes JUEL.(ex. : getIdByName)
- Les objets sont stockés dans un référentiel : Nom de l’objet => IDs. Dans ce cas, tous les scripts font un getParam pour récupérer l’ID de l’objet sur cette instance.
Dans tous les cas, il est préférable de privilégier les affectations par variable et groupe à celles par utilisateur.
Mise en production
Le multi-instance dissocie les instances de production et de test, il est donc nécessaire de préparer un protocole de migration et de monitorer cette même migration.
Vous devez préparer un protocole de migration sur les éléments suivants :
- Services
- Groupes
- Listes
- Tables de dépendance
- Référentiels métier
- Processus
- des sous-processus aux macros processus
Si un processus s’appelle lui-même il faut l’importer deux fois pour assurer le mapping.
Pour effectuer la mise en production, il est préférable de :
- Privilégier l’API pour les structures
- N’avoir aucun warning lors de l’import de processus
- Valider l’import grâce au mode test en faisant attention aux scripts, services et sous-processus
À la suite de la migration, vous devez :
- Attendre que le processus soit lancé en conditions réelles par les utilisateurs.
- Vérifier qu’il n’y a pas d’erreurs.
- Faire un suivi en détail des premières instances.
Lors de la migration, il existe 2 cas particuliers auxquels il est important de prêter attention :
- En cas de modification d’une opération ou un changement sur un service vous devez :
- Dupliquer l’opération avant de la modifier afin qu’elle soit toujours accessible en version précédente pour les processus en cours.
- Faire les corrections sur l’opération doublée.
- Changer le mapping pour que les processus importés fassent appel à la nouvelle opération.
- Attendre que les processus lancés avant la mise en production soient terminés puis supprimer l’ancienne opération.
- Sur une évolution dans le start d’un sous-processus ou si des processus parents sont encore en cours vous devez :
- Mettre un script juste après le start pour y écrire une règle métier de déduction du champ modifié à partir des données des champs non modifiés.
