Up(sun) est opérationnel avec plusieurs applications

On est là pour t'expliquer comment héberger et configurer tes différents projets d'applications sur Upsun Cloud grâce à ce guide étape par étape. L'objectif, c'est de permettre à ton équipe de se concentrer davantage sur la création d'expériences utilisateur incroyables et moins sur la gestion de l'infrastructure multi-applications — tout en te donnant quelques conseils de développement multi-applications au passage.

On va aborder ça du point de vue d’un client à la recherche d’un hébergement multi-applications avec quelques contraintes spécifiques. Ces contraintes sont les suivantes :

• Un backend utilisant le composant API Platform Admin
• Un front-end existant, hébergeant une API et un front-end d’entreprise, développé avec Symfony 6.2
• Un front-end en marque blanche développé avec Gatsby, qui utilise l’API « Legacy »
• Un serveur Mercure Rocks à des fins marketing (notifications push)
• Toutes les sources du client sur un dépôt GitHub public

Comment commencer à héberger ton projet multi-applications avec Upsun Cloud

Créer un fork du dépôt multi-applications BigFoot

Pour pouvoir suivre les étapes suivantes de ce processus, tu dois d’abord créer ton propre dépôt — un fork — à partir d’un exemple d’Upsun Cloud. Pour ça, il te suffit de suivre les étapes décrites dans cet article GitHub pour créer un fork de notre projet multi-applications BigFoot vers ta propre organisation GitHub. Ce projet multi-applications BigFoot dispose d’un backend utilisant API Platform, d’un frontend + API utilisant Symfony, d’un frontend en marque blanche utilisant Gatsby et d’un serveur Mercure Rocks.

Une fois ton fork créé, clone-le localement et ouvre-le dans ton environnement de développement intégré (IDE) préféré.

git clone https://github.com/<YourOrgName>/upsun_multi-app-example bigfoot-multiapp
cd bigfoot-multiapp

N’oublie pas ensuite de remplacer la valeur <YourOrgName> par le nom de ta propre organisation GitHub.

Configure ton projet

Pour héberger ton projet multi-applications sur Upsun Cloud, un fichier de configuration YAML — config.yaml—est nécessaire dans ton code source pour gérer le comportement de ton application. Ce fichier de configuration YAML se trouve dans un .upsun/ dossier, à la racine de ton code source, dont l’architecture ressemblera à ceci :

bigfoot-multiapp
├── .upsun
│   └── config.yaml
└── <project sources>

Pour configurer ton projet multi-applications, voici quelques règles de base :

1. Le format YAML est utilisé pour les fichiers de configuration.
2. Le dossier .upsun/, qui contient un fichier config.yaml avec la configuration du routage, des services et des applications partagée par toutes les applications, doit rester à la racine de ton projet.
3. Chaque application se trouve dans un dossier dédié :
   • admin : composant d'administration de la plateforme API
   • api : API BigFoot et front-end par défaut
   • gatsby : interface utilisateur Gatsby
   • mercure : serveur Mercure Rocks

La configuration YAML d'Upsun se trouve dans le .upsun/ dossier et peut être remplie automatiquement à l’aide de la upsun project:init commande ci-dessous :

├── .upsun
│   └── config.yaml
└── <project sources>

Cette commande a généré un .upsun/config.yaml fichier, en fonction de ta stack locale, et il contient 3 clés YAML de premier niveau :

• applications: celle-ci contient la liste des définitions de tes applications
• services: ça contient la liste des définitions de tes services
• routes: elle contient la liste des définitions de tes routes

Crée le fichier .upsun/config.yaml

Pour configurer ton projet, tu dois d'abord créer un nouveau .upsun/config.yaml fichier contenant les clés YAML de premier niveau suivantes :

# .upsun/config.yaml
applications:
services:
routes: 

Ensuite, valide ton fichier nouvellement configuré :

git add .upsun/config.yaml
git commit -m "init Upsun configuration"
git push

Maintenant, configurons nos quatre applications une par une :

Configurer l'application API

Tout d’abord, on doit configurer la applicationsclé de premier niveau en fonction du comportement de notre application Symfony BigFoot, nommée api.

