Dossiers par statégie d'état

Au démarrage d’un projet, il faut pouvoir organiser tous les scénarios d’automatisation qui vont être développés. Cette organisation va suivre une stratégie d’état (state) comparable à ce que l’on peut retrouver sur des outils de versioning.

Stratégie des états (states) par dossier

Dans la méthodologie, chaque dossier correspond à un état du scénario (state).

6 états de scénarios sont à concevoir en amont sur une organisation par dossier.

Les 6 états sont les suivants (l’ordre est alphabétique, mais ne reflète pas un ordre d’importance) :

1. Archived
2. Backup
3. Dev
4. Prod
5. Sandbox
6. Staging

Faire des dossiers séparés permet de visuellement mettre en exergue les états des différents scénarios.

Ce qui est important ici, c’est l’organisation des différentes versions et les états des scénarios pour pouvoir agir dessus et les faire évoluer.

On veut éviter de devoir faire une modification sur un scénario actuellement en PROD et qui fonctionne sans avoir au préalable testé ce scénario.

Il évite, par exemple, d’avoir des scénarios en PROD qui soient intégrés dans différents dossiers.

En fonction des outils, cela permet également de donner des droits par dossier aux responsables des automatisations en fonction de la criticité de leurs états.

Convention de nommage

TIP

STATE : PROD

• Les noms doivent être en UPPERCASE.
• Ils ne doivent pas contenir d’accents, de caractères spéciaux, émoticones.
• La langue officielle est l’anglais.

States - Description détaillée

Dans la méthodologie, nous avons identifié 6 états de scénarios qui vont vous permettre de gérer leur cycle de vie et d’envisager une montée en charge de vos scénarios ainsi qu’une collaboration.

Pour une bonne organisation par dossier, il convient de créer en amont les différents dossiers avant de démarrer la construction des scénarios. Cela vous permettra ensuite plus facilement de ranger un nouveau scénario dans son dossier.

Un scénario doit absolument être rangé dans un dossier et/ou identifié par son state.

Aucun dossier n’est optionnel, vous devez tous les créer en amont. Toutefois, et d’un point de vue pratique, il s’avère que les dossiers DEV et PROD sont les plus critiques dans l’organisation de vos scénarios.

Vos scénarios vont suivre un cycle de vie qui sera bien souvent le même. Voici l’ordre de leur cycle de vie.

1. Sandbox
2. Developpement
3. Staging
4. Production
5. Backup
6. Archived

Sandbox

Le dossier _SANDBOX possède des scénarios dont l’objectif est de réaliser des tests en amont, des MVP (Minimal Viable Product) afin de pouvoir aller rapidement tester si les scénarios sont possibles et/ou crée de la valeur. Cela va permettre également d’être un terrain de jeu pour le test lors de la sortie de nouveaux modules et d’actions à intégrer dans de nouveaux scénarios. Dans tous ces scénarios, certains seront ensuite amenés en DEV puis en PROD, d’autres ne sortiront jamais de ce dossier. Si des scénarios ne sont plus pertinents, vous pouvez les supprimer. Aucun de ces scénarios ne doit se retrouver dans le dossier BACKUP ou ARCHIVED s’ils n’ont pas été au préalable en PROD.

INFO

le dossier _SANDBOX est identifié par un underscore _. Cet underscore signifie dans ce contexte la présence de scénarios non critiques dans le cycle de vie des différentes automatisations.

Developpement

Un scénario qui passe en DEV est un scénario validé par l’équipe ou le client comme étant un scénario qui sera mis en PROD. Lors de toute la phase de construction du scénario et des différents tests de ce dernier, le scénario sera géré à part entière sur ce dossier avant d’être déplacé en PROD. Toutes les variables, connexions, webhooks… des scénarios de DEV seront également des versions de DEV. Dans ce dossier, il n’y a qu’une seule version du scénario en DEV. À partir du moment où il passe en PROD, il doit disparaître dossier DEV. Si vous avez besoin de refaire une nouvelle version de DEV pour itérer ou régler un bug, il faut alors cloner le scénario de PROD et le remettre dans le dossier DEV (avec le bon titre de version) — en n’oubliant pas de remettre des variables de DEV. Avant de passer en PROD, un scénario de DEV peut passer dans le dossier STAGING.

