Un framework moderne et puissant pour construire des applications web scalables côté client.
Cette application front-end est conçue pour le dashboard des bots Discord en utilisant le framework Angular.
Afin de maintenir une cohérence et une clarté dans notre travail collaboratif, nous avons mis en place des normes pour les messages de commit et les pull requests.
Le projet suit le workflow GitFlow pour la gestion des branches. Voici les principales branches à utiliser :
main: Branche de production, contient le code stabledevelop: Branche principale de développementfeature/*: Branches pour les nouvelles fonctionnalitéshotfix/*: Branches pour les corrections urgentesrelease/*: Branches pour la préparation des versions
Règles importantes :
- Toute nouvelle fonctionnalité doit partir de
developet créer une branchefeature/nom-de-la-feature - Les corrections urgentes partent de
mainavec une branchehotfix/nom-du-fix - Les branches
featuresont fusionnées dansdevelop - Les
hotfixsont fusionnés dansmainETdevelop
Les messages de commit doivent suivre ce format :
type(portée): titre du commit
type : Le type de modification, par exemple "fix" ou "feat".
portée : Le dossier concerné (un commit par fichier modifié, supprimé ou ajouté).
titre du commit: Une description concise du changement apporté. En l'occurence (en anglais)
feat(auth): add login button
Ajouter un body : Si le titre du commit n'est pas assez explicite sur la localisation de la modification, le nom du fichier doit être précisé dans le body.
In file "login.component.ts"
Cela permet de donner plus d'informations sur les raisons du changement, son impact ou les fichiers modifiés.
Bonne pratique : Respecter une longueur maximale d'environ 50 caractères pour les titres des commits. Cela permet d'avoir des messages concis, faciles à lire et à comprendre.
Commits atomiques : Chaque commit doit être atomique, c'est-à-dire qu'il doit se concentrer sur une seule fonctionnalité ou un seul changement. Cela veut dire un commit par fichier modifié, supprimé ou ajouté au minimum.
Cela garantit une meilleure traçabilité et simplifie la gestion des erreurs.
Nom en anglais : Les titres des pull requests doivent être rédigés en anglais pour garantir une compréhension globale de l'équipe.
Ajout de labels : Chaque pull request doit inclure un ou plusieurs labels pour faciliter la gestion des PRs.
Les labels indiquent le type de changement.
Par exemple :
Nom des fichiers en français : Les noms des fichiers dans le projet doivent être en français pour garder une cohérence avec la langue principale du projet.
Utiliser le kebab-case : Les noms de fichiers doivent être écrits en kebab-case, c'est-à-dire tout en minuscules, avec des mots séparés par des tirets.
Exemple :
gestion-utilisateurs.js
verifier-email.md
Demandes de changements détaillées par les reviewers : Si un reviewer exige des modifications sur une pull request, il doit clairement spécifier dans un commentaire les changements à effectuer.
Le reviewer doit fournir une explication détaillée pour s'assurer que le contributeur comprend bien les modifications demandées. Cela favorise la transparence et permet à tous les membres de l'équipe de suivre l'évolution de la pull request.
Approbation partagée : Une pull request doit être validée par au moins un membre du groupe émetteur de la PR en question.
Nombre minimum de reviewers : Pour qu'une pull request soit fusionnée, elle doit être approuvée par un minimum de trois reviewers, y compris des membres externes au groupe émetteur, afin de garantir une évaluation complète et de qualité.
Validation du Tech Lead : Parmi les reviewers, le Tech Lead du groupe émetteur de la pull request doit obligatoirement faire partie des approbateurs. L'approbation finale du Tech Lead est nécessaire pour qu'un membre du groupe puisse procéder à la fusion. Il revient au Tech Lead de donner l'aval définitif, assurant que la pull request est prête à être intégrée dans la base de code principale.
Responsabilité lors de la fusion : Le tech lead qui approuve le merge d'une pull request est responsable de la fusion de celle-ci. En acceptant de fusionner la pull request, il accepte également de prendre la responsabilité en cas de problèmes futurs liés à cette pull request.
Interdiction pour l'émetteur de fusionner sa pull request : L'émetteur de la pull request n'est pas autorisé à fusionner sa propre pull request. Cela permet de garantir une validation externe par les autres membres du groupe ou par des reviewers indépendants, pour renforcer la qualité et la fiabilité des modifications apportées.
Annulation des approbations de pull requests lorsque de nouveaux commits sont poussés : La règle "Dismiss stale pull request approvals when new commits are pushed" doit être activée. Cela signifie que si des commits supplémentaires sont ajoutés à une pull request déjà approuvée, les approbations précédentes seront automatiquement révoquées. Cette règle garantit que les modifications récentes sont également examinées par les reviewers, assurant ainsi que l'évaluation de la pull request reste valide et à jour.
# Installation des dépendances
$ npm install# mode développement
$ ng serve
# mode développement avec hot reload
$ ng serve --watch
# build pour la production
$ ng build --prod# tests unitaires
$ ng test
# tests end-to-end
$ ng e2e
# lint
$ ng lint