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

Conventional Commits
Semantic Commit Messages
Ses propres conventions documenté

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

PHPunit
Panthere
Behat
PHPspec
Codeception

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 :
- PHP : php-cs-fixer
- Javacsript : ESLint
Security :
- PHP : composer audit
- Javascript : yarn audit ou npm audit
Qualité :
- PHPStan
- Rector
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 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 :
- PHPStorm
- VisualStudio Code
- Eclipse PDT
- Netbeans
As an alternative : SublimeText
PHPStorm est le plus avancé/puissant

Recommendation : PHPStorm

	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

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

	# .gitlab-ci.yaml

	stages:
	- install
	- quality
	- tests

	variables:
	GIT_DEPTH: 1


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

Stack Symfony Best practice

Stack Symfony
Best practice