Staging

Le dossier STAGING est un dossier qui se situe entre le dossier DEV et PROD dans le cycle de vie d’une automatisation. Dans les faits, le STAGING est peu utilisé. Il n’a de sens que lors d’une validation du scénario de DEV. Cela peut être le cas :

• Si vous souhaitez travailler en peer programming avec un collaborateur qui va valider et tester votre scénario ;
• Si une personne dans votre équipe est en charge de valider l’ensemble des scénarios avant la mise en PROD. Lorsque le scénario en STAGING est validé, il convient de le passer en PROD.

Prodcution

Dans le dossier PROD, il n’y a que les scénarios qui sont live.

En règle générale, il n’y a qu’une seule version d’un même scénario en PROD.

Toutefois, dans certains cas, vous pouvez imaginer avoir des scénarios en PROD qui ont des versions différentes. Voici les cas d’usages :

• Vous souhaitez mesurer la performance de deux scénarios sur la même fonctionnalité et donc avoir des datas pour comparer dans un temps définit pour définir in fine le meilleur scénario pour votre cas d’usage ;
• Un module présent dans le scénario a été mis à jour sur une nouvelle version de son API et certains des outils que vous avez mis en place sont reliés à l’ancienne version de l’API. Par conséquent, vous avez deux mêmes scénarios avec des versions d’APIs différentes dans un souci de compatibilité de votre parc logiciel.

Backup

Ce dossier contient la dernière version du scénario poussée en PROD et qui vient d’être remplacée par une version antérieure. Le dossier BACKUP ne contient seulement que la dernière version de PROD. Les autres versions antérieures sont déplacées dans le dossier ARCHIVED. L’objectif de ce dossier BACKUP est de pouvoir retrouver rapidement la dernière version d’un scénario de PROD pour potentiellement le repousser en PROD dans le cas où un scénario actuellement en PROD rencontrerait trop de difficultés ou d’erreurs qui nuisent à son fonctionnement.

Archived

Le dossier _ARCHIVED contient seulement les versions de PROD antérieures. La bonne pratique voudrait que l’on garde uniquement les deux dernières versions d’un scénario. Les versions en dessous peuvent être considérées comme non pertinentes à garder ici et il convient donc de les supprimer pour une meilleure lisibilité et éviter de surcharger le dossier. Si vous souhaitez le faire, avant de supprimer un scénario du dossier _ARCHIVED, il est important de faire un backup du blueprint et de le stocker soit sur un repository ou un Drive.

INFO

le dossier _ARCHIVED est identifié par un underscore _. Cet underscore signifie dans ce contexte la présence de scénarios non critiques dans le cycle de vie des différentes automatisations.

FAQ

Pourquoi ne pas mettre le nom de l’entreprise / organisation dans le dossier ?

Le nom de l’entreprise / organisation est déjà inclut de base sur votre projet (aka votre compte). Il est donc sous-entendu. Il n’y a pas besoin de le répéter.

Pourquoi ne pas ajouter le nom de l’entité / équipe en charge dans le dossier ?

En fonction de la complexité et du nombre de scénario, il sera utile de mettre le nom de la business unit / équipe / entité à qui est destiné le scénario dans le titre du scénario. Pour rappel, la stratégie de dossier a pour objectif de représenter le cycle de vie d’un scénario. Par conséquent, par exemple, il est important de ne pas avoir 2 dossiers PROD (ex. PROD_MARKETING et PROD_COMMUNICATION)

Peut-on ajouter une date pour différencier ?

Les dates ne sont pas indiquées à ce niveau-là. Les dossiers ont pour vocation d’exprimer un state du scénario.