diff --git a/gitlab/architecture_projets.md b/gitlab/architecture_projets.md index a3115686442faab558fda2bd8c84058a50c5fc69..acc089c613191d3ace1f69ee07227e68f347236c 100644 --- a/gitlab/architecture_projets.md +++ b/gitlab/architecture_projets.md @@ -4,7 +4,7 @@ Il y a trois grand groupes utilisés à Veremes, qui permettent de versionner et  -## Projet +## 1. Projet Ce groupe encadré par Jordi et Yoann permet de versionner les différents projets faits pour des clients et où il n'y a pas de développement. @@ -12,45 +12,45 @@ Chaque client est représenté par un sous-groupe qui contiendra les différents  -## Development +## 2. Development Le groupe dévelopment est scindé en deux sous-groupes **vitis_apps** et **products**.  -### products +### 2.1. products Ce sous-groupe contient les différents développements faits pour des logiciels autres que Vitis. -### vitis_apps +### 2.2. vitis_apps Vitis_apps est un ensemble de sous-groupes permettant de versionner tout ce qui touche aux applications Vitis allant des modules aux spécifications.  -#### Sources +#### 2.2.1. Sources Dans ce sous-groupe on retrouve l'ensemble des modules ainsi que Vitis, ces sources sont directement contenues dans les applications sous formes de subtrees, pour les modifier il faudra passer par les applications et **il ne faudra pas travailler directement sur les modules** mis à part pour créer ou merger des branches. -#### Applications +#### 2.2.2. Applications Ici on retrouve l'ensemble des applications Vitis **sur lesquelles il faudra travailler**, chaque application est dirigée par un chef de produit qui validera les différentes issues et merge-requests. Chaque application contient une copie de chacun de ses modules sous la forme de subtrees, une documentation détaillée sur le fonctionnement de ces applications est disponible [ici](applications_vitis.html). -#### Integration +#### 2.2.3. Integration Contient tout ce qui touche à l'intération continue : tests, génération de setups etc... -#### Specs +#### 2.2.4. Specs On y retrouvera les spécifications des différentes applications. -#### Util +#### 2.2.5. Util Nous retrouverons dans les sous-groupe les utilitaires liés à Vitis pour compiler PHP, lancer les websockets etc... -## Documentation +## 3. Documentation Ce groupe est encadré par Armand et Marot et contient l'ensemble des documentations des applications. @@ -58,17 +58,17 @@ Ce groupe est encadré par Armand et Marot et contient l'ensemble des documentat On y retrouve deux types de depôts : -### Modules +### 3.1. Modules Les dépôts de documentation des modules utiliés par les applications et se nomment doc_module_[nom du module] -### Applications +### 3.2. Applications Se nomment doc_module_[nom du module] ces dépôts contiennent à l'aide de *submodules* des copies à l'instant T des modules qu'ils contiennent. Un même module peut être utilisé par plusieurs applications comme c'est le cas pour doc_module_vitis -### Synchronisation +### 3.3. Synchronisation Des web hooks ont étés mis en place pour qu'à chaque fois qu'un module est modifié, alors toutes les applications qui le contiennent mettent à jour leurs *submodules*. Une documentation à été rédigée à ce sujet [ici](automaj_doc/automaj_doc.html) diff --git a/gitlab/compte_gitlab.md b/gitlab/compte_gitlab.md index c633d7df5be477c2b72f90a96005a1ac48b5b7ac..7321c52eae181b9fe8fbeb6a7fa0c478acb98db7 100644 --- a/gitlab/compte_gitlab.md +++ b/gitlab/compte_gitlab.md @@ -10,7 +10,7 @@ Je vais ci-après vous détailler les sections les plus importantes, pour édite  -## Profile +## 1. Profile Dans la partie profile nous pouvons éditer notre adresse mail, notre photo etc... @@ -20,19 +20,19 @@ GitLab n'est pas entièrement traduit en Français et parfois on peut se perdre  -## Notifications +## 2. Notifications GitLab va vous envoyer des notifications par email en fonction de votre implication dans les différents projets, vous pouvez paramétrer le niveau de notifications que nous allez recevoir directement dans cette section.  -## SSH keys +## 3. SSH keys Les clés SSH font partie intégrante de l'utilisation de Git en général car contrairement à SVN, git ne permet pas d'enregistrer ses mots de passe pour des raisons de sécurité. Si vous l'utilisez tel quel git vous demandera votre mot de passe à chaque fois que vous voudrez envoyer un fichier sur le serveur. Pour ne pas devoir taper votre mot de passe à chaque fois, vous devrez créer une clé SSH et la lier à votre compte GitLab. -### 1. Générer une clé SSH +### 3.1. Générer une clé SSH Pour générer une clé SSH il y a différentes solutions, l'une d'entre elles et la plus simple celons moi est d'utiliser GitKraken. @@ -42,7 +42,7 @@ Une fois ceci fait deux fichiers auront étés générés id_rsa qui correspond  -### 2. Enregistrer la clé +### 3.2. Enregistrer la clé Une fois que vous avez généré votre paire de clés, copiez le contenu de la clé publique (id_rsa.pub) et collez-le dans le champ Key, enfin donnez un nom à votre clé (exemple : Ordinateur Armand) puis ajoutez-la. @@ -50,7 +50,7 @@ Une fois que vous avez généré votre paire de clés, copiez le contenu de la c Vous pouvez maintenant utiliser GitKraken sans taper votre mot de passe à nouveau. -## Preferences +## 4. Preferences Ici vous pourrez modifier la couleur de votre interface et surtout décider de quelle page s'affiche quand vous arrivez sur GitLab. diff --git a/gitlab/correctifs_evolutions.md b/gitlab/correctifs_evolutions.md index af40099058813cc037beedfe952663a7aa72a89f..7d14ecfdfb845c0069fa912b524fb77e0218b1cd 100644 --- a/gitlab/correctifs_evolutions.md +++ b/gitlab/correctifs_evolutions.md @@ -1,12 +1,12 @@ # Correctifs et évolutions -## Branches principales +## 1. Branches principales -### Pour les projets FME +### 1.1. Pour les projets FME Quand les projet abritent des fichiers non textuels (audio, fmw, zip etc..) des conflits non résolvables vont apparaître régulièrement lors des étapes de merge, dans ce cas il est préférable de créer une branche de travail ouverte à tous les contributeurs, de protéger la branche master pour y faire des merge quand les développements ont étés validés. -### Pour les projets de développement +### 1.2. Pour les projets de développement Dans ce cas il est possible d'utiliser 100% des capacités de Git et c'est ce que nous allons faire en appliquant la procédure suivante. @@ -21,7 +21,7 @@ Quand l'environnement de pré-production est validé, il est alors mergé sur ne  -## Faire un correctif +## 2. Faire un correctif *Cette section est réservée aux projet de développement* @@ -33,7 +33,7 @@ Une fois le bug corrigé nous le rapatrierons sur master à l'aide d'une merge r Chaque correctif doit être fait à travers une issue (documenté plus bas) -## Faire une évolution +## 3. Faire une évolution *Cette section est réservée aux projet de développement* @@ -45,7 +45,7 @@ Une fois terminée, la branche sera rapatriée sur next_version. Chaque évolution doit être fait à travers une issue (documenté plus bas) -## Créer un correctif/évolution dans GitLab +## 4. Créer un correctif/évolution dans GitLab Dans GitLab la notion de correctif ou d'évolution est lié à une issue, une issue est une demande aux développeurs de résoudre un problème sur l'application actuellement en production ou alors de déveloper une nouvelle fonctionnalité. @@ -62,7 +62,7 @@ Parmi les labels disponibles il faudra spécifier si il s'agit d'un bug ou d'une Lorsqu'un responsable produit va accepter une issue il voudra si c'est un bug créer une branche ainsi qu'une merge request, pour cela plusieurs étapes sont nécessaires. -#### Assigner la demande +#### 4.1. Assigner la demande En assignant la branche à quelqu'un il recevra une notification par mail ainsi que sur l'interface. @@ -76,7 +76,7 @@ Les labels permettront de filtrer les issues, les deux labels bug et evolution s  -#### Effectuer la demande +#### 4.2. Effectuer la demande **Quand l'issue vous est attribuée** et que vous commencez à la résoudre il faudra créer une branche ainsi qu'une merge request. @@ -94,7 +94,7 @@ Désormais une branche portant le nom de l'issue a été créée. Vous remarquer **Une fois les développements terminés** sur la branche il est temps de terminer la merge request pour demander au responsable projet d'intégrer les développements sur la banche source. Pour cela il faudra lui assigner la merge request puis enlever le status WIP en cliquant sur **Resolve WIP status**. -#### Valider la demande +#### 4.3. Valider la demande Une fois que le développeur a terminé et vous a assigné la demande de merge vous pouvez visualiser les modifications effectuées et valider la demande. diff --git a/gitlab/depot_gitlab.md b/gitlab/depot_gitlab.md index a37ed0033cbb157ab31752630bef993bad6f5aac..7461e2c27f729039ee23bd922d54514f5460f99a 100644 --- a/gitlab/depot_gitlab.md +++ b/gitlab/depot_gitlab.md @@ -4,7 +4,7 @@ Les dépôts agissent comme des conteneurs de fichiers et permettent le versionn  -## Créer un dépôt +## 1. Créer un dépôt Pour créer un dépôt il suffit de cliquer sur le bouton **New project**, lors de la création d'un dépôt il est important de comprendre où doit-il se situer, par défaut il indiquera votre compte au quel cas vous serez hébergeur et il sera accessible à l'URL `https://gitlab.veremes.net/[votre nom]/[nom du dépôt]`. Pour un projet en production il est préférable le créer dans un groupe de manière à ce qu'il hérite des droits des utilisateurs et que son emplacement soit clair, pour cela il suffira de choisir le groupe voulu dans la liste déroulante située à droite de l'URL du projet. @@ -16,7 +16,7 @@ Chaque dépôt doit contenir un fichier README.md contenant une description du p Une fois le dépôt crée il faudra éditer les paramètres comme détaillé ci-arpès dans la section [paramètres depot](depot_gitlab.html#) -## Paramétrer le dépôt +## 2. Paramétrer le dépôt Une fois le dépôt crée on accède à la page suivante, on peut déjà le cloner pour alimenter ses fichiers mais nous allons tout d'abord le paramétrer. Pour cela il suffit de se rendre dans la section **Settings** @@ -26,12 +26,12 @@ Cette section est divisée en plusieurs parties que nous détaillerons pour la p  -### 1. General -### 1.1 General project +### 2.1. General +#### 2.1.1 General project Dans cette partie nous pouvons modifier le nom, la description, la photo etc.. affichés dans GitLab, ceci ne changera pas l'URL du projet et ce dernier pourra continuer à fonctionner sur les postes l'ayant clonné. -### 1.2 Permissions +#### 2.1.2 Permissions Ici on peut activer/désactiver les différents modules GitLab disponibles, à Veremes nous utiliserons le paramétrage suivant : @@ -43,19 +43,19 @@ Ici on peut activer/désactiver les différents modules GitLab disponibles, à V - **Wiki** doit être desactivé - **Snippets** doit être desactivé -### 1.3 Advanced +### 2.1.3 Advanced Permet de supprimer le projet ou de changer son URL -### 2. Members +### 2.2. Members Ici nous pourrons définir quels seront les droits des différents contributeurs, pour plus d'informations vous pouvez lire la section [droits GitLab](objets_gitlab.html#droits). -### 2. Integrations +### 2.3. Integrations Cette partie permettra de mettre en place des Web-hooks pour lier le projet à un logiciel tiers (ReadTheDocs etc..) -### 3. Repository +### 2.4. Repository Dans cette section il est important de ce pencher sur la partie **Protected branches**, c'est ici que nous déciderons des branches à protéger. diff --git a/gitlab/objets_gitlab.md b/gitlab/objets_gitlab.md index 640bbd6a1e4f4f3dfc196cf8a3710054ae8cbd20..cdce49e71df0f6a0848ac2e88b606be8a4ce66e9 100644 --- a/gitlab/objets_gitlab.md +++ b/gitlab/objets_gitlab.md @@ -1,16 +1,17 @@ + # Objets GitLab -## Groupes +## 1. Groupes Sur GitLab les projets peuvent êtres répartis par groupes, ces derniers vont agir comme des dossiers conteneurs de dépôts, on peut également placer des sous-groupes qui contiendront eux aussi des dépôts. -### Interface +### 1.1. Interface On peut accéder à la liste des groupes en cliquant sur le bouton **Groups** présent dans la barre suppérieure. On y distingue **Your groups** pour retourner les groupes sur lesquels l'utilisateur contribue et **Explore groups** pour visualiser les groupes de l'utilisateur plus les groupes publics.  -### Droits +### 1.2. Droits On peut dans un groupe gérer les droits des utilisateurs, alors ces droits seront appliqués sur tous les projets contenus. @@ -21,54 +22,54 @@ Vous trouverez plus de détails sur les différents droits dans la section corre  -## Dépôts +## 2. Dépôts Les dépôts agissent comme des conteneurs de fichiers et permettent le versionnement, chaque dépôt est représenté par un lien unique proposé en HTTPS et SSH qui permettra d'effectuer un clone local du projet.  -### Branches +### 2.1. Branches Chaque dépôt est contitué au moins d'une branche **Master**, cette dernière est régulièrement protégée pour éviter les erreurs de rétro-compatibilité. Pour effectuer les modifications il vaut mieux créer une branche pour y effectuer les modifications, puis créer une **merge request**. -### Merge request +### 2.2. Merge request Une merge request est une demande d'intégration de modifications d'une branche enfant vers une branche parent, après avoir effectué des modifications sur une branche, il faudra créer une **merge request** et l'affecter à la personne en charge du projet. De cette manière la personne en charge du projet pourra vérifier et accepter (ou pas) la demande. -### Issue +### 2.3. Issue Une issue est une tâche liée à un problème ou une évolution, l'auteur de l'issue pourra dialoguer avec le responsable de produit et suivre l'avancement de la tâche. Quand le responsable de projet décide d'effectuer une tache il pourra lier l'issue à une merge request elle même liée à une branche, de cette manière on pourra une fois la tâche terminée vérifier les modifications effectuées. -### Labels +### 2.4. Labels Les labels agiront comme des tags pour classifier les issues (bug, évolution etc..) on peut définir les labels à utiliser dans le dépôt ainsi que dans les groupes.  -### Milestones +### 2.5. Milestones Un milestone est un ensemble d'issues à effectuer pour une version/projet, il permet entre autres de suivre l'avancement du projet.  -## Droits +## 3. Droits Sur GitLab il y a 5 types de droits qui peuvent entre autres effectuer les opérations ci-dessous, une documentation complète est disponible sur https://docs.gitlab.com/ee/user/permissions.html -### Guest +### 3.1. Guest - Visualiser le projet - Créer des issues - Voir les issues y compris confidentielles - Laisser des commentaires -### Reporter +### 3.2. Reporter - Pull le projet - Assigner des issues @@ -77,20 +78,20 @@ Sur GitLab il y a 5 types de droits qui peuvent entre autres effectuer les opér - Voir les merge requests - Manager les issues -### Developer +### 3.3. Developer - Créer des branches - Push sur les branches non protégées - Créer/éditer les milestones - Accepter les merge requests -### Maintainer +### 3.4. Maintainer - Ajouter des nouveaux membres - Accéder aux paramètres du dépôt - Rendre les branches protégées ou non -### Owner +### 3.5. Owner - Changer le niveau de visibilité - Supprimer/renommer le projet