Skip to content

Latest commit

 

History

History
189 lines (132 loc) · 5.96 KB

CONTRIBUTING.md

File metadata and controls

189 lines (132 loc) · 5.96 KB

Guide du développeur

Prérequis

  • docker et son plugin compose installés
  • utilisateur membre du groupe docker (pour exécuter docker et docker compose sans sudo)
  • id d'utilisateur (id -u) et de groupe (id -g) défini dans le .env à la racine du projet, si différents de 1000 (pour s'assurer que les différents conteneurs s'exécutent en tant que l'utilisateur pour avoir les mêmes droits)

Utiliser l'environnement de développement complet

Démarrer et initialiser l'environnement :

docker compose up -d front
./npm install
./npm run build -- --configuration production

Puis ouvrez votre navigateur sur http://localhost:8080

Les logs sont affichés sur la sortie standard des conteneurs et collectés par docker compose. Pour les consulter ou fil de l'eau :

docker compose logs -f

Attention : chaque démarrage de l'environnement Docker réinitialisera la base de données et recréera les fixtures (docker compose run --rm slim-cli ./install-with-fixtures.sh)

Tests de bout en bout

docker compose up -d front
./npm run e2e

Note : ces tests de bout en bout sont les tests d'intégration front, mais exécutés sur l'environnement de développement complet, avec du coup un jeu de test aligné sur les fixtures de l'API. Ce jeu de test doit être raffraichi entre 2 exécutions des tests :

docker compose up -d slim-cli

Front

Outils

Les différents outils front (cypress, ng, npm, npx) s'exécutent dans le conteneur docker npm, de manière à ne pas nécessiter l'installation de dépendances sur le poste du développeur, et maîtriser les versions utilisées.

Des scripts sont disponibles à la racine du projet pour simplifier leur appel via docker : ./cypress, ./ng, ./npm, ./npx. Ces scripts s'exécutent directement dans le contexte du répertoire front.

Installation des dépendances

./npm install

Tests

  • tests unitaires :

    ./npm test

    A faire : les tests unitaires sont minimalistes (instanciation des singleton). Une partie des tests faits en int/e2e devrait être repassée en tests unitaires

  • tests de composants :

    ./npm run ct

    ou pour n'exécuter que certains fichiers de tests :

    ./npm run cy -- --spec '**/liste-idees.component.cy.ts'

    A faire : les tests de composants sont pour la plupart minimalistes (montage du composant uniquement). Une partie des tests faits en int/e2e devrait être repassée en tests de composants

  • tests d'intégration :

    ./npm run int

    ou pour n'exécuter que certains fichiers de tests :

    ./npm run int -- --spec '**/liste-idees.cy.ts'

    (pour n'exécuter qu'une partie des tests au sein d'un fichier, remplacer it(...) par it.only() dans le fichier pour n'exécuter que certains tests, ou it.skip() pour au contraire passer certains tests)

    Notes :

    • ces tests d'intégration s'exécutent sur le serveur de développement Angular, avec interception des requêtes destinées à l'API (voir ci-dessous)

Utiliser le serveur de développement Angular seul

./npm start

Puis ouvrez votre navigateur sur http://localhost:4200/ quand l'invite vous le demande.

Comme le serveur de développement Angular est lancé sans --prod, les requêtes destinées à l'API sont interceptées et bouchonnées (cf. front/src/app/dev-backend.interceptor.ts).

Montées de version de node, angular et des autres dépendances

Procédure à suivre pour que le projet continue d'utiliser angular de la manière la plus standard possible de version en version :

  • passer sur la branche ngskel
  • monter la version de l'image node sur laquelle est basée le conteneur npm à la dernière version stable
  • reconstruire le conteneur npm
  • lancer ./init-ng, en l'adaptant si nécessaire aux nouveautés de node et d'angular
  • commit & push sur ngskel
  • cherry-pick ngskel dans master et :
    • supprimer le répertoire node_modules et le package.lock
    • repartir du package.json de la branche ngskel
    • réinstaller les autres dépendances avec ./npm install (pour qu'elles soient dans la dernière version disponible avec cette version de node)
    • résoudre les conflits pour adapter le code du front aux nouveautés de node, d'angular et des autres dépendances

API

Outils

Les différents outils back (composer, doctrine, console) s'exécutent dans le conteneur docker slim-cli, de manière à ne pas nécessiter l'installation de dépendances sur le poste du développeur, et maîtriser les versions utilisées.

Des scripts sont disponibles à la racine du projet pour simplifier leur appel via docker : ./composer, ./doctrine, ./console. Ces scripts s'exécutent directement dans le contexte du répertoire api.

Tests

  • tous les tests (unitaires et intégration) :

    docker compose run --rm slim-cli ./run-test.sh

  • ou seulement les tests d'intégration :

    docker compose run --rm slim-cli ./run-test.sh --filter '/Test\\Int/'

Attention : l'exécution des tests d'intégration réinitialise la base de données de l'environnement de développement (docker compose run --rm slim-cli ./install.sh)

Créer une nouvelle migration de base de données

Commencer par réinitialiser l'environnement de développement et s'assurer que la base de données est au niveau de la dernière migration :

docker compose run --rm slim-cli ./install.sh

Puis générer automatiquement la nouvelle migration :

./doctrine orm:clear-cache:metadata
./doctrine orm:clear-cache:query
./doctrine orm:clear-cache:result
docker compose run --rm slim-cli -c 'for d in $(find var/doctrine/cache -mindepth 1 -type d); do rm -rf "$d"; done'
./doctrine migrations:diff

Finalement, après vérification/finalisation de la migration, la tester :

./doctrine migrations:migrate
./console fixtures