# .upsun/config.yaml
# Complete list of all available properties: https://docs.upsun.com/create-apps/app-reference.html
applications:
  # A unique name for the app
  api:
    # Information on the app's source code and operations that can be run on it.
    source:
      # The path where the app code lives. Defaults to the directory of the .upsun/config.yaml file. Useful for multi-app setups.
      root: api
    # The runtime the application uses.
    type: php:8.3
    # The relationships of the application with services or other applications.
    relationships:
      database: "database:postgresql"
    # Mounts define directories that are writable after the build is complete. If set as a local source, disk property is required.
    mounts:
      "/var/cache": { source: storage, source_path: files/cache  }
      "/var/log": { source: storage, source_path: files/log  }
      "/var/sessions": { source: storage, source_path: files/sessions  }
      "/data": { source: storage, source_path: files/data  }
    # The web key configures the web server running in front of your app.
    web:
      # Each key in locations is a path on your site with a leading /.
      locations:
        "/":
          root: "public"
          passthru: '/index.php'
          index:
            - index.php
          scripts: true
          allow: true
          headers:
            Access-Control-Allow-Origin: "*"
    # Variables to control the environment.
    variables:
      env:
        APP_ENV: 'prod'
      php:
        assert.active: off
        #opcache.preload: config/preload.php
    # Specifies a default set of build tasks to run. Flavors are language-specific.
    build:
      flavor: composer
    # Installs global dependencies as part of the build process.
    # Hooks allow you to customize your code/environment as the project moves through the build and deploy stages
    hooks:
      # The build hook is run after any build flavor.
      build: |
        set -x -e
        curl -s https://get.symfony.com/cloud/configurator | bash
        symfony-build
      # The deploy hook is run after the app container has been started, but before it has started accepting requests.
      deploy: |
        set -x -e
        symfony-deploy
    # Scheduled tasks for the app.
    crons:
      update-sighting:
        spec: '*/5 * * * *'
        cmd: './bin/console app:update-sighting-scores'
      security-check:
        # Check that no security issues have been found for PHP packages deployed in production
        # See https://github.com/fabpot/local-php-security-checker
        spec: '50 23 * * *'
        cmd: if [ "$PLATFORM_ENVIRONMENT_TYPE" = "production" ]; then croncape php-security-checker; fi
    # Customizations to your PHP or Lisp runtime.
    runtime:
      extensions: [ ctype, iconv, apcu, mbstring, sodium, xsl, pdo_pgsql ]

Tu as sans doute remarqué que notre api application a une relation avec un service appelé database, comme le montre la configuration YAML ci-dessous. Ça veut dire qu’on doit déclarer ce service database.

applications:
  api:
    ...
    relationships:
      database: "database:postgresql"

Toujours dans le même .upsun/config.yaml fichier, définissons ce service dans la services clé YAML de niveau supérieur :

# .upsun/config.yaml
applications:
  api: ...
# The services of the project.
#
# Each service listed will be deployed
# to power your Upsun project.
# More information: https://docs.upsun.com/add-services.html
# Full list of available services: https://docs.upsun.com/add-services.html#available-services
services:
  database:
    type: postgresql:15

Enfin, on doit définir le routage de notre application API dans ce même .upsun/config.yaml fichier. Pour ça, ajoute ce qui suit :

# .upsun/config.yaml
applications:
  api: …
services: …
routes:
  # BigFoot API
  https://{default}:
    type: upstream
    # the first part should be your project name
    upstream: "api:http"
    id: api

Ensuite, il faut configurer les variables d'environnement spécifiques à Upsun Cloud pour l'application API. Crée un fichier api/.environment. Une fois créé, ce fichier sera pris en compte dans l'environnement de l'application.

# api/.environment
export N_PREFIX=$HOME/.n
export PATH=$N_PREFIX/bin:$PATH

# Set dynamic CORS_ALLOW_ORIGIN for NelmioBundle
export CORS_ALLOW_ORIGIN=.*$(echo $PLATFORM_PROJECT)..*.platformsh.site
export TRUSTED_HOSTS=.*$(echo $PLATFORM_PROJECT)..*.platformsh.site
export TRUSTED_PROXIES=.*$(echo $PLATFORM_PROJECT)..*.platformsh.site

# Admin Site Name
export API_SITE_NAME="API Platform"

export APP_SECRET=$(echo $PLATFORM_PROJECT_ENTROPY)

