| 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.localet.env.test.localà partir des valeurs vides de.env.devand.env.test - Installer les dépendances Mix et NPM avec
make dependencies - Générer des valeurs pour les secrets dans
.env.devavecmix 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-elixirs’assure que le code Elixir respecte nos bonnes pratiquesmake lint-scriptss’assure que le code JavaScript respecte nos bonnes pratiquesmake lint-styless’assure que le code SCSS respecte nos bonnes pratiquesmake check-formatvalide que le code est bien formattémake formatformatte 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.