Créer un espace de travail

Un espace de travail se crée en une minute, puis se rend exploitable en trois étapes dont une seule est obligatoire : connecter GitLab. Le reste se termine dans l’assistant, ou plus tard dans la configuration.

Créer l’espace

Qui peut LecteurProduct ownerDéveloppeurManagerAdministrateur

N’importe quel utilisateur connecté peut créer un espace : il en devient l’administrateur, et n’obtient aucun droit ailleurs.

Le dialog de création. Le panneau de droite explique le mode sélectionné, trait par trait.

Faites glisser pour parcourir la capture

1. Ouvrir le dialog

   Sur l’accueil, cliquez la carte en pointillés « Créer un espace de travail » à la fin de la grille. Sans aucun espace, c’est un bouton central qui la remplace.

   

2. Nommer l'espace

   Le Nom est obligatoire, la Description libre. Les deux se modifient ensuite dans la configuration.

   

3. Choisir le mode de déploiement

   Par branche ou Par tag. Le panneau de droite dit, pour le mode sélectionné, ce que deviennent le déploiement, la construction, l’environnement, les versions et le correctif, et rappelle en gris ce que ferait l’autre mode. Si vous hésitez, la section Les deux modes de déploiement de la page précédente les compare.

   

4. Nommer la branche principale

   master est proposé. La casse compte, et la branche n’a pas besoin d’exister déjà dans vos dépôts : elle est déclarative. Puis « Créer ».

   

Le même dialog en mode tag. Le panneau de droite change avec le mode sélectionné.

Faites glisser pour parcourir la capture

À la création, Deployer fabrique trois choses d’un coup : l’espace, sa branche principale comme première branche suivie, et votre adhésion en tant qu’administrateur. Vous êtes ensuite envoyé dans l’espace, où l’assistant vous attend.

L’assistant : trois étapes, une seule obligatoire

Qui peut Administrateur

L’assistant s’ouvre sur la première étape non franchie. Une barre en tête montre les trois étapes et leur badge, « Obligatoire » pour la connexion, « Optionnel » pour les deux autres. « Passer cette étape » saute une étape optionnelle ; « Retour » revient à la précédente.

L'étape 1 de l'assistant. L'aide de droite dit quel token créer.

Faites glisser pour parcourir la capture

Étape 1 : Connexion GitLab

1. Créer le token côté GitLab

   Deployer agit sur GitLab avec un token qui doit avoir le scope api. Si tous vos projets sont dans un même groupe GitLab, créez un Group Access Token sur ce groupe. S’ils sont répartis sur plusieurs groupes, créez un compte de service (un utilisateur bot membre de chaque groupe) et son token personnel. Évitez le token personnel d’une vraie personne : il casse l’espace le jour où elle part.

   

2. Renseigner l'instance et le token

   URL de l’instance en HTTPS, sans identifiants ni paramètres. Token d’accès tel que GitLab l’a généré. Le token n’est jamais réaffiché ensuite.

   

3. Tester et connecter

   « Tester et connecter » vérifie l’URL et le token auprès de GitLab avant de les enregistrer. En cas de refus, un encart rouge dit lequel des deux est en cause : token refusé, droits insuffisants, instance injoignable, quota atteint. Une fois la connexion établie, le même bouton devient « Continuer », et revenir sur cette étape ne réinterroge pas GitLab.

   

Étape 2 : Projets liés

Le catalogue liste les projets GitLab que le token peut voir, avec une recherche et une pagination par vingt. GitLab ne renvoie pas de total : on parcourt page par page. Cochez les dépôts que l’espace doit piloter, puis « Lier N projets ».

L'étape 2. Les projets que le token peut voir, à cocher.

Faites glisser pour parcourir la capture

Un projet lié est un dépôt sur lequel Deployer écrit : il y pousse des branches, pose des tags, ouvre des merge requests. Le projet qui porte vos tickets n’a en général pas à en faire partie ; il se déclare ailleurs, comme source d’issues (voir Configurer un espace).

Étape 3 : Environnements

L’étape déclare les cibles de déploiement, dans l’ordre de promotion. Sa forme dépend du mode.

L'étape 3. Les presets ne s'affichent que sur un espace encore vide.

Faites glisser pour parcourir la capture

Glissez les lignes pour changer l’ordre de promotion. La branche principale est affichée mais ne se modifie pas ici. Chaque geste part immédiatement : il n’y a pas de bouton « Enregistrer » dans l’assistant.

1. Terminer

   « Terminer et ouvrir l’espace » est actif dès que GitLab est connecté. Il vous mène sur l’accueil de l’espace : la checklist s’il reste quelque chose à faire, l’écran Déploiements sinon.

   

La checklist d’accueil

Tant que l’espace est connecté mais incomplet, son accueil affiche « Terminer la configuration » : trois lignes avec leur badge, une barre de progression, et un bouton par ligne.

La checklist. Un item franchi porte « Voir », un item à faire porte « Configurer ».

Faites glisser pour parcourir la capture

« Configurer » rouvre l’assistant à la bonne étape ; « Voir » ouvre la section de configuration correspondante. « Explorer l’espace sans terminer la configuration » mène sur Déploiements : sans cette sortie, une étape optionnelle jamais faite vous ramènerait sur la checklist à chaque arrivée.

Dès que l’espace a une connexion et au moins un projet, la checklist disparaît : arriver dans l’espace ouvre directement Déploiements.

Et après

L’espace est créé, connecté et lié. Il reste ce que l’assistant ne fait pas, et qui se règle dans la configuration : les branches sources autorisées et les variables de chaque environnement, les motifs de nommage des tags et des branches de correctif, les sources d’issues, l’application OAuth. Et l’équipe, qui s’invite depuis l’écran Membres.

Un espace créé par erreur se supprime depuis la zone sensible de la configuration, en retapant son nom, ou depuis le menu de sa carte sur l’accueil.