Section | Description |
---|---|
🎯 Objectifs et contexte | Introduction et contexte du projet |
🚧 Dépendances | Dépendances techniques et comment les installer |
🏎 Départ rapide | Détails sur comment démarrer rapidement le développement du projet |
🏗 Code et architecture | Détails sur les composantes techniques de l’application |
🔭 Améliorations possibles | Améliorations, idées et refactors potentiels |
🚑 Problèmes et solutions | Problèmes récurrents et solutions éprouvées |
🚀 Déploiement | Détails pour le déploiement dans différents environnements |
…
Navigateur | OS | Contrainte |
---|---|---|
… | … | … |
Toutes les versions des dépendances runtime sont définies dans le fichier .tool-versions
. Ces dépendances externes sont également requises :
- PostgreSQL (
~> 12.0
)
Toutes les variables d’environnement requises sont documentées dans .env.dev
.
Ces variables doivent être présentes dans l’environnement lorsque des commandes mix
ou make
sont exécutées. Plusieurs moyens sont à votre disposition pour ça, mais l’utilisation de nv
est recommandée puisqu’elle fonctionne out of the box avec les fichiers .env.*
.
- Créer
.env.dev.local
et.env.test.local
à partir des valeurs vides de.env.dev
and.env.test
- Installer les dépendances Mix et NPM avec
make dependencies
- Générer des valeurs pour les secrets dans
.env.dev
avecmix phx.gen.secret
Ensuite, avec les variables de .env.dev
et .env.dev.local
présentes dans l’environnement :
- Créer et migrer la base de données avec
mix ecto.setup
- Démarrer le serveur Phoenix avec
make run
Un fichier Makefile
est présent à la racine et expose des tâches communes. La liste de ces tâches est disponible via make help
.
Pour éviter de rouler PostgreSQL localement sur votre machine, un fichier docker-compose.yml
est inclus pour permettre le démarrage d’un serveur PostgreSQL dans un container Docker avec docker-compose up postgresql
.
La suite de tests peut être exécutée avec make test
et le niveau de couverture de celle-ci peut être calculé et validé avec make check-code-coverage
.
Plusieurs outils de linting et de formatting peuvent être exécutés pour s’assurer du respect des bonnes pratiques de code :
make lint-elixir
s’assure que le code Elixir respecte nos bonnes pratiquesmake lint-scripts
s’assure que le code JavaScript respecte nos bonnes pratiquesmake lint-styles
s’assure que le code SCSS respecte nos bonnes pratiquesmake check-format
valide que le code est bien formattémake format
formatte les fichiers en utilisant Prettier etmix format
Le workflow .github/workflows/ci.yaml
s’assure que le code du projet est en bon état à chaque pull request et push
sur une branche.
…
Description | Priorité | Complexité | Idées |
---|---|---|---|
… | … | … | … |
Le projet expose une route GET /ping
qui retourne une réponse HTTP 200 OK
dès que le serveur est prêt à recevoir des requêtes. La réponse contient également la version du projet à des fin de déboguage.
Le projet expose une route GET /health
qui sert le module ElixirBoilerplateHealth
. Ce module contient différents checks qui s’assurent que l’application et ses services dépendants sont en santé.
Nom | Description |
---|---|
NOOP |
Check check est toujours en santé |
Le projet expose un tableau de bord Telemetry UI via la route GET /metrics
. Les métriques sont configurables ici.
Chaque déploiement est effectué à partir d’un tag Git. La version du codebase est gérée avec incr
.
Un container Docker exposant une release OTP peut être créé avec make build
, testé avec docker-compose up application
et poussé dans un registre avec make push
.