Stack Symfony
Best practice
GIT
![](https://s3.amazonaws.com/media-p.slid.es/uploads/309684/images/11415575/DALL_E_2024-06-17_15.38.59_-_A_conceptual_digital_artwork_representing_the_version_control_system__GIT_._The_image_should_include_a_large__glowing_GIT_logo_in_the_center__surround.webp)
MonoRepo vs Polyrepo
![](https://s3.amazonaws.com/media-p.slid.es/uploads/309684/images/10667715/pasted-from-clipboard.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/309684/images/10666256/Screenshot_2023-08-08_at_16.38.46.png)
Workflow GIT
Choisir le bon workflow pour la bonne taille d'équipe et le bon process de déploiement :
Légère recommendation : son propre workflow, inspiré de github flow et gitflow
![](https://s3.amazonaws.com/media-p.slid.es/uploads/309684/images/11415590/pasted-from-clipboard.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/309684/images/11415599/pasted-from-clipboard.png)
Feature Flag
Avantages :
- Déploiements indépendants des releases
- Tests en conditions réelles
- Gestion du risque
- Facilitation des rollbacks
- Amélioration continue
- Simplification du workflow git
- Contrôle dynamique
Convention Commit
- Conventional Commits
- Semantic Commit Messages
- Ses propres conventions documenté
Stack Local
![](https://s3.amazonaws.com/media-p.slid.es/uploads/309684/images/11415758/pasted-from-clipboard.png)
Docker
Docker Compose fait concensus
Recommendations :
- Versionné la configuration dans le code source du projet
- Multi stage build
- Utiliser un compose.override.yaml pour la surchage local
- Utiliser un compose.override.yaml.dist
- Bien configurer les volumes (read/write)
- Utiliser le réseau par défaut si possible
services:
php:
build: ./docker/php
depends_on:
- mysql
volumes:
- ./app:/srv/jobs:rw,cached
- ~/.composer:/.composer # for Composer cache
mysql:
image: percona
restart: always
environment:
- MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD:-nopassword}
- MYSQL_DATABASE=jobs
- MYSQL_USER=jobs
- MYSQL_PASSWORD=${MYSQL_PASSWORD:-nopassword}
volumes:
- mysql-data:/var/lib/mysql:rw
nginx:
build: ./docker/nginx
depends_on:
- php
security_opt:
- no-new-privileges:true
volumes:
- ./app/public:/srv/jobs/public:ro
Version
Bien choisir la version des dépendances que va utiliser le projet.
S'appuyer sur le semver "Semantic Versioning"
X.Y.Z incrémenter la version :
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug & security fixes
![](https://s3.amazonaws.com/media-p.slid.es/uploads/309684/images/11415814/Screenshot_2024-06-17_at_16.26.28.png)
Version - Symfony
![](https://s3.amazonaws.com/media-p.slid.es/uploads/309684/images/11415831/Screenshot%2B2024-06-17%2Bat%2B16.31.41.png)
Version - PHP
Tests
automatisés
![](https://s3.amazonaws.com/media-p.slid.es/uploads/309684/images/11417938/pasted-from-clipboard.png)
Bonne pratiques :
- Toute contribution de code vient avec un test automatisé
- Raisonner en rentabilité plutot qu'en type de tests ou outils
- Privilégier les tests fonctionels
- FIRST rules
- Pas de TDD
- Pas de codecoverage
Les Tests doivent être :
- Fast in their execution
- Isolated from each other
- Repeatable indefinitely
- Self-explanatory
- Must come Timely
F.I.R.S.T rule
Framework de tests
- Atoum
- Pest
- Jest
- Cypress
- Playwright
Recommendations :
- Utiliser un framework qui supporte Gherkin
- Behat
- Utiliser un framework de test backend pour mieux piloter le projet
- On peut avoir plusieurs frameworks de tests pour différent types de tests
- Il ne faut pas imposer un framework de test, il doit être adopter par l'équipe
Type de test
Disclaimer : Il y a beaucoup de types de tests, et peu de consensus. Il vaut mieux s'éloigner du débat pour simplifier à quelque type de tests :
- Unitiaire : tester le comporement d'une méthode de class. Entré/Sortie + Exception
- Fonctionnel : tous le reste, une couche de l'application
- Smoke : test fonctionnel le plus basic dans le web : Tester une URL et son status code.
Type de test
Recommendations :
- Mettre en place en priorité dans cet ordre : les smoke tests, puis les tests fonctionnel voir E2E
- Une bonne base 80% de test fonctionnel pour 20% de test unitaire
- La proportions de type de test dépends de la maturité et du type de projet
- Peu importe l'outils ou même le type de test, chaque contribution de code vient avec un test*
- Tester unitairement les algorithmes, les méthodes métier, foncitonnel ou sensible. Ou les librairie réutilisable (bundles/plugins)
A éviter absolument :
- pyramide de tests
- ticket de tests
Données de tests
Recommendations :
- AliceFixtures
- Faker
- Ne pas être trop rigoureux sur la solution et le format des fixtures
CI
![](https://s3.amazonaws.com/media-p.slid.es/uploads/309684/images/11415989/pasted-from-clipboard.png)
Continuous Integration
CI
Bonne pratiques :
- Utiliser une solution dédié comme Gitlab-CI, GithubActions, CircleCI
- Versionner la configuration dans le code source du projet pour quelle soit maintenable par tout le monde
- S'appuyer le plus possible sur la stack docker et ses valeurs par défaut pour exploiter le projet
Forte recommendation : Gitlab-CI
# .gitlab-ci.yaml
stages:
- install # removed in this exemple
- quality
- tests
quality:phpstan:
image: thecodingmachine/php:8.3-v4-cli-node18
stage: quality
script:
- php vendor/bin/phpstan analyze -c phpstan.dist.neon
quality:security:
image: thecodingmachine/php:8.3-v4-cli-node18
stage: quality
script:
- composer audit
- yarn audit
quality:cs:
stage: quality
script:
- vendor/bin/php-cs-fixer check src
tests:unit:
script:
- php bin/phpunit --colors=always
tests:behat:
script:
- php bin/console hautelook:fixtures:load -q
- php vendor/bin/behat --stop-on-failure
Quality Gate
-
Coding Style :
-
PHP : php-cs-fixer
-
Javacsript : ESLint
-
-
Security :
-
PHP : composer audit
-
Javascript : yarn audit ou npm audit
-
-
Qualité :
-
Database : bin/console doctrine:database:validate
-
Architecture & Monorepo : deptrac
Configuration
Recommendations :
- Activer les shallow clone
- Protéger les branchs develop/master
- Code revew via minimum 1 approval. Davantage si l'équipe est plus grande
- Prérequis des merges :
- Approvals
- Pipeline successfull
Exemple de shallow clone
# .gitlab-ci.yaml
stages:
- install
- quality
- tests
variables:
GIT_DEPTH: 1
Déploiement
![](https://s3.amazonaws.com/media-p.slid.es/uploads/309684/images/11418071/pasted-from-clipboard.png)
Best practices :
- Déploiement continue
- Configuration de déploiement versionné dans le projet
- Si plusieurs projets à déployer, un seul projet maître pour centraliser la configuration
- Pattern Blue/Green
Solution de déploiement :
- Capistrano
Deployer- Fabric
- Ansible
- Custom
Légère recommendation : Capistrano
Technologies
![](https://s3.amazonaws.com/media-p.slid.es/uploads/309684/images/11418077/pasted-from-clipboard.png)
- Framework : Basé sur Symfony (Laravel, Cake, Custom, SymfonyFramework)
- Database : PosgreSQL / MariaDB
- Moteur de fil d'attente : RabbitMQ
- Storage rapide : Redis
- Moteur de recherche : Meilisearch / ElasticSearch
- ServeurWeb : FrankenPHP / Nginx
- Outils de monitoring : Sentry / ELK / Datadog / Dynatrace
Serveur de mail
Recommendations :
- RGPD & Français : Mailjet
- Standard : Sendgrid
- RGPD & professionnel : Brevo
Autre &
Outils
![](https://s3.amazonaws.com/media-p.slid.es/uploads/309684/images/11418147/pasted-from-clipboard.png)
Outils pour piloter un projet
- Script Shell ou Bash
- Packetmanager : Composer ou Yarn
- Task runner : Castor, Gulp, Grunt, Doit, Robo
- Makefile
Forte recommendation : Makefile
## Install environment from scratch
install: vendor db-create fixtures
## Install vendir
vendor: composer.json
composer install
## Create Database
db-create:
bin/console doctrine:database:create
bin/console doctrine:schema:update -f
## Load Fixtures
fixtures:
bin/console doctrine:fixtures:load -n
Makefile
Performance
Pour adresser ce vaste sujet, un bon moyen de commencer et d'utiliser la checklist de Symfony concernant la performance
Mesure de la performance
Mesurer la performance passe par plusieurs solutions. Du monitoring, aux tests de monté en charge (TMC) en passant par le profiling.
L'équipe de développement doit avoir accès à ces outils. En ce qui concerne la solution de profiling on recommendera un outils dédié comme Blackfire.
Plutot qu'un profiler intégré comme dans : NewRelic, DataDog, Dynatrace, Sentry.
Alternative : Tideways
Performance - Cache
A l'echelle d'un projet Web et pour l'équipe de développement on peut simplifier en trois type de cache :
- Cache HTTP
- Cache applicatif (filesystem/redis)
- Cache Database
Le développeur devrait se concentrer sur la stratégie de cache HTTP, et sur le cache applicatif.
Cache à mettre en place par ordre de priorité :
- Cache HTTP : Documentation HTTP Cache Symfony
- Cache Applicatif : Composant Symfony Cache
Cache - priorité
IDE
-
Vous pouvez ce que vous préférer. Le meilleur IDE c'est celui qu'on maitrise :
-
Eclipse PDT
-
Netbeans
-
As an alternative : SublimeText
-
PHPStorm est le plus avancé/puissant
Recommendation : PHPStorm
Stack Symfony
By skigun
Stack Symfony
- 66