Déployer plusieurs branches sur votre environnement de test

Dans le développement de logiciels, la phase de test peut constituer un goulot d'étranglement important. Les longs délais de validation et l'attente de la validation du client peuvent entraîner des retards dans la livraison et avoir un impact sur le calendrier global du projet. Cependant, le multi-build staging environments est apparu comme une solution précieuse à ces problèmes.

En offrant la possibilité de déployer plusieurs versions isolées en même temps, nous sommes en mesure d'offrir plusieurs avantages clés :

• donner au client tout le temps dont il a besoin pour réviser et valider une fonctionnalité
• pouvoir répéter plusieurs fois le processus de révision en introduisant tous les changements requis par le client avant de fusionner la branche des fonctionnalités avec la branche principale
• éviter de verrouiller un environnement entier juste pour permettre au client de valider une fonctionnalité
• accélérer l'identification des bugs car le champ d'application de la révision est limité à des modifications mineures.

Tous ces éléments combinés offrent aux développeurs une meilleure expérience et accélèrent le processus de validation du client, étant donné que plusieurs fonctionnalités peuvent être validées en même temps par plusieurs équipes.

Comment nous avons procédé

Afin de mettre cela en œuvre, nous devions trouver une solution pour les points suivants :

• route requests vers un build specifique
• environnement de build isolées
• disposer d'une seule ligne de commande pour gérer l'ensemble du déploiement (l'expérience nous montre que lorsque les processus sont complexes, les utilisateurs ont tendance à moins les utiliser).

Route requests vers un build spécifique

Pour pouvoir router les requêtes vers un build spécifique, nous avons utilisé Traefik.

Traefik est un reverse proxy, ce qui signifie qu'il est la porte d'entrée de votre plateforme. Il intercepte et route chaque requête entrante : il connaît toute la logique et toutes les règles qui déterminent quels services traitent quelles requêtes (en fonction du chemin, de l'hôte, des en-têtes, et ainsi de suite...).

L'avantage de Traefik est qu'il n'y a pas beaucoup de configuration à écrire.

Avec seulement quelques labels docker-compose sur les services, vous avez un puissant reverse-proxy qui gère le trafic de votre stack.

services:
  traefik:
    image: traefik
    networks:
      proxy: {}
    command:
      - "--logLevel=ERROR"
      - "--traefiklog.format=json"
      - "--defaultEntryPoints=http,https"
      - "--entryPoints=Name:http Address::80 Redirect.Regex:^http://((.+\\.)?staging\\.contoso\\.com/?(.*)) Redirect.Replacement:https://$$1"
      - "--entryPoints=Name:https Address::443 TLS"
      - "--docker"
      - "--docker.watch=true"
      - "--docker.swarmmode=true"
      - "--docker.exposedByDefault=false"
      - "--acme=true"
      - "--acme.entrypoint=https"
      - "--acme.httpchallenge.entrypoint=http"
      - "--acme.domains=*.staging.contoso.com"
      - "--acme.email=hello@knplabs.com"
      - "--acme.storage=/etc/traefik/acme/acme.json"
      - "--acme.acmelogging"
      - "--acme.onHostRule=false"
      - "--acme.dnsChallenge.provider=cloudflare"
      - "--acme.dnsChallenge.delayBeforeCheck=0"
      - ...
    ...

networks:
  proxy:
    external: true

Environnement de build isolés

Afin de pouvoir déployer des environnements de build isolées, nous avons défini un système de labels où, au moment du déploiement, nous attribuons un label qui est ensuite utilisé pour créer des réseaux et des stacks isolés.

services:
  frontend:
    image: nginx
    networks:
      default: {}
      proxy: {}
    deploy:
      labels:
        - "traefik.frontend.rule=Host:${STAGE_TAG}.staging.contoso.com"
        - "traefik.enable=true"
        - "traefik.frontend.entryPoints=http,https"
        - "traefik.backend=${STAGE_TAG}-frontend"
        - "traefik.port=80"
        - "traefik.docker.network=proxy"
	  ...
    ...
  ...

networks:
  default:
    attachable: true
  proxy:
    external: true

Commande de déploiement en une seule ligne
Afin d'améliorer au maximum l'expérience des développeurs, nous avons créé une commande en ligne unique qui prend en charge la configuration et le déploiement d'un environnement de build isolé.

/bin/deploy-staging-build feature-1

Ce script se charge de faire les choses suivantes :

• construire des images Docker
• pousser les images Docker sur le dépôt
• initialiser tous les dossiers nécessaires sur le serveur distant et copier tous les fichiers nécessaires (docker compose, scripts, etc...)
• configurer les variables d'environnement par défaut (vous pouvez ajouter une étape pour les demander au cas où vous en auriez besoin)
• créer les réseaux isolés
• déployer les services
• exécuter les procédures de post-déploiement (initialisation de la base de données, etc...)
  Une fois le script terminé, la nouvelle étape de build sera accessible via "https://feature-1.staging.contoso.com".

Conclusions

L'environnement de test multi-build est devenu un outil essentiel dans notre flux de travail de développement de logiciels, offrant un moyen de faciliter le processus de review et de s'assurer que les produits développés sont de la plus haute qualité. En permettant aux clients d'examiner et de valider le travail à leur propre rythme, en éliminant la nécessité de verrouiller les environnements et en améliorant l'identification des problèmes et la collaboration, les environnements de test multi-build offrent des avantages significatifs qui peuvent contribuer à améliorer le processus de développement global.

🧐 Vous avez aimé cet article ? Celui-ci pourrait vous intéresser https://knplabs.com/fr/blog/comment-dockeriser-un-projet-symfony/

De plus, nous proposons de nombreuses formations afin de partager notre expérience et d'aider d'autres développeurs à créer d'excellentes applications web ou mobiles ! Jetez-y un coup d'œil et contactez-nous ici https://knplabs.com/fr/services/trainings