Section Équipe

L’endroit dans lequel l’équipe puise son environnement. Au lieu de se passer un fichier par messagerie — ce que fait partager un scénario —, le scénario vit dans un catalogue et chacun l’adopte quand il en a besoin.

La section n’apparaît que si un catalogue est configuré. Si vous ne voyez pas « Équipe » dans la barre latérale, il ne manque rien à votre installation : ce projet n’a pas de catalogue, et il se configure dans aseptic.project.yml.

Ce que l’on voit

La liste de ce que l’équipe partage. En sélectionnant une entrée, le détail répond aux deux questions que l’on se pose avant d’adopter quoi que ce soit :

• Ce qu’il apporte — combien de services, combien de mocks et combien de réglages de démarrage. S’il n’apporte que la définition du scénario, c’est dit aussi.
• Ce qui manque ici — ce dont ce scénario a besoin et que votre machine n’a pas encore : une connexion de base de données référencée par le paquet, un identifiant sans valeur, un dépôt absent de votre espace de travail, ou un micro enregistré sur une autre branche.

Cette seconde liste est la raison d’être du détail. Adopter à l’aveugle et découvrir le manque quand le scénario refuse de démarrer, c’est exactement le temps que cela fait gagner.

Adopter

Adopter ramène le scénario et le réconcilie avec votre catalogue sans l’écraser : c’est le même chemin que l’import d’un fichier, avec les mêmes politiques de conflit.

Quand il manque quelque chose, le détail le dit avec son remède à côté : quel identifiant définir, quel dépôt reste à cloner, sur quelle branche chaque service a été enregistré. Et si vous préférez régler cela plus tard, vous pouvez adopter quand même : le scénario arrive dans votre catalogue et ne démarrera pas tant que le manque n’est pas comblé, ce qui vaut mieux que de ne pas pouvoir le récupérer.

Si l’équipe le change

Adopter laisse un fil : le scénario est annoté avec l’entrée dont il provient et avec la version exacte qui a été rapportée. C’est ce qui permet à l’application de dire ensuite quelque chose qu’elle ne pouvait pas dire avant : ce n’est plus ce que partage l’équipe.

Dans la liste, chaque entrée porte son état :

• À jour — ce qui est ici correspond à ce que publie l’équipe.
• A changé — quelqu’un l’a republié après son adoption.
• (sans marque) — il n’a pas encore été rapporté sur cette machine.

Les entrées sans marque sont la majorité dans un grand catalogue, et c’est pour cela qu’elles n’en portent aucune : si tout était marqué, la seule marque qui demande quelque chose se perdrait parmi les autres.

En ouvrant une entrée déjà adoptée, le détail ajoute Ce qui change : quels services diffèrent de ceux d’ici, et dans quels champs précis. Et le bouton passe d’Adopter à Mettre à jour, parce que c’est ce qu’il fait : il réécrit le scénario déjà présent, il ne laisse pas de copie à côté. Adopter trois fois ne produit plus « Paiements QA », « Paiements QA (2) » et « Paiements QA (3) ».

Ce qui est comparé, c’est le contenu : republier la même chose ne compte donc pas comme un changement. Un avertissement qui se déclenche sans que personne n’ait rien touché cesse vite d’être lu, et avec lui celui qui compte vraiment.

Si quelqu’un retire une entrée du catalogue, le scénario qui en provenait continue de fonctionner ici — mais la section le signale en haut, plutôt que de le laisser disparaître en silence : il n’y a plus personne derrière pour le mettre à jour.

Publier

Publier un scénario… le met à disposition de toute l’équipe, avec une ligne expliquant à quoi il sert. On y arrive depuis l’en-tête de la section, ou depuis le scénario lui-même avec Partager avec l’équipe… dans son menu. C’est cette ligne que verront ceux qui le trouveront dans la liste : elle vaut la peine d’être écrite.

Votre couche de démarrage locale ne voyage pas. Les options et variables avec lesquelles vous lancez un micro appartiennent à votre machine et n’ont pas à valoir sur celle d’un autre ; ce qui est publié, c’est le scénario, ses manifestes et ses mocks.

Retirer une entrée la supprime du catalogue de toute l’équipe, pas seulement du vôtre. D’où la confirmation : vous n’effacez pas quelque chose qui n’appartient qu’à vous.

La clé de l’équipe

Quand le catalogue est hébergé, il est chiffré de bout en bout : ce que le serveur stocke, ce sont des blocs qu’il ne peut pas ouvrir. La clé appartient à l’équipe et ne quitte jamais ses machines.

Elle se génère une fois — Générer une nouvelle clé — et se colle sur les autres machines — Saisir la clé de l’équipe. L’application demande de la répéter au moment de l’enregistrer : c’est ainsi qu’elle vérifie que vous l’avez vraiment recopiée quelque part avant de continuer.

Il vaut la peine de lire l’avertissement à côté du bouton et de le croire : si l’équipe perd la clé, le catalogue est irrécupérable. Aucune réinitialisation n’y changera rien, parce que personne d’autre ne la détient. Sa place est là où l’équipe garde ses autres secrets.

Un catalogue servi par Git n’a pas besoin de clé : le contrôle d’accès y est celui du dépôt lui-même.

La même chose depuis le terminal

Tout cela existe aussi dans le CLI, ce qui permet de monter l’environnement dans un job d’intégration continue ou sur la machine de quelqu’un qui vient d’arriver :

aseptic team list                     # ce que l'équipe partage
aseptic team status                   # toujours ce que partage l'équipe ?
aseptic team adopt pagos-qa --apply   # le ramener et l'adopter ici
aseptic start "Pagos QA"

Sans --apply, adopt n’affiche que le plan et ce qui manque sur cette machine — la même liste que le détail de la section. Détail complet dans Commandes du CLI.

Ce que ce n’est pas

Ce n’est pas un endroit où ranger le code de vos micros : les dépôts restent des dépôts. Ce qui se partage, c’est la façon dont ils se combinent — quels micros, dans quel mode, avec quels mocks et quelles dépendances résolues —, c’est-à-dire précisément ce qui ne tient pas dans un README et finit par se transmettre de bouche à oreille.