## Objectif

Quand nous développons des sites Web, nous avons à cœur de les rendre les plus légers possibles afin d’améliorer les performances pour les utilisat⋅eurs⋅rices, et aussi de réduire l'utilisation de la bande-passante pour diminuer l’énergie nécessaire à fournir ces services.

Néanmoins, il n’est pas toujours facile d’identifier quelles sont les parties à améliorer. Il existe plusieurs outils ([EcoIndex](https://www.ecoindex.fr/) ou [Greenspector](https://greenspector.com/) pour l’impact environnemental), et nous avons retenu Lighthouse qui mesure les performances comme l'accessibilité, et que nous avons pu intégrer facilement à notre CI.

## Lighthouse

[Lighthouse](https://developer.chrome.com/docs/lighthouse/overview?hl=fr) est un outil de mesure des performances d’une page Web développé par Google. Il évalue notamment : la vitesse d’affichage et de poids de page, le référencement (SEO), ainsi que l’accessibilité. Il simule la navigation comme le ferait un humain, et calcule le temps passé entre la demande du navigateur et la fin de l’affichage. Tout en évaluant le temps passé à télécharger les scripts et feuilles de style, et à exécuter le code Javascript.

On peut l’utiliser pour générer un rapport de la page que l’on souhaite (par exemple, [notre site](https://pagespeed.web.dev/analysis/https-www-troopers-coop/lz3s7730k4?form_factor=mobile)) : 

![performances.png](https://strapi.troopers.coop/uploads/performances_d4cdbbf7cf.png)

On souhaitait mesurer régulièrement les performances d’un projet afin de vérifier qu’elles ne s’éloignent pas de notre objectif, mais cela nous aurait demandé de lancer des analyses manuellement à intervalles réguliers.

Heureusement, il est possible d'automatiser ces analyses, nous allons vous présenter comment.

## Intégration continue

Grâce à notre [expérience avec GitLab CI](https://www.troopers.coop/blog/donnez-des-ailes-a-votre-gitlab-ci), nous avons pu facilement mettre en place une tâche automatique qui lance Lighthouse : 

1. un⋅e développeu⋅r⋅se modifie le code du projet
2. la personne pousse ses changements sur GitLab ouvre une demande de fusion
3. GitLab CI lance automatiquement la compilation du projet
4. ensuite, GitLab CI va faire tourner [Lighthouse](https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/getting-started.md) (via Docker) sur cette version du code, puis les envoyer à Google
5. les résultats du rapport sont visibles via un lien généré par Lighthouse

## Confidentialité des données et évolution dans le temps

Ces mesures sont très intéressantes, mais nous voulions améliorer 2 points : 
- stocker les données dans notre infrastructure au lieu d’envoyer les données à Google
- avoir un historique pour pouvoir comparer les rapports avant et après un changement

Fort heureusement, Google fournit également le[ côté serveur de Lighthouse](https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/server.md). Nous avons ainsi pu configurer notre propre instance (également via Docker).

Ainsi, GitLab CI envoie les résultats des analyses sur notre Lighthouse, ce qui ouvre de nouvelles possibilités :
- confronter les notes et mesures pour vérifier qu’une évolution ne dégrade pas les performances du site, pour ensuite faire des corrections adéquates ou expliquer au client si une diminution des performances est inévitable (par exemple, l’ajout d’une image, même optimisée, aura forcément un coût)
- constater l’évolution au fur et à mesure du temps, afin d'avoir une vue d’ensemble des performances
- les données ne sont pas transmises à Google, nous gardons le contrôle des résultats

Exemple : 
![exemple.png](https://strapi.troopers.coop/uploads/exemple_e08f69e31a.png)

Il faut prendre en compte qu’il y a une variabilité entre les résultats due aux serveurs de CI :
- Lighthouse peut être lancé par des serveurs différents, qui n’ont pas les mêmes performances
- ces serveurs peuvent être plus ou moins occupés en fonction des autres tests en cours
- il peut y avoir une congestion sur le réseau à ce moment-là (pour les appels à Strapi, qui héberge le contenu des pages)

Pour pallier cela, nous sommes en train de tester différentes solutions : restreindre Lighthouse à un seul serveur, mettre en cache les données de Strapi avant de lancer les tests pour éliminer la variabilité du réseau, etc
.
## Configuration de Lighthouse
### Côté serveur
docker-compose.yml


```yaml
services:
 lighthouse-ci-server:
 lighthouse-ci-server:
 image: 'patrickhulce/lhci-server'
 restart: always
 ports:
   - '127.0.0.1:9001:9001'
 volumes:
   - '/var/docker/lighthouse/:/data'
```

On peut alors interroger ce serveur pour [créer un projet](https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/getting-started.md#project-creation).
### Dans le projet
On utilise les règles recommandées par Lighthouse et on définit quelle(s) URL(s) on souhaite utiliser : 

 .lighthouserc.js 

```javascript
module.exports = {
 ci: {
   assert: {
     preset: 'lighthouse:recommended',
   },
   collect: {
     url: ['http://localhost:3000/fr'],
   },
   upload: {
     target: 'temporary-public-storage',
   },
 },
}
```

### Dans GitLab CI
On définit 3 valeurs de configuration via les variables de GitLab CI : 
- LIGHTHOUSE_USER : utilisateur HTTP
- LIGHTHOUSE_PASSWORD : mot de passe HTTP
- LIGHTHOUSE_BUILD_TOKEN : généré quand on a créé un projet


.gitlab-ci.yml

```yaml
.lighthouse-ci: &lighthouse-ci
 image: cypress/browsers:node-20.17.0-chrome-128.0.6613.119-1-ff-130.0-edge-128.0.2739.63-1
 stage: tests
 tags:
   - yarn-cache
 before_script:
   - yarn global add @lhci/cli@0.14.x
 only:
   - merge_requests
   # this is required to provide a base build to Lighthouse
   - develop


tests-lighthouse-ci:
 <<: *lighthouse-ci
 script:
   - yarn install


   - yarn build-web


   - nohup yarn start-web &
   - .ci/wait-for-it.sh localhost:3000 --timeout=120 # Donne du temps au serveur pour démarrer


   - lhci collect --numberOfRuns 1 --collect.settings.chromeFlags="--no-sandbox"
   # Supprimer les résultats du « pré-chauffage »
   - rm -rfv .lighthouseci/


   - lhci collect --collect.settings.chromeFlags="--no-sandbox"


   - lhci assert
 artifacts:
   paths:
     - .lighthouseci/
   expire_in: 24 hrs
   when: always
 allow_failure: true


lighthouse-ci:upload:
 <<: *lighthouse-ci
 stage: lighthouse
 needs: ['tests-lighthouse-ci']
 dependencies: ['tests-lighthouse-ci']
 variables:
   LHCI_SERVER_BASE_URL: https://lighthouse.troopers.agency
   LHCI_BASIC_AUTH__USERNAME: ${LIGHTHOUSE_USER}
   LHCI_BASIC_AUTH__PASSWORD: ${LIGHTHOUSE_PASSWORD}
   LHCI_TARGET: lhci
   LHCI_TOKEN: ${LIGHTHOUSE_BUILD_TOKEN}
 script:
   # the directory must exist
   - ls -lh ${PWD}/.lighthouseci/
   - lhci upload
```

## Conculsion
L’ajout de Lighthouse à nos processus qualité nous offre un nouveau regard quantitatif sur les performances de nos projets web. C’est rapidement devenu un des indicateurs qui nous aide à améliorer nos développements au quotidien, et par conséquent les projets de nos clients.

![meme.png](https://strapi.troopers.coop/uploads/meme_57e739fc67.png)

Mesurer les performances de nos sites web avec LightHouse, côté client et serveur

## Problème


Easyadmin est une solution de zone d’administration pour une application web, basé sur des CRUD (Create, Read, Update, Delete) pour les différents objets métiers (les utilisateurs, les articles d’un blog, les clients, etc.).

Ces objets métier peuvent être caractérisés par un contenu texte sous la forme de code html mis en forme, pour mettre du contenu en italique, en gras, ou pour définir un hyperlien.

Il existe des éditeurs en javascript pour réaliser cette mise en forme d’une façon pratique pour un utilisateur. Easyadmin [intègre](https://symfony.com/bundles/EasyAdminBundle/current/fields/TextEditorField.html) d’ailleurs une bibliothèque javascript pour cette fin : [Trix](https://github.com/basecamp/trix). S’il a l’avantage d’être léger et simple, cet éditeur peut manquer de fonctionnalités avancées comme l’upload de média.

C’est pourquoi nous allons mettre en place [CKEditor](https://ckeditor.com/) pour remplir cette fonction. 

À l’heure où nous écrivons cet article, la version d'EasyAdmin est la 4.11 et celle de CKEditor est la 42.0. Mais il est fort probable que la méthode fonctionne avec les versions ultérieures.

Pour les versions plus anciennes de CKEditor, il existe un [bundle symfony](https://symfony.com/bundles/FOSCKEditorBundle/current/index.html) pour avoir un élément de formulaire de type WYSIWYG. Mais il ne prend pas un charge CKEditor 5, qui par ailleurs est plus simple à utiliser. Nous allons donc l’installer et le configurer manuellement, ce qui nous donnera toute l’amplitude de personnalisation proposée par CKEditor.

## Prérequis

Nous considérerons que Symfony est installé avec EasyAdmin et fonctionnel, et que qu’un Crud pour un objet __Post__ est disponible, incluant un champ __Content__ stockant du HTML.

## Fonctionnement de base

Pour la gestion de dépendances javascript, nous utiliserons la solution qui est poussée par Symfony et qui a l’avantage d’être indépendant de Nodejs : [AssetMapper](https://symfony.com/doc/current/frontend/asset_mapper.html). Elle est installée par défaut avec tout projet Symfony récent.

Nous installons donc CKEditor via la commande
```bash
bin/console importmap:require ckeditor5
```

Asset mapper fonctionne selon le principe qu’un fichier doit servir de point d’entrée pour utiliser différents composants. Nous ajoutons maintenant la définition de cet entrypoint dans la configuration des assets, le fichier ```importmap.php``` à la racine du projet :

```php
    …
    'admin' => [
        'path' => './assets/admin.js',
        'entrypoint' => true,
    ],
    …
```

Créons maintenant ce fichier à l’emplacement ```assets/admin.js``` où nous faisons appel à notre librairie pour l’appliquer aux éléments de formulaires

```javascript
import 'ckeditor5/dist/ckeditor5.css';

document.querySelectorAll('[data-ckeditor=full]').forEach((editor) => {
    ClassicEditor.create(editor, {}});
});
```

Il nous reste maintenant à configurer le champ dans le contrôleur easyadmin

```php
namespace App\Controller\Admin;

use App\Entity\Article;
use EasyCorp\Bundle\EasyAdminBundle\Controller\AbstractCrudController;
use EasyCorp\Bundle\EasyAdminBundle\Field\TextareaField;

class ArticleCrudController extends AbstractCrudController
{
    public static function getEntityFqcn(): string
    {
        return Article::class;
    }

    public function configureFields(string $pageName): iterable
    {
        return [
            …
            TextareaField::new('content')->setLabel('admin.article.content')->setFormTypeOption('attr', ['data-ckeditor' => 'full']),
        ];
    }
}
```

Et voilà un champ gérer par CKEditor pour un beau WYSIWYG :) Par contre, on se retrouve avec l’éditeur de base, que nous voulons justement personnaliser …

## Personaliser 

La personnalisation de CKEditor se fait en passant un objet en paramètre. Nous vous proposons cette configuration très complète.

```javascript
import {
    ClassicEditor, AccessibilityHelp, Alignment, Autoformat, AutoImage, AutoLink, Autosave, BalloonToolbar, BlockQuote, Bold, Code, CodeBlock, Essentials, FindAndReplace, FontBackgroundColor, FontColor, FontFamily, FontSize, GeneralHtmlSupport, Heading, Highlight, HorizontalLine, HtmlComment, HtmlEmbed, ImageBlock, ImageCaption, ImageInline, ImageInsert, ImageInsertViaUrl, ImageResize, ImageStyle, ImageTextAlternative, ImageToolbar, ImageUpload, Indent, IndentBlock, Italic, Link, LinkImage, List, ListProperties, Mention, Paragraph, RemoveFormat, SelectAll, ShowBlocks, SimpleUploadAdapter, SourceEditing, SpecialCharacters, SpecialCharactersArrows, SpecialCharactersCurrency, SpecialCharactersEssentials, SpecialCharactersLatin, SpecialCharactersMathematical, SpecialCharactersText, Strikethrough, Style, Subscript, Superscript, Table, TableCaption, TableCellProperties, TableColumnResize, TableProperties, TableToolbar, TextTransformation, Underline, Undo
} from 'ckeditor5';

const editorConfig = {
    toolbar: {
        items: ['undo', 'redo', '|', 'sourceEditing', 'showBlocks', 'findAndReplace', 'selectAll', '|', 'heading', 'style', '|', 'fontSize', 'fontFamily', 'fontColor', 'fontBackgroundColor', '|', 'bold', 'italic', 'underline', 'strikethrough', 'subscript', 'superscript', 'code', 'removeFormat', '|', 'specialCharacters', 'horizontalLine', 'link', 'insertImage', 'insertTable', 'highlight', 'blockQuote', 'codeBlock', 'htmlEmbed', '|', 'alignment', '|', 'bulletedList', 'numberedList', 'indent', 'outdent', '|', 'accessibilityHelp'
        ],
        shouldNotGroupWhenFull: true
    },
    plugins: [
        AccessibilityHelp, Alignment, Autoformat, AutoImage, AutoLink, Autosave, BalloonToolbar, BlockQuote, Bold, Code, CodeBlock, Essentials, FindAndReplace, FontBackgroundColor, FontColor, FontFamily, FontSize, GeneralHtmlSupport, Heading, Highlight, HorizontalLine, HtmlComment, HtmlEmbed, ImageBlock, ImageCaption, ImageInline, ImageInsert, ImageInsertViaUrl, ImageResize, ImageStyle, ImageTextAlternative, ImageToolbar, ImageUpload, Indent, IndentBlock, Italic, Link, LinkImage, List, ListProperties, Mention, Paragraph, RemoveFormat, SelectAll, ShowBlocks, SimpleUploadAdapter, SourceEditing, SpecialCharacters, SpecialCharactersArrows, SpecialCharactersCurrency, SpecialCharactersEssentials, SpecialCharactersLatin, SpecialCharactersMathematical, SpecialCharactersText, Strikethrough, Style, Subscript, Superscript, Table, TableCaption, TableCellProperties, TableColumnResize, TableProperties, TableToolbar, TextTransformation, Underline, Undo
    ],
    balloonToolbar: ['bold', 'italic', '|', 'link', 'insertImage', '|', 'bulletedList', 'numberedList'],
    fontFamily: {
        supportAllValues: true
    },
    fontSize: {
        options: [10, 12, 14, 'default', 18, 20, 22],
        supportAllValues: true
    },
    heading: {
        options: [
            {
                model: 'paragraph',
                title: 'Paragraph',
                class: 'ck-heading_paragraph'
            },
            {
                model: 'heading1',
                view: 'h1',
                title: 'Heading 1',
                class: 'ck-heading_heading1'
            },
            {
                model: 'heading2',
                view: 'h2',
                title: 'Heading 2',
                class: 'ck-heading_heading2'
            },
            {
                model: 'heading3',
                view: 'h3',
                title: 'Heading 3',
                class: 'ck-heading_heading3'
            },
            {
                model: 'heading4',
                view: 'h4',
                title: 'Heading 4',
                class: 'ck-heading_heading4'
            },
            {
                model: 'heading5',
                view: 'h5',
                title: 'Heading 5',
                class: 'ck-heading_heading5'
            },
            {
                model: 'heading6',
                view: 'h6',
                title: 'Heading 6',
                class: 'ck-heading_heading6'
            }
        ]
    },
    htmlSupport: {
        allow: [
            {
                name: /^.*$/,
                styles: true,
                attributes: true,
                classes: true
            }
        ]
    },
    image: {
        toolbar: ['toggleImageCaption', 'imageTextAlternative', '|', 'imageStyle:inline', 'imageStyle:wrapText', 'imageStyle:breakText', '|', 'resizeImage'
        ]
    },
    link: {
        addTargetToExternalLinks: true,
        defaultProtocol: 'https://',
        decorators: {
            toggleDownloadable: {
                mode: 'manual',
                label: 'Downloadable',
                attributes: {
                    download: 'file'
                }
            }
        }
    },
    list: {
        properties: {
            styles: true,
            startIndex: true,
            reversed: true
        }
    },
    mention: {
        feeds: [
            {
                marker: '@',
                feed: [
                    /* See: https://ckeditor.com/docs/ckeditor5/latest/features/mentions.html */
                ]
            }
        ]
    },
    placeholder: 'Type or paste your content here!',
    style: {
        definitions: [
            {
                name: 'Article category',
                element: 'h3',
                classes: ['category']
            },
            {
                name: 'Title',
                element: 'h2',
                classes: ['document-title']
            },
            {
                name: 'Subtitle',
                element: 'h3',
                classes: ['document-subtitle']
            },
            {
                name: 'Info box',
                element: 'p',
                classes: ['info-box']
            },
            {
                name: 'Side quote',
                element: 'blockquote',
                classes: ['side-quote']
            },
            {
                name: 'Marker',
                element: 'span',
                classes: ['marker']
            },
            {
                name: 'Spoiler',
                element: 'span',
                classes: ['spoiler']
            },
            {
                name: 'Code (dark)',
                element: 'pre',
                classes: ['fancy-code', 'fancy-code-dark']
            },
            {
                name: 'Code (bright)',
                element: 'pre',
                classes: ['fancy-code', 'fancy-code-bright']
            }
        ]
    },
    table: {
        contentToolbar: ['tableColumn', 'tableRow', 'mergeTableCells', 'tableProperties', 'tableCellProperties']
    },
};


document.querySelectorAll('[data-ckeditor=full]').forEach((editor) => {
    ClassicEditor.create(editor, editorConfig);
});

```

Voilà un éditeur vraiment complet.

À présent, on peut aussi définir deux configurations différentes. Par exemple, on pourrait ajouter une version mini avec uniquement la mise en forme des textes. Nous pouvons la définir et l’appliquer à d’autres contextes.

```javascript
import {
    ClassicEditor,
} from 'ckeditor5';

const editorConfig = {
    toolbar: {
        items: [
            'bold',
            'italic',
            'underline',
            'strikethrough',
            'removeFormat',
        ],
    },
};

document.querySelectorAll('[data-ckeditor=mini]').forEach((editor) => {
    ClassicEditor.create(editor, editorConfig);
});
```

Pour utiliser cette configuration alternative, il suffit de la préciser dans le contrôleur :

```
    …
    TextareaField::new('content')->setLabel('admin.article.content')->setFormTypeOption('attr', ['data-ckeditor' => 'mini']),
    …
```


## En bonus : upload de media

L’upload de media depuis l’interface de WYSIWYG est une fonctionnalité vraiment pratique pour y intégrer des médias directement. CKEditor gère justement cette fonctionnalité. On va commencer par indiquer à CKEditor l’URL pour uploader les médias :

```javascript
import {
    …
    ImageUpload,
    SimpleUploadAdapter,
} from 'ckeditor5';

const editorConfig = {
    …
    plugins: [
        …
        ImageUpload,
        SimpleUploadAdapter,
    ],
    simpleUpload: {
        uploadUrl: '/admin/upload',
    }
};
```

Et voici le contrôleur Symfony associé qui renvoie la réponse attendue par ce «SimpleUploadAdapter» pour faire son travail correctement.

```php
namespace App\Controller\Admin;

use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;

class UploadController
{
    #[Route('/admin/upload', name: 'app_admin_upload', methods: ['POST'])]
    public function index(
        Request $request,
    ): Response {
        $path = 'uploads/wysiwyg';
        $uploadedFile = $request->files->get('upload');
        $originalFilename = pathinfo((string) $uploadedFile->getClientOriginalName(), PATHINFO_FILENAME);
        $filename = $originalFilename.'-'.uniqid().'.'.$uploadedFile->guessExtension();
        $request->files->get('upload')->move($path, $filename);
        $host = $request->getScheme().'://'.$request->getHttpHost();

        return new JsonResponse(['url' => $host.'/'.$path.'/'.$filename]);
    }
}
```


## Le mot de la fin


Finalement, nous avons vu que brancher la version 5 de CKEditor sur l’EasyAdmin basé sur Symfony est simple et hautement personnalisable. Parfois, ça vaut le coup de faire ce type de liaison soi-même et ne pas chercher un bundle ou une extension pour réaliser des liaisons finalement simples.

Installer CKeditor5 dans Easyadmin : une solution pas à pas

Dans [l’article précédent](https://www.troopers.coop/blog/github-gitlab-et-l-integration-continue) nous avions présenté GitHub et GitLab, nous allons maintenant montrer comment on actionne les CI en pratique.

## GitHub et ses Actions
Pendant plusieurs années, GitHub n’intégrait pas de solution de CI et il fallait s’appuyer sur des services externes comme Travis CI ou CircleCI afin d’exécuter les tests automatiquement, ce qui était fastidieux à configurer car il fallait connecter deux services différents.

Ceci a changé à partir de 2018 quand GitHub a intégré un service de CI gratuit nommé Actions. Sa grande force est la possibilité d’utiliser des recettes existantes, par exemple pour installer PHP et des modules en quelques lignes de configuration.

Pour les projets non publics (autrement dit les projets privés), GitHub offre 2 000 minutes d’utilisation des Actions par mois.

## GitLab et sa CI

Dès le début de notre bascule sur GitLab, nous nous sommes appuyés sur son service CI afin de lancer automatiquement les tâches de tests (fonctionnels, unitaires ou E2E) et de vérification de la qualité du code (formatage et logique).

Les tests automatisés sont lancés par 4 serveurs physiques qui jouent le rôle de runner, chaque serveur attend en permanence que des tests soient en file d’attente. Dès qu’un test apparaît dans cette file d’attente, le serveur lance le test. Par exemple, chez Troopers les tests sont créés quand une demande de fusion (Merge Request) est ouverte dans GitLab.

Comme GitHub Actions, GitLab est en train de mettre en place un système de recettes réutilisables (les components) cependant cette fonctionnalité est encore en beta et nous n’avons pas encore tenté l’expérience. La documentation n’est pas très claire sur le résultat : est-ce que ça crée un ou plusieurs jobs sur la CI ?

[GitLab.com](https://about.gitlab.com/) (la plate-forme officielle) offre 500 minutes d‘utilisation par mois pour les projets privés.

## GitHub Actions et GitLab CI en pratique

Afin de montrer la configuration en pratique, nous avons créé un projet qui contient un fichier PHP simple avec une spécificité : l’extension intl est nécessaire pour que PHP puisse l’exécuter.

La CI aura 2 rôles :
- vérifier que le script peut être exécuté sans erreur
- vérifier que la syntaxe du script est correcte, grâce à l’outil PHP-CS-Fixer

Les deux services sont configurés via des fichiers YAML dont la syntaxe est assez similaire.




### Avec GitHub Actions

Fichier `.github/workflows/tests.yaml` : 

```yaml
name: Tests

on: [pull_request]

jobs:
  tests:
    name: Test
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup PHP, with extensions
        uses: shivammathur/setup-php@v2
        with:
          php-version: 8.2
          extensions: intl

      - name: Run tests
        run: php -f ./src/script.php
```

[source du script](https://github.com/Troopers/ci-playground/blob/ff973b2421a8abbb06566259b9179d19b7751ea9/.github/workflows/tests.yml)

Résultat dans une [_Pull Request_](https://github.com/Troopers/ci-playground/pull/1) :

Comme vous pouvez le constater, l’utilisation des actions existantes de GitHub permet de faire des opérations complexes avec quelques lignes de code pour décrire les paramètres qui seront passés aux Actions déjà existantes.

Le mot-clé `uses:` sert à appeler des Actions préexistantes. L’ajout de l’extension `intl` est simplifié au maximum grâce à l’action [shivammathur/setup-php](https://github.com/shivammathur/setup-php) qui gère les extensions PHP à notre place.


### Avec GitLab CI

Fichier `.gitlab-ci.yml` :

```yaml
stages:
  - install
  - tests
  - quality

variables:
  JAKZAL_IMAGE: jakzal/phpqa:1.96.3-php8.2-alpine

build-php:
  stage: install
  image: troopers/docker-images:docker-pip-docker-compose
  services:
    - docker:dind
  before_script:
    - echo -e "\e[0Ksection_start:`date +%s`:docker-login[collapsed=true]\r\e[0Kdocker login"
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
    - echo -e "\e[0Ksection_end:`date +%s`:docker-login\r\e[0K"
  script:
    - ./.gitlab/build-job-php
  only:
    - merge_requests

tests:
  stage: tests
  image: ${CI_REGISTRY}/${CI_PROJECT_PATH}/php:latest
  needs: [ 'build-php' ]
  only:
    - merge_requests
  script:
    - echo -e "\e[0Ksection_start:`date +%s`:tests\r\e[0Ktests"
    - php -f ./src/script.php
    - echo -e "\e[0Ksection_end:`date +%s`:0Ktests\r\e[0K"

php-cs-fixer:
  image: ${JAKZAL_IMAGE}
  stage: quality
  needs: [ ]
  only:
    - merge_requests
  script:
    - echo -e "\e[0Ksection_start:`date +%s`:php-cs-fixer\r\e[0KPHP-CS-Fixer"
    - php-cs-fixer --dry-run --diff --no-interaction --ansi fix --show-progress none
    - echo -e "\e[0Ksection_end:`date +%s`:0Kphp-cs-fixer\r\e[0K"
```

[source du script](https://gitlab.com/troopers-nantes/ci-playground/-/blob/847b1468a8d89c2adf5ff9d06b35992e162d9c42/.gitlab-ci.yml)

Résultat dans une [_Merge Request_](https://gitlab.com/troopers-nantes/ci-playground/-/merge_requests/1) :

Quant à GitLab, aucune recette externe n’est utilisée, chaque étape doit être définie dans le fichier de configuration. En contrepartie, on voit exactement les étapes qui vont être réalisées par GitLab, alors qu’avec GitHub Actions, il faut aller voir dans le code source de `shivammathur/setup-php@v2` si on veut comprendre ce qu’il se passe sous le capot lors de cette étape.

Afin de disposer d’un environnement PHP avec l’extension `intl`, on doit passer par plusieurs étapes :

1. construire une image Docker (notez qu’on fait un appel direct au programme `docker build`)
2. pousser l’image sur le _registry_ de GitLab
3. dans un second temps, récupérer l’image et lancer le test

Cela peut sembler contraignant, mais au final ça n’ajoute que 40 secondes dans le temps total de la CI (une fois que l’image a été construite, la CI ne la re-construit pas afin d’économiser du temps), ça fait peu de différence car nos CI tournent en moyenne pendant 10 minutes.

Alors qu’avec GitHub Actions, l’installation de l’extension intl n’a nécessité que 2 lignes de configuration. Nous espérons que les components de GitLab seront aussi performants que les actions de GitHub.

(note : il est aussi possible de lancer un conteneur Docker basé sur PHP puis d’installer l’extension `intl` à la volée, mais cette étape prendrait entre 2 et 3 minutes à chaque fois que la CI tourne, cela serait inefficace à long terme.)

Pour des explications complètes, nous vous invitons à voir les exemples d’un article précédent : https://www.troopers.coop/blog/votre-workflow-sous-steroides-avec-gitlab-ci

## Conclusion

GitHub Actions et GitLab CI sont des outils extrêmement puissants, on peut configurer toutes les opérations que l’on souhaite :
- lancer des batteries de tests
- vérifier notre propre code par des analyses statiques
- déployer des conteneurs Docker sur des serveurs Web
- compiler un projet React en site statique puis envoyer les fichiers sur un serveur Web
- générer un storybook et l’héberger via GitLab Pages, ce qui est plus rapide que de configurer un serveur Web
- déployer une application mobile via Expo EAS
- etc.

GitHub, avec son service Actions, offre une intégration fluide et de puissantes recettes prédéfinies qui réduisent significativement le temps et l'effort nécessaires à la configuration des environnements et à l'exécution des tests. GitLab, d’un autre côté, offre une transparence et un contrôle accrus sur les processus grâce à ses configurations détaillées, permettant aux équipes de comprendre et de gérer chaque étape du pipeline de CI/CD.


L'intégration continue en pratique

Chez Troopers, on gère le code source de nos projets grâce à git, c’est un logiciel de suivi de version. Cela permet à chaque personne travaillant sur un projet de récupérer le code source, d’y apporter des modifications puis de partager le résultat avec les autres personnes.

Il est possible d’utiliser git sans interface web, mais l’utilisation d’une plateforme en ligne présente de nombreux avantages : on peut facilement visualiser quels sont les changements apportés sur le code source, ajouter des commentaires ou suggérer des modifications et valider la liste des changements.

Il existe beaucoup d’acteurs fournissant ce service, et nous allons ici nous attarder sur deux d’entre eux que nous affectionnons particulièrement : GitHub et GitLab.

Nous allons voir comment nous tirons profit de ces services afin d’automatiser les tests et les contrôles qualité.


## CI et CD, qu’est-ce que c’est ?
L’Intégration Continue (Continuous Integration ou CI) est un ensemble de processus qui visent à automatiser l’exécution des tests et contrôles qualité d’un projet informatique.

Le déploiement continu (Continuous Delivery ou CD) est une pratique qui consiste à déployer les derniers développements d’un projet facilement en quelques clics ou de façon automatique.

Plutôt que de confier la responsabilité de ces actions à l’équipe de développement, on automatise ces méthodes, ce qui prévient tout oubli. Autre avantage : déployer fréquemment permet de rendre cette opération routinière : l’équipe prend l'habitude de déployer plus souvent, de plus petits incréments de code. Les bugs sont détectés plus tôt et corrigés plus vite.


Voici concrètement comment cela se passe : 
1. Le développeur ou la développeuse pousse son code vers GitHub ou GitLab et crée une demande de fusion
2. La CI est lancée automatiquement
3. Le résultat est affiché sur la page de la demande de fusions, il y a 2 cas possibles : 
- Un test a échoué, il peut s’agir d’une régression sur une fonctionnalité existante ou d’un comportement qui nécessite que le test soit mis à jour (par exemple si le texte attendu a été modifié) ; la fusion du code est bloquée, le code doit être modifié jusqu’à ce que les tests soient valides
- Tous les tests ont été réalisés avec succès ; la fusion du code est possible
4. Après la fusion du code sur la branche de développement, le code est directement déployé sur un environnement de test, grâce à la CD


## GitHub, la plateforme de référence
[GitHub](https://github.com/) a été créé en 2008, c’est un service commercial dont les sources sont fermées.

Son utilisation est gratuite pour les projets open source, et une version payante amène [différents avantages](https://github.com/pricing). Ce service est rapidement devenu le plus populaire des services d’hébergement de projets, éclipsant par exemple SourceForge et BitBucket. Nous l’utilisons toujours pour nos projets open source.

Malgré les qualités de ce service, de nombreux projets open source choisissent de ne pas utiliser GitHub afin de conserver la souveraineté des données et de ne pas être dépendant d’un écosystème qui dépend entièrement de la société GitHub. Cela amène plusieurs risques : GitHub peut changer ses conditions d’utilisation du jour au lendemain, par exemple en supprimant l’utilisation gratuite pour les projets open source ou bien en décidant unilatéralement qu’un projet n’est plus le bienvenu chez GitHub.

Il est possible de déployer sa propre instance de GitHub grâce à l‘offre GitHub Enterprise Server pour 21 $ / mois / utilisateur (plus les frais d’hébergement).

## GitLab, l'alternative open source
[GitLab](https://about.gitlab.com/) a été lancé en 2011, c’est un projet open source qui peut être utilisé de plusieurs façons : 
- L’instance principale gitlab.com, qui a des fonctionnalités gratuites et payantes comme GitHub
- D’autres instances hébergées par des prestataires externes
- En hébergeant sa propre instance de GitLab (auto-hébergement)

Chez Troopers nous l’utilisons depuis 2017 en auto-hébergement. Notre instance de GitLab tourne grâce à Docker, et nous avons effectué les mises à jour au fur et à mesure des années.

Nous n’avons rencontré qu’un seul souci lors d’une migration vers un nouveau format de stockage des données git. Malgré ce problème, Gitlab est un modèle du genre : de nombreux logiciels ont des processus de mise à jour plus complexes.

## Conclusion
Bien que chaque plateforme ait ses particularités, le choix entre GitHub et GitLab dépendra finalement des besoins spécifiques de l'équipe et du projet, ainsi que de la préférence pour un modèle plus ouvert ou plus intégré. Quelle que soit la plateforme choisie, l'automatisation apportée par ces outils peut considérablement accélérer le développement, améliorer la qualité du code, et permettre des déploiements plus fréquents et fiables.

Dans un prochain article, nous montrerons des exemples de mise en pratique d'intégration continue sur ces deux plateformes.

## Alternatives à GitHub et GitLab
- [Gitea](https://about.gitea.com/) : un logiciel léger qui nécessite moins de ressources matérielles que GitLab (cela peut par exemple tourner sur un Raspberry Pi) mais n’intègre pas de système de CI
- Codeberg : un fork de Gitea, voir [cet article chez LinuxFr](https://linuxfr.org/news/codeberg-la-forge-en-devenir-pour-les-projets-libres)

GitHub, GitLab et l’intégration continue

Après une formation à la Wild Code School où j’ai appris le métier de développeur web, avec un focus sur React en front, je suis arrivé chez Troopers pour un stage. J’ai très rapidement été mis dans le bain : Marie, une développeuse front, partait dans trois semaines et je devais l’aider à terminer ce qu’elle avait déjà bien entamé : finir de migrer le site de l’agence depuis Strapi v3 vers la v4 du cms, et créer tous les composants et pages du nouveau blog avec Next.js et TypeScript. Anciennement sur un autre domaine (slash.troopers.coop), ce blog est désormais intégré au site, entièrement redesigné et repensé.

Étant junior, j’ai encore tout à apprendre, de nombreux exemples feront probablement transparaître ce fait dans l’article qui vient. En voici un premier : j’ai cru Marie quand elle m’a dit « t'inquiètes, trois semaines c’est large ». 

## Le plus dur est fait

L’enjeu du projet était donc double : migrer sur Strapi v4 et créer le nouveau blog. La migration sur la v4 était bien avancée. Le repo était créé et configuré, la plupart du code ainsi que du contenu avait déjà été migré sauf quelques slices. Pour chacun d’eux il fallait : 
Créer le slice sur Strapi
Mettre à jour le fragment GraphQL du front
Mettre à jour le typage du front
Mettre à jour la structure de donnée du front
Mettre à jour le storybook (un outil permettant de documenter les composants d’un projet)
Mettre en place des éventuelles modifications de fonctionnement

Mettre à jour les fragments a été l’occasion de découvrir GraphQL et Apollo, des structures d’API. Je suis plusieurs fois resté perplexe devant des erreurs 400 d’origine diverses : typos, mauvaise structure de requête, requête d’un élément par encore créé ou qui a changé de nom, mais finalement rien de trop compliqué de ce côté là.
Concernant les typages, la logique de TypeScript est venue très vite, et je trouve déjà difficile de m’en passer. J’ai néanmoins réalisé trop tard qu’aucun de nos types ne tenait réellement compte du caractère obligatoire du champ dans Strapi, ce qui est dommageable car cela empêche TypeScript de me prévenir que tel ou tel composant va crasher si l’utilisateur oublie de remplir un champ. Heureusement Patrick le PO et Leticia la designeuse se sont chargés de vérifier ce qu’il se passe avec un bouton sans lien, ou une liste de logo sans logo : j’ai souvent dû ajouter des ternaires (des conditions de rendu).
Un jour je prévois de refaire une passe pour typer possiblement null ce qui doit l’être, et de rendre obligatoire dans Strapi les autres éléments. Un travail d’autant plus fastidieux que Strapi refuse de rendre obligatoire un champ si quelque part il existe vide dans un composant…

Nous avons aussi créé quelques nouveaux slices mais rien de trop complexe, et deux bonnes semaines après mon arrivée, j’avais déjà beaucoup appris sur GraphQL, Strapi, Next.js et TypeScript. Nous étions au bout de la migration du site existant, au bout du tunnel donc ?

Strapi v4 a bien chamboulé la manière dont les données étaient organisées, voici un exemple ci dessous de requêtes pour exactement le même élément:

```graphql
category {
       id
       name
       slug
       color
     }
```
```graphql
categories {
         data {
           id
           attributes {
             name
             color
            }
      }
}
```
_Pas tout à fait la même chose : si vous avez bien observé, le premier récupère une seule catégorie quand le second en récupère potentiellement plusieurs. Profitant de la migration, les fonctionnalité ont souvent évolué, ce qui a contribué à allonger le projet._

## Le blog

Marie part dans moins d’une semaine, il reste tout à créer pour le nouveau blog. Une nouvelle page article et plusieurs nouveaux slices pour cette page, créer la page d’accueil du blog qui affiche les articles, les pagine et les filtre et une fois ce travail terminé, intégrer les articles manuellement dans le nouveau CMS. On est large ?

Et bien, pas tant que ça, je me dis même qu’on risque d’avoir une ou deux semaines de retard si ça continue (douce innocence). L’intégration n’est pas terminée quand Marie part, je continue à un petit rythme. Je découvre que quand figma donne une épaisseur de 2px, un trait d’épaisseur 3px retourne directement de la colonne “à tester” vers la colonne “à faire”. Et que si ça marche en local mais pas sur la liseuse du PO ou le Tamagochi de la designeuse, ça ne marche pas.


Des choses qui aujourd’hui me paraissent plutôt simples sont entièrement nouvelles, et me prennent donc longtemps. Comment on crée une page déclinable en plusieurs versions dans Next.js ? Et dans Strapi ? Comment on pagine dans Strapi ? C’est quoi remark ? C’est mieux quand c’est saveur github ? Il faut aussi des miettes de pain ? Heureusement, Vincent l’autre développeur front prend le relais de Marie, relit mes PR et répond à mes questions.

Malgré le retard sur le projet, je reste optimiste. Chaque lundi, j’annonce en réunion que le site est presque prêt. Les choses avancent, et le gros œuvre sort de terre fin septembre : des pages, des composants fonctionnels, l’intégration peut commencer. Il ne reste plus que quelques finitions !

## Vous avez dit finitions ?

À mesure que la mise en prod approchait, j’ai été confronté à de nouvelles questions: notre site est-il accessible, éco-conçu, ses métas données se comportent-elles correctement ? Pourquoi mettre à jour un article ne re-rend pas toujours le contenu ? 
Leticia, qui a intégré une grande partie des contenus, et Patrick se sont mis à dénicher tout un tas d’anomalies, de bizarreries, d’approximations et nous nous sommes tous les trois lancés dans une valse de tickets. 
Gwenn, un développeur de l’agence, venait de terminer une formation sur l’accessibilité. Il a audité le blog et créé des dizaines de tickets, sur des sujets souvent  tout à fait nouveaux pour moi, afin de rendre ce blog aussi accessible que possible.
Enfin, avec Vincent qui relisait chacune de mes PR, et ne manquait pas de me faire chaque fois des retours instructifs, ainsi que des nouveaux projets sur lesquels j’ai commencé à travailler, la mise en ligne s’est retrouvée repoussée pendant encore plusieurs semaines.
J’ai par exemple passé un grand nombre d’heures le nez dans la doc de Next.js pour chercher à comprendre pourquoi le re-rendu était si lent et aléatoire après une modification dans le CMS de preprod. Spoiler : c’était la faute du cache d’apollo, une petite ligne a résolu le problème. 

```js
const defaultOptions: DefaultOptions = {
 watchQuery: {
   fetchPolicy: 'network-only',
 },
 query: {
   fetchPolicy: 'network-only',
 },
}
```
_Waow, 3j de boulot pour générer deux lignes d’options dans la configuration apollo, ça c’est de la productivité !_

Ou alors pour tenter de comprendre la différence entre getServerSideprops et getStaticProps.
Enfin, j’ai bataillé avec tout un tas de concepts nouveaux qui sont pourtant au cœur du travail du front : métadonnées, navigation au clavier, liens canoniques, balisage accessible, limitation des requêtes serveur…
Ce travail a payé, car le site est très bien noté en accessibilité (96 sur [https://pagespeed.web.dev](https://pagespeed.web.dev)) et en éco-conception (98 sur [https://kastor.green](https://kastor.green)). 

En parallèle, toute l’agence a mis la main à la patte pour copier coller les articles de blog dans le nouveau CMS. Les scripts de migration, et bien, disons que ça nous a semblé plus rapide de nous en passer. Grâce à cet effort collectif, nous avons mis en prod mi-novembre, avec seulement 10 semaines de retard sur le planning, youpi !


## Pour finir

Vous vous demandez si le jeu en valait la chandelle ? Vous pouvez juger par vous-même, vous lisez un article de blog sur la création d’un blog, sur le blog qui a servi à créer l’article de blog relatant la création du blog, dingue !
Pour ma part, j’ai beaucoup aimé commencer mon stage sur un projet interne, de petite envergure, basé sur des technos récentes, avec toujours quelqu’un pour apporter une réponse à mes questions. 
J’ai le sentiment d’avoir énormément appris. A la fin du projet, j’ai même pu quelques temps m’y sentir chez moi, afin d’arriver en pleine forme sur des nouveaux repos à la syntaxe étrange (vous dit Redux ?) et d’être de nouveau perdu.


Passer à Strapi v4 et créer un blog : mes premiers mois chez Troopers.

[Nous aimons utiliser Sylius](https://troopers.coop/expertises/sylius) comme plateforme pour développer des sites e-commerce, des sites de vente, des marketplaces, ou même des ERP !




C’est un excellent outil, très évolutif. Il est possible de modifier son fonctionnement en profondeur tout en conservant la puissance du framework et la possibilité de continuer à le mettre à jour pour bénéficier de nouvelles fonctionnalités.
Mais parfois, une modification anodine a des conséquences inattendues…

## L’apparition du problème

Lors d’un sprint récent sur un projet basé sur Sylius, Patrick le PO remonte une erreur lors de la modification d’un produit. Il n’arrive pas à valider la modification d’un produit alors que cela marchait auparavant.
Étrange, c’est le même formulaire qui permet la création et la mise à jour d’un produit. Il a été modifié il y a peu et des tests automatisés ont été mis en place.

Il n’y a pas à tergiverser, lorsque l’on cherche à modifier certains champs, le site remonte une erreur :
“Mise à jour impossible, Product a été modifiée précédemment” ou “Cannot update, the Product was previously modified” selon les préférences de langue.

Les tests automatisés n’ont pas détecté le problème : ils ne couvrent que la création du produit, pas sa modification.

## Que nous révèle cette erreur ?

En première approche, j’aime faire un rapide tour dans le code. En restant naïf on a parfois de bonnes surprises, et des réponses rapidement. Le message d’erreur semble suffisamment unique pour commencer par là.



Une recherche dans le code fait remonter que ce texte est associé à la clé de traduction “race_condition_error”.
Nouvelle recherche : cette clé n’est utilisée qu’au sein d’une exception spécifique à Sylius (RaceConditionException), elle-même est utilisée dans une seule classe : Sylius\Bundle\CoreBundle\Doctrine\ORM\Handler\ResourceUpdateHandler

Ouch ! Ça parle de Doctrine, qui fait l’interface entre notre code et la base de données. Dans ce contexte, une erreur de “race condition” signifie que le code ne parvient pas à déterminer dans quel ordre traiter une ou plusieurs demandes de mise à jour : la donnée en base peut être plus récente que la modification que l’on envoie.

Cela ne s’annonce pas trivial : il est temps d’identifier la modification qui a fait apparaître l’erreur.

## Comment trouver le commit coupable ?

On a identifié un champ qui génère l’erreur lors de la modification d’un produit. J’écris un test simple : créer un produit, puis tenter de modifier ce champ. Le test échoue car l’erreur apparaît.

Je vais remonter dans le temps à l’aide de GIT, l’outil de gestion de version que nous utilisons. Mon objectif : utiliser le test pour déterminer quel commit a fait apparaître l’erreur.

Je pourrais utiliser la commande [git bisect](https://git-scm.com/docs/git-bisect) qui remplit parfaitement ce rôle. Mais j’ai ma petite idée du commit “coupable” :
- Je remonte l’historique GIT juste avant le commit : le test passe.
- J’avance d’un commit, le test échoue. Parfait, c’est bien là que tout se joue !

## Identifier le problème

Dans ce commit, on a ajouté des champs sur deux entités : Product et ProductVariant.

- Product, vous l’aurez deviné, représente un produit.
- ProductVariant représente un produit particulier, avec ses propres options, sa propre tarification, voire son propre suivi des stocks.



En plus de l’ajout de ces champs, les formulaires ont été modifiés pour les afficher, et au passage intégrer le design du projet.

J’annule les modifications sur ProductVariant, et je retire les champs associés dans les formulaires. L’erreur est encore présente. Mauvaise pioche ?

Je recommence avec les modifications de l’entité Product… L’erreur persiste.

On a toujours la “RaceConditionException”, due à la mise à jour d’une entité en base de données. Or je viens d'annuler tout ce qui a changé dans le code qui concerne les entités Product et ProductVariant. Soit je suis entré dans la quatrième dimension, soit j’ai raté quelque chose.



Que reste t’il dans le commit ? Une innocente modification esthétique : nous n’affichons plus la gestion des stocks lors de l’édition du produit car c’est inutile pour ce projet.

Dans le doute, j’annule cette modification : l’erreur disparaît !

## La réponse, et le correctif

En supprimant l’affichage de la gestion des stocks, nous avons cassé l’édition des produits.

Comment est-ce possible ? Le formulaire en question ne présente que deux champs : *faut-il suivre les stocks* et si oui, *quel est le stock actuel*…

Et pourtant, un troisième champ est bien présent (mais invisible pour l’utilisateur) : la *version*. Il n’est pas obligatoire, mais son absence semble poser problème.
Je ne sais pas ce qu’est cette *version* de la variante. Avant de creuser cette piste : testons. 

Si je l’affiche (toujours invisible) mais sans rétablir la gestion des stocks, l’erreur ne réapparaît pas. Bingo, voici le correctif : rétablir le champ *version* dans le formulaire, bien qu’il ne soit pas visible.

## Mais, pourquoi ?

Ce système de version sur ProductVariant est présent pour éviter que plusieurs demandes de modifications simultanées ne rentrent en conflit. D’accord, mais pourquoi est-ce que le champ se retrouve enfoui avec la gestion des stocks, s’il est si important ?

Avec le système des stocks, il va y avoir une modification de la variante à chaque fois qu’un produit est vendu. Si deux clients achètent le même produit au même moment, ils vont tous deux demander une modification “stock -1” avec la même version : 
- Le système s'appuiera sur la donnée version pour n’autoriser qu’une modification.
- La seconde modification sera rejetée, puis retentée avec la nouvelle version : s’il reste du stock, l’achat sera également validé. Si non, pas de chance, le produit vient de passer en rupture de stock.

Comme le champ de formulaire est caché, il peut être généré n’importe où dans la page.
Bien que j’aurais préféré qu’il soit ajouté avec les champs cruciaux de la variante, je peux comprendre comment il s’est retrouvé associé aux champs de formulaire liés aux stocks…

## Le(s) mot(s) de la fin

Ce bug aura été l’occasion de creuser un peu plus loin dans notre connaissance du framework Sylius et de ses composants les moins apparents, comme le versionnage des entités.

Le problème peut sembler lunaire : des erreurs liées à Doctrine, la persistance en base, RaceConditionException. Mais l’approche de résolution montre encore une fois sa pertinence : reproduire l’erreur, réduire les modifications jusqu’à trouver l’élément déclencheur, étudier cet élément pour comprendre pourquoi il pose problème et comment corriger.

Comme à chaque fois qu’un bug échappe aux tests automatisés écrit par les développeurs, nous nous posons la question : avons-nous la bonne approche pour la rédaction des tests ?
Les tests sont nécessaires mais peuvent être chronophages (écriture, maintenance, exécution). Lorsque l'on travaille avec un framework, on cherche à tester “notre” code, pas celui du framework car il est déjà testé : c’est une perte de temps.
Ici, fallait il d’emblée un test automatisé sur la mise à jour, en plus de la création ? Sachant que le même code est concerné dans les deux cas, j’ai tendance à penser que non.
Par contre, maintenant que le bug a été rencontré, le test créé pour réussir à l’isoler et à le corriger va rester dans notre suite de tests. On a pu se faire surprendre une fois, mais pas deux !

Un bug cache parfois une occasion de mieux découvrir votre framework préféré

Accueil