# Mercure Rocks uri
export MERCURE_URL=$(echo $PLATFORM_ROUTES | base64 --decode | jq -r 'to_entries[] | select(.value.id == "mercure") | .key'| awk '{print substr($0, 0, length($0))}')
export MERCURE_PUBLIC_URL=$(echo $PLATFORM_ROUTES | base64 --decode | jq -r 'to_entries[] | select(.value.id == "mercure") | .key'| awk '{print substr($0, 0, length($0))}')
export MERCURE_PUBLISH_URL=$(echo $PLATFORM_ROUTES | base64 --decode | jq -r 'to_entries[] | select(.value.id == "mercure") | .key'| awk '{print substr($0, 0, length($0))}')

# The secret used to sign the JWTs
export MERCURE_JWT_SECRET="!ChangeThisMercureHubJWTSecretKey!"

Tu peux ensuite valider ton fichier de configuration dans ton dépôt Git :

git add .upsun/config.yaml api/.environment
git commit -m "adding api configuration for Upsun"
git push

Configurer l’application Admin

Ensuite, on doit configurer la applications clé de niveau supérieur avec le comportement de notre composant Admin de la plateforme API, nommé admin. Pour configurer ton application d'administration, ajoute le applications.admin bloc dans ton .upsun/config.yaml fichier :

# .upsun/config.yaml
applications:
  api: …
  # A unique name for the app
  admin:
    # Information on the app's source code and operations that can be run on it.
    source:
      # The path where the app code lives. Defaults to the directory of the .upsun/config.yaml file. Useful for multi-app setups.
      root: admin
    # The runtime the application uses.
    type: nodejs:20
    # How many resources to devote to the app. If not set, default to the predefined runtime definition.
    # For more information, please see https://docs.upsun.com/manage-resources/adjust-resources.html#advanced-container-profiles
    container_profile: BALANCED
    # Mounts define directories that are writable after the build is complete. If set as a local source, disk property is required.
    mounts:
      '/.tmp_platformsh': { source: "storage", source_path: "files/tmp_platformsh" }
      '/build': { source: "storage", source_path: "files/build" }
      '/.cache': { source: "storage", source_path: "files/.cache" }
      '/node_modules/.cache': { source: "storage", source_path: "files/node_modules/.cache" }
    # The web key configures the web server running in front of your app.
    web:
      # Each key in locations is a path on your site with a leading /.
      locations:
        "/admin":
          root: "build"
          passthru: "/admin/index.html"
          index:
            - "index.html"
          expires: 300s
          scripts: true
          allow: false
          rules:
            .(css|js|gif|jpe?g|png|ttf|eot|woff2?|otf|html|ico|svg?)$:
              allow: true
            ^/admin/robots.txt$:
              allow: true
            ^/admin/manifest.json$:
              allow: true
            ^/admin/_next:
              allow: true
            ^/admin/sitemap:
              allow: true
          headers:
            Access-Control-Allow-Origin: "*"
    # Variables to control the environment.
    variables:
      env:
        NODE_OPTIONS: '--max-old-space-size=1536'
    # Specifies a default set of build tasks to run. Flavors are language-specific.
    build:
      flavor: none
    # Hooks allow you to customize your code/environment as the project moves through the build and deploy stages
    hooks:
      # The build hook is run after any build flavor.
      build: |
        set -eu
        corepack yarn install --immutable --force
      # The post_deploy hook is run after the app container has been started and after it has started accepting requests.
      post_deploy: |
        corepack yarn build

Comme tu l'as sans doute remarqué, le applications.admin.web.locations est défini sur /admin. Ça veut dire que l’admin sera accessible sur <defaultUrl>/admin. On doit définir la route correspondante dans le même .upsun/config.yaml fichier, dans la routes clé YAML de niveau supérieur :

applications:
  api: ...
  admin: ... 
services: ...
routes:
  # BigFoot API
  https://{default}: …
 
  # API Platform Admin component
  https://{default}/admin:
    type: upstream
    # the first part should be your project name
    upstream: "admin:http"
    id: "admin"
    cache:
      cookies: [ '*' ]
      default_ttl: 0
      enabled: true
      headers: [ Accept, Accept-Language ]
    ssi:
      enabled: false

Ensuite, il faut configurer les variables d'environnement spécifiques à Upsun pour l'application d'administration, qui utilise l'outil jq préinstallé. Crée un fichier admin/.environment.

# admin/.environment
export REACT_APP_PUBLIC_URL=$(echo $PLATFORM_ROUTES | base64 --decode | jq -r 'to_entries[] | select(.value.id == "api") | .key')api
export PUBLIC_URL=$(echo $PLATFORM_ROUTES | base64 --decode | jq -r 'to_entries[] | select(.value.id == "admin") | .key')

# Admin Site Name
export REACT_APP_ADMIN_SITE_NAME="Admin API Upsun"

Tu peux ensuite valider ton fichier de configuration dans ton dépôt Git :

git add .upsun/config.yaml admin/.environment
git commit -m "adding admin configuration for Upsun"
git push

Configurer l'application Gatsby

Troisièmement, on doit configurer la applications' clé de niveau supérieur avec le comportement de notre interface utilisateur en marque blanche — nommée gatsby—développée à l’aide de la stack Gatsby.

# .upsun/config.yaml
applications:
  api: ...
  admin: ...
  
  # A unique name for the app
  gatsby:
    # Information on the app's source code and operations that can be run on it.
    source:
      # The path where the app code lives. Defaults to the directory of the .upsun/config.yaml file. Useful for multi-app setups.
      root: gatsby
    # The runtime the application uses.
    type: 'nodejs:20'
    # How many resources to devote to the app. If not set, default to the predefined runtime definition.
    # For more information, please see https://docs.upsun.com/manage-resources/adjust-resources.html#advanced-container-profiles
    container_profile: BALANCED

    # Mounts define directories that are writable after the build is complete. If set as a local source, disk property is required.
    mounts:
      '/.cache': { source: "storage", source_path: "cache" }
      '/.config': { source: "storage", source_path: "config" }
      '/public': { source: "storage", source_path: "public" }
    # The web key configures the web server running in front of your app.
    web:
      # Each key in locations is a path on your site with a leading /.
      locations:
        '/site':
          root: 'public'
          index: [ 'index.html' ]
          scripts: false
          allow: true
    # Variables to control the environment.
    variables:
      env:
       NODE_OPTIONS: --max-old-space-size=1536
    # Specifies a default set of build tasks to run. Flavors are language-specific.
    build:
      flavor: none
    # Installs global dependencies as part of the build process.
    dependencies:
      nodejs:
        yarn: "1.22.17"
   # Hooks allow you to customize your code/environment as the project moves through the build and deploy stages
    hooks:
      # The build hook is run after any build flavor.
      build: |
        set -e
        yarn --frozen-lockfile
      # The post_deploy hook is run after the app container has been started and after it has started accepting requests.
      post_deploy: |
        yarn build --prefix-paths

Comme tu l'as sans doute remarqué, le applications.gatsby.web.locations est défini sur /site. Ça veut dire que Gatsby sera accessible sur <defaultUrl>/site et on doit définir la route correspondante dans le même .upsun/config.yaml fichier, dans la routes clé YAML de niveau supérieur :

applications:
  api: ...
  admin: ... 
services:
  ...
routes:
  # BigFoot API
  https://{default}: ... 
  # API Platform Admin component
  https://{default}/admin: ...

  # Gatsby App
  https://{default}/site:
    type: upstream
    # the first part should be your project name
    upstream: "gatsby:http"

L' gatsby application utilise notre API REST BigFoot. Si tu regardes le gatsby code source, dans le gatsby/gatsby-config.js fichier, tu trouveras l'itinéraire vers ton api application en utilisant process.env.PLATFORM_ROUTES ce qui signifie qu’on n’a pas besoin d’un gatsby/.environment fichier pour trouver cette route. Tu peux ensuite valider ton fichier de configuration dans ton dépôt Git :

git add .upsun/config.yaml 
git commit -m "adding gatsby configuration for Upsun"
git push

Configurer l’application Mercure

Le composant API Platform Admin, développé par Les Tilleuls, communique avec un serveur Mercure.rocks — une stack GO utilisée pour la communication push en temps réel. On doit configurer la applications clé de niveau supérieur avec le comportement d’un serveur Mercure.rocks autonome, nommé mercure.

# .upsun/config.yaml
applications:
  api: ...
  admin: ...
  gatsby: ...
 
  # A unique name for the app
  mercure:
    # Information on the app's source code and operations that can be run on it.
    source:
      # The path where the app code lives. Defaults to the directory of the .upsun/config.yaml file. Useful for multi-app setups.
      root: mercure/.config
    # The runtime the application uses.
    type: golang:1.21
    # Mounts define directories that are writable after the build is complete. If set as a local source, disk property is required.
    mounts:
      "database": { source: "storage", source_path: "database" }
      "/.local": { source: "storage", source_path: ".local" }
      "/.config": { source: "storage", source_path: ".config" }
    # The web key configures the web server running in front of your app.
    web:
      # Commands are run once after deployment to start the application process.
      commands:
        # The command to launch your app. If it terminates, it's restarted immediately.
        start: ./mercure run --config Caddyfile.upsun
    # Each key in locations is a path on your site with a leading /.
    locations:
      /:
        passthru: true
        scripts: false
        allow: true
        request_buffering:
          enabled: false
        headers:
          Access-Control-Allow-Origin: "*"
    # Variables to control the environment.
    variables:
      env:
        MERCUREVERSION: 0.14.4
        SERVER_NAME: ":8888"
        MERCURE_TRANSPORT_URL: "bolt:///var/run/mercure.db?size=1000&cleanup_frequency=0.5"
        MERCURE_EXTRA_DIRECTIVES: |
          cors_origin *
          publish_origins *
          subscriptions
          demo
        GLOBAL_OPTIONS: |
          auto_https off
        MERCURE_PUBLISHER_JWT_KEY: "!ChangeThisMercureHubJWTSecretKey!"
        MERCURE_SUBSCRIBER_JWT_KEY: "!ChangeThisMercureHubJWTSecretKey!"
    # Specifies a default set of build tasks to run. Flavors are language-specific.
    build:
      flavor: none
    # Hooks allow you to customize your code/environment as the project moves through the build and deploy stages
    hooks:
      # The build hook is run after any build flavor.
      build: |
        # Install Mercure using cache
        FILE="mercure_${MERCUREVERSION}_Linux_x86_64.tar.gz"
        if [ ! -f "$PLATFORM_CACHE_DIR/$FILE" ]; then
          URL="https://github.com/dunglas/mercure/releases/download/v${MERCUREVERSION}/$FILE"
          wget -O "$PLATFORM_CACHE_DIR/$FILE" $URL
       else
         echo "Found $FILE in cache, using cache"
       fi
       file $PLATFORM_CACHE_DIR/$FILE
       tar xvzf $PLATFORM_CACHE_DIR/$FILE

Pour le routage de l’application Mercure, on va utiliser un sous-domaine de l’URL par défaut de ton environnement (pour permettre la découverte du routage Upsun). Ça veut dire que l’application Mercure sera accessible sur mercure.<defaultUrl>.

On doit donc définir la route correspondante dans le même .upsun/config.yaml fichier, dans la routes clé YAML de premier niveau :

applications:
  api: ...
  admin: ... 
  gatsby: ... 
  mercure: ... 
services: ...
routes:
  # BigFoot API
  https://{default}: ... 
  # API Platform Admin component
  https://{default}/admin: ...
  # Gatsby App
  https://{default}/site: ...
 
  # Mercure Rocks app
  https://mercure.{default}:
    type: upstream
    # the first part should be your project name
    upstream: "mercure:http"
    cache:
      enabled: false

Tu peux ensuite valider ton fichier de configuration dans ton dépôt Git :

git add .upsun/config.yaml 
git commit -m "adding mercure configuration for Upsun"
git push

Et voilà, ton projet est prêt à être poussé vers Upsun ! Tu peux consulter le résultat final d'un .upsun/config.yaml fichier ici à titre de référence.

Créer un projet Upsun Cloud

La prochaine étape pour configurer ce projet multi-applications sur Upsun Cloud consiste à créer un projet, ce qui est très simple à faire via la Console. Sur la page d’accueil de ta Console (tous les projets), dans le coin en haut à droite, clique sur le bouton « Créer un projet », comme indiqué ci-dessous :

Si tu n’as pas encore créé d’organisation dans laquelle placer le projet, tu seras d’abord invité à en créer une. Une fois que c’est fait, sélectionne cette organisation dans le menu déroulant, puis choisis « Synchroniser ton dépôt GitHub avec Upsun », comme indiqué sur l’écran ci-dessous :

Sélectionne ensuite « Se connecter à GitHub » parmi les options proposées, comme indiqué ici :

Dans le formulaire suivant qui s’affiche, comme sur la capture d’écran ci-dessous, sélectionne ton organisation GitHub dans le premier menu déroulant, puis clique sur « Installer et autoriser » et remplis les identifiants GitHub. Tu devras sélectionner ton organisation GitHub, le dépôt GitHub que tu as créé précédemment ainsi que la branche de production, puis cliquer sur « Continuer ».

Tu seras ensuite redirigé vers la troisième étape de cette configuration — comme illustré ci-dessous — où tu devras renseigner diverses informations, notamment le nom du projet, le nom de l’environnement et la région. Une fois que tu auras terminé, clique sur « Créer un projet ».

Sur la page suivante, pendant que le processus de création du projet se déroule en arrière-plan, tu verras à gauche des instructions de configuration supplémentaires, si tu en as besoin. À droite, tu peux suivre le déroulement de la création du projet et tu seras informé dès qu’elle sera terminée, comme le montre l’écran ci-dessous :

Une fois ton projet créé, le processus d'intégration GitHub déploiera automatiquement ton application à partir du code source de ton dépôt GitHub. Attends que l'intégration ait terminé le déploiement ; les informations relatives à ton application s'afficheront alors, comme tu peux le voir dans l'exemple ci-dessous :

C’est le moment de déployer, non ?

Et voilà, c’est l’heure du déploiement ! Mais attends…

Comme tu t’es déjà assuré que ton code source était compatible avec Upsun dans la section de configuration du projet de ce guide, ton projet aura été déployé automatiquement lors de sa création et ton application sera déjà en ligne, sans qu’aucun déploiement ne soit nécessaire. Découvre l’URL de ton nouveau projet en bas de l’interface de la console.

L'étape suivante consiste à accéder à la console de ton projet en cliquant sur le bouton « Afficher le projet » en bas de la page de configuration, et voilà, ton projet multi-applications est en ligne et tu peux commencer à l'explorer et à y ajouter plein de nouvelles fonctionnalités géniales !

Configurer un accès à distance vers ton projet Upsun Cloud

Pour faciliter l’interaction entre ton terminal et ton projet Upsun, tu dois configurer un accès distant à l’aide de cette commande CLI :

upsun project:set-remote <projectID>

upsun project:list

Remplis la base de données

L'application Bigfoot (application API) contient des données de test qui peuvent être importées dans la base de données. Pour ce faire, exécute les commandes suivantes :

upsun ssh --app=api "php bin/console d:s:u --dump-sql --force"
upsun ssh --app=api "php bin/console d:f:load -e dev"

Afficher les sites déployés

Ton projet comportant plusieurs applications est désormais en ligne et tu devrais le tester. Pour ouvrir l’un de tes sites web, tu peux soit utiliser l’interface de la console, soit utiliser la commande CLI suivante, puis choisir l’une des routes répertoriées :

upsun environment:url

Créer un environnement de préproduction

Pour créer un nouvel environnement dans notre projet, on doit créer une nouvelle branche Git, la pousser vers le dépôt GitHub, puis le processus d’intégration GitHub créera automatiquement l’environnement. Pour ça, exécute les commandes suivantes :

git checkout -b staging
git push --set-upstream origin staging

N’oublie pas que chaque fois que tu crées et pousses une nouvelle branche Git, l’intégration GitHub génère un nouvel environnement inactif au sein de ton projet Upsun. Comme l’environnement est inactif par défaut, tu dois l’activer pour le déployer en procédant comme suit :

upsun environment:info type staging
upsun environment:activate staging

Créer un environnement de développement

Il est maintenant temps de créer un nouvel environnement de développement en créant une nouvelle branche Git à partir de l’environnement de préproduction, comme suit :

git checkout -b dev
git push --set-upstream origin dev

N’oublie pas que chaque fois que tu crées et pousses une nouvelle branche Git, l’intégration GitHub génère un nouvel environnement inactif au sein de ton projet Upsun Cloud. Comme cet environnement est inactif par défaut, tu dois l’activer pour le déployer :

upsun environment:info type development
upsun environment:activate dev

Et les guides Git ne s’arrêtent pas là : reste à l’écoute pour notre prochain article sur les sous-modules Git, à paraître très bientôt. Reste informé de nos dernières actualités sur nos réseaux sociaux et nos canaux communautaires : Dev.to, Reddit et notre communauté.