doc-locale/fr-fr/tutorials/protected_workflow/_index.md
{{< details >}}
{{< /details >}}
Lorsque votre équipe démarre un nouveau projet, elle a besoin d'un workflow qui équilibre efficacité et revues appropriées. Dans GitLab, vous pouvez créer des groupes d'utilisateurs, combiner ces groupes avec des protections de branches, puis appliquer ces protections avec des règles d'approbation.
Ce tutoriel configure des protections pour les branches de release 1.x et 1.x.x d'un exemple de projet nommé « Excelsior », et crée un workflow d'approbation minimal pour le projet :
engineeringengineeringengineering {#create-the-engineering-group}Avant de configurer le projet Excelsior, vous devez créer un groupe pour posséder le projet. Ici, vous allez configurer le groupe Engineering :
Engineering.engineering.Ensuite, vous allez ajouter des sous-groupes à ce groupe engineering pour un contrôle plus granulaire.
engineering {#create-subgroups-in-engineering}Le groupe engineering est un bon début, mais les ingénieurs backend, les ingénieurs frontend et les responsables du projet Excelsior ont des tâches différentes et des domaines de spécialité différents.
Ici, vous allez créer trois sous-groupes plus granulaires dans le groupe Engineering pour segmenter les utilisateurs par type de travail : managers, frontend et backend. Vous ajouterez ensuite ces nouveaux groupes comme membres du groupe engineering.
Commencez par créer le nouveau sous-groupe :
Dans la barre supérieure, sélectionnez Rechercher ou aller à et recherchez engineering.
Sélectionnez le groupe nommé Engineering :
Sur la page de présentation du groupe engineering, dans le coin supérieur droit, sélectionnez Créer un sous-groupe.
Pour le Nom du sous-groupe, saisissez Managers.
Définissez le Niveau de visibilité sur Privé.
Sélectionnez Créer un sous-groupe.
Ajoutez ensuite le sous-groupe comme membre du groupe engineering :
engineering.Engineering.Engineering / Managers.engineering et à ses projets.Répétez ce processus pour créer des sous-groupes pour backend et frontend. Lorsque vous avez terminé, recherchez à nouveau le groupe engineering. Sa page de présentation doit afficher trois sous-groupes, comme ceci :
À l'étape précédente, lorsque vous avez ajouté vos sous-groupes au groupe parent (engineering), vous avez limité les membres des sous-groupes au rôle de Chargé de maintenance. Il s'agit du rôle le plus élevé qu'ils peuvent hériter pour les projets appartenant à engineering. Par conséquent :
manager avec le rôle Invité, et reçoit le rôle Invité sur les projets engineering.manager avec le rôle Propriétaire. Ce rôle est supérieur au rôle maximum (Chargé de maintenance) que vous avez défini. L'utilisateur 2 reçoit donc le rôle Chargé de maintenance au lieu de Propriétaire.Pour ajouter un utilisateur au sous-groupe frontend :
frontend.Frontend.frontend.Faites de même avec les groupes backend et managers. Le même utilisateur peut être membre de plusieurs sous-groupes.
Maintenant que votre structure de groupes est en place, créez le projet excelsior dans lequel les équipes pourront travailler. Comme les ingénieurs frontend et backend sont tous deux impliqués, excelsior doit appartenir à engineering plutôt qu'à l'un des sous-groupes plus petits que vous venez de créer.
Pour créer le nouveau projet excelsior :
engineering.Engineering.engineering, dans le coin supérieur droit, sélectionnez Créer un nouveau ({{< icon name="plus" >}}) et Dans ce groupe > Nouveau projet/dépôt.Excelsior. L'Identifiant « slug » du projet devrait se remplir automatiquement avec excelsior.GitLab crée le projet excelsior pour vous et vous redirige vers sa page d'accueil. Il devrait ressembler à ceci :
Vous utiliserez une fonctionnalité de cette page à l'étape suivante.
Ajoutez un fichier CODEOWNERS au répertoire racine de votre projet pour diriger les revues vers le bon sous-groupe. Cet exemple configure quatre règles :
engineering.[!note] GitLab Free ne prend en charge que les revues facultatives. Pour rendre les revues obligatoires, vous avez besoin de GitLab Premium ou Ultimate.
Pour ajouter un fichier CODEOWNERS à votre projet excelsior :
Dans la barre supérieure, sélectionnez Rechercher ou aller à et recherchez Excelsior.
Sélectionnez le projet nommé Excelsior.
À côté du nom de la branche, sélectionnez l'icône plus ({{< icon name="plus" >}}), puis Nouveau fichier :
Pour le Nom du fichier, saisissez CODEOWNERS. Cela créera un fichier nommé CODEOWNERS dans le répertoire racine de votre projet.
Collez cet exemple dans la zone d'édition en modifiant @engineering/ si cela ne correspond pas à votre structure de groupe :
# All changes should be reviewed by someone in the engineering group
* @engineering
# A manager should review any changes to this file
CODEOWNERS @engineering/managers
# Frontend files should be reviewed by FE engineers
[Frontend] @engineering/frontend
*.scss
*.js
# Backend files should be reviewed by BE engineers
[Backend] @engineering/backend
*.rb
Pour le Message de commit, collez :
Adds a new CODEOWNERS file
Creates a small CODEOWNERS file to:
- Route backend and frontend changes to the right teams
- Route CODEOWNERS file changes to managers
- Request all changes be reviewed
Sélectionnez Valider les modifications.
Le fichier CODEOWNERS est maintenant en place dans la branche main de votre projet et disponible pour toutes les futures branches créées dans ce projet.
Le fichier CODEOWNERS décrit les relecteurs appropriés pour les répertoires et les types de fichiers. Les règles d'approbation dirigent les merge requests vers ces relecteurs. Ici, vous allez configurer une règle d'approbation qui utilise les informations de votre nouveau fichier CODEOWNERS et ajoute une protection pour les branches de release :
Excelsior.Excelsior.Enforce CODEOWNERS.1.managers comme approbateurs.Une fois ajoutée, la règle Enforce CODEOWNERS ressemble à ceci :
Vous avez configuré plusieurs protections pour votre projet et vous êtes maintenant prêt à combiner ces protections pour sécuriser les branches importantes de votre projet :
Votre projet excelsior utilise la gestion sémantique de version pour les noms de branches de release, vous savez donc que les branches de release suivent le modèle 1.x et 1.x.x. Vous souhaitez que tout le code ajouté à ces branches soit revu par des experts du domaine, et que les responsables prennent la décision finale sur le travail fusionné dans la branche de release.
Plutôt que de créer des protections pour une branche à la fois, configurez des règles de branches génériques pour protéger plusieurs branches :
Excelsior.Excelsior.1.*, puis sélectionnez Create wildcard 1.*.Default. (Selon votre version de GitLab, cette branche peut être nommée main ou master.) Définissez les valeurs de cette branche pour qu'elles correspondent aux paramètres que vous avez utilisés pour la règle 1.*.Vos règles sont maintenant en place, même si aucune branche 1.* n'existe encore :
Maintenant que toutes les protections de branches sont en place, vous êtes prêt à créer votre branche de release 1.0.0 :
Excelsior.Excelsior.1.0.0.Les protections de branches sont maintenant visibles dans l'interface utilisateur :
Dans la barre latérale gauche, sélectionnez Code > Branches. Dans la liste des branches, la branche 1.0.0 doit indiquer qu'elle est protégée :
Dans la barre latérale gauche, sélectionnez Paramètres > Dépôt, puis développez Règles des branches pour afficher les détails de toutes les branches protégées :
Félicitations ! Vos ingénieurs peuvent travailler de façon indépendante dans leurs branches, et tout le code soumis pour la branche de release 1.0.0 sera revu par des experts du domaine.