Stack Symfony
Best practice

GIT

MonoRepo vs Polyrepo

https://monorepo.tools/#polyrepo-concept

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

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

Stack Local

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

Version - Symfony

Version - PHP

Tests
automatisés

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

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 : 

  • Security : 

  • 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

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 :

Légère recommendation : Capistrano

Technologies

  • 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

Benchmark serveur web

Serveur de mail

Recommendations :

  • RGPD & Français : Mailjet
  • Standard : Sendgrid
  • RGPD & professionnel : Brevo

Autre &
Outils

Outils pour piloter un projet

  • Script Shell ou Bash
  • Packetmanager : Composer ou Yarn
  • Task runner : Castor, Gulp, Grunt, Doit, Robo
  • Makefile

Forte recommendation : Makefile

Exemple complet


## 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

https://symfony.com/doc/current/performance.html

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 - priorité

IDE

  •   Vous pouvez ce que vous préférer. Le meilleur IDE c'est celui qu'on maitrise :

  • As an alternative : SublimeText

  • PHPStorm est le plus avancé/puissant

Recommendation : PHPStorm

Made with Slides.com