# CHECK-LIST #
## I-DESCRIPTION

Ce projet est développé avec le langage PHP à l'aide du framework [BlitzPHP](http://blitz-php.byethost14.com), utilise Bootstrap comme framework frontend et tourne sur une base de données MySql

## I-Installation
- [x] Commencez par cloner le projet sur votre PC

Rendez-vous sur la branche de developpement (`git checkout devs`)
**Vous ne ferez des commits et push que sur cette branche**

## Démarrage du projet

Après avoir cloner le projet, rassurez-vous que vous êtes dans le dossier approprié et à l'aide de votre terminal éxécuter les commandes suivantes:

 1 - installation des dependances
composer install

# 2 - creation du fichier de configuration
cp .env.example .env

## Vous devez par la suite modifier la section `BASE DE DONNEES` du fichier .env généré (Ligne 27 - 30) en fonction des paramètres de votre SGBD

# 3 - creation de la base de données
php klinge db:create sygen

# 4 - Execution des migrations pour la creation des tables
php klinge migrate --all

# 5 - Execution des seeds pour la creation du super admin
php klinge db:seed InitialUser

Une fois ceci terminé, vous pouvez lancer l'application à tout moment et commencer à l'utiliser

php klinge serve

L'application est lancée sur **http://localhost:3300**

Le informations d'accès par défaut sont:
* Login: **[e-mail]**
* Pass: **admin123**

Documentation de BlitzPHP: http://blitz-php.byethost14.com

## Cycle de développement
Avant de commencer à travailler, chacun doit se rassurer au préalable d'avoir récupérer les travaux de ses collaborateurs afin que toute l'équipe ai la même base de code. De ce fait, le workflow quotidien doit être le suivant

git checkout devs
git pull --no-rebase
composer update
php klinge migrate
// commit 1
// commit 2
git push

Une fois le push fait, le développeur devra faire une **pull request** sur GitHub afin qu'on puisse fusionner ses travaux.

## Guide de développement
LES REGLES SUIVANTES DOIVENT SCRUPULEUSEMENT ETRE RESPECTEES

1. Aucun push ne doit être fait sur la branche principale. Les différents développeurs devront faire des push sur la branche **devs** et faire une **pull request** sur la branche **main** lorsqu'ils auront des fonctionnalités prêtes à l'emploi.
2. Les commits sur un nombre important de fichiers sont proscits. Ils doivent être ponctuels et spécifique à une activité précise. Par ailleurs les commits doivent être fait avec la syntaxe suivante **{{badge}}: description**. La description du badge doivent être précise et en rapport avec l'action effectuée. {{badge}} est un terme générique qui peut avoir les valeurs suivantes:
* **feat** : Utilisé lorsqu'une nouvelle fonctionnalité a été ajoutée
* **fix** : Utilisé lorsqu'un bug a été corrigé
* **patch** : Utilisé lorsqu'on a apporté une optimisation d'une fonction sans ajout de fonctionnalité ou correction de bug et sans que sa n'impacte sur le reste du code (lors du remplacement d'un if/else par une condition ternaire par exemple)
* **chore** : Utilisé lorsque la structure globale d'un grand ensemble a été fortement modifiée
* **cs-fix** : Utilisé lorsqu'on fait une correction du style de code (par exemple quand on change **ma_variable** par **maVariable**)
* **docs**: Utilisé quand on fait une modification sur le guide d'utilisation (documentation). Un wiki sera créer sur ce dépôt de chaque responsable documentera chacune des fonctionnalités de son module.
Vous pouvez vous referez à la page des commits (https://github.com/mr-about-team/sygen2/commits/devs) pour avoir un aperçu
4. Les règles de codage suivantes doivent être respecter pour une meilleure intégration.
* Le nom de classe doivent être en *pascal case* et doivent être sufixé de *Controller* c'est-à-dire **MaClasseController**
* Le nom des propriétés et méthodes doivent être en *camel case* c'est-à-dire **maVariable** ou **maMethode**