Processus de publication rationalisé pour une application Web : développement basé sur le tronc avec indicateurs de fonctionnalités

Dans cet article, nous présenterons un processus de publication robuste et efficace pour les applications Web, construit autour d'un développement basé sur le tronc et d'indicateurs de fonctionnalités basés sur l'environnement. Cette méthodologie garantit une intégration continue, des tests faciles en production et un parcours fluide du développement à la version tout en maintenant des normes de qualité élevées.

---

Principes fondamentaux

1. Développement basé sur les troncs :

   • La branche principale sert de source unique de vérité pour tous les travaux de développement.
   • Les développeurs créent des branches de fonctionnalités (par exemple, feature/xyz) à partir du tronc pour les nouvelles fonctionnalités ou les tickets Jira.
   • Les demandes d'extraction (PR) sont soumises à partir de ces branches de fonctionnalités au tronc pour examen et fusion après des tests réussis.

2. Drapeaux de fonctionnalités basés sur l'environnement :

   • Les indicateurs de fonctionnalités sont utilisés pour contrôler l'activation des fonctionnalités dans les environnements.
   • Les indicateurs sont stockés dans des fichiers de configuration spécifiques à l'environnement ou dans le cadre de la configuration du pipeline CI/CD.
   • Dans la branche tronc, tous les indicateurs de fonctionnalités sont définis sur OFF par défaut.
   • Les indicateurs peuvent être activés ON dans des environnements spécifiques (par exemple, bac à sable, préparation ou production) selon les besoins.

---

Versions JIRA en Sprint

---

Flux de déploiement de l'environnement

1. Bac à sable ou environnement de test :

   • Pour les tests d'assurance qualité et d'intégration, les équipes peuvent créer une branche préfixée par sandbox/ (par exemple, sandbox/xyz) à partir du tronc.
   • Cette branche est déployée dans un bac à sable dédié ou un environnement de test à l'aide de pipelines CI/CD.
   • Les équipes d'assurance qualité peuvent valider les nouvelles fonctionnalités et les tests d'intégration peuvent garantir la compatibilité.
   • Les indicateurs de fonctionnalités sont activés ON dans cet environnement pour tester des fonctionnalités spécifiques.

2. Préparation de la sortie de production :

   • Pour préparer une release, créez une branche release/xyz à partir du tronc.
   • La branche release/xyz sert de release candidate et est initialement déployée sur 5 % du trafic de production pour les tests bêta.
   • Les indicateurs de fonctionnalités pour les nouvelles fonctionnalités sont activés ON dans cette branche pour permettre les tests en production.
   • Nginx ou un équilibreur de charge similaire peut gérer cette répartition du trafic, garantissant que seul un sous-ensemble d'utilisateurs voit les modifications.

---

Drapeaux de fonctionnalités : exemples et utilisation

1. Structure du drapeau :

   • Stockez les indicateurs de fonctionnalité dans un fichier de configuration (par exemple, config/feature-flags.json) :

    {
      "feature_xyz": false,
      "feature_abc": true
    }
   

• Utilisez des variables d'environnement pour contrôler les indicateurs pendant l'exécution :
  

   FEATURE_XYZ=true FEATURE_ABC=false npm start
  

1. Exemple de back-end :

   • Activer les drapeaux dans le code :

    const featureFlags = require('./config/feature-flags');
   
    if (featureFlags.feature_xyz) {
        console.log('Feature XYZ is enabled!');
    } else {
        console.log('Feature XYZ is disabled.');
    }
   

2. Exemple d'interface :

   • Utilisez des indicateurs pour afficher de manière conditionnelle les composants de l'interface utilisateur :

    if (process.env.REACT_APP_FEATURE_XYZ === 'true') {
        render(<NewFeatureComponent />);
    } else {
        render(<OldFeatureComponent />);
    }
   

3. Basculer les indicateurs pendant les tests :

   • Pour activer un indicateur de test, mettez à jour les variables de configuration ou d'environnement et redémarrez le service concerné (frontend ou backend) :

    FEATURE_XYZ=true npm start
   

• Pour les pipelines CI/CD, assurez-vous que les valeurs d'indicateur appropriées sont injectées dans l'environnement lors du déploiement.

---

Tests en production

1. Routage du trafic pour les tests bêta :

   • Utilisez les configurations Nginx pour contrôler l'allocation du trafic :

    http {
        upstream stable_backend {
            server stable_backend_1;
            server stable_backend_2;
        }
   
        upstream canary_backend {
            server canary_backend_1;
            server canary_backend_2;
        }
   
        upstream mixed_backend {
            server stable_backend_1 weight=45;
            server stable_backend_2 weight=45;
            server canary_backend_1 weight=5;
            server canary_backend_2 weight=5;
        }
   
        server {
            listen 80;
            server_name my-app.example.com;
   
            location / {
                if ($http_x_qa_test = "true") {
                    proxy_pass http://canary_backend;
                    break;
                }
   
                proxy_pass http://mixed_backend;
            }
        }
    }
   

• Acheminez 5 % du trafic de production vers les serveurs exécutant la nouvelle version en ajustant les poids des équilibreurs de charge.

1. Tests d'assurance qualité dédiés en production :
   • Les équipes d'assurance qualité peuvent joindre un cookie personnalisé (par exemple, qa-test=true) à leurs demandes.
   • Nginx vérifie ce cookie et achemine ces requêtes vers la nouvelle version 100 % du temps, garantissant ainsi des tests ciblés en production.

---

Stabiliser la sortie

1. Résolution des problèmes :

   • Les développeurs résolvent tous les problèmes identifiés lors des tests bêta en ouvrant les PR sur la branche tronc.
   • Une fois fusionnés, ces correctifs sont triés sur le volet dans la branche release/xyz.

2. Finalisation de la sortie :

   • Une fois tous les problèmes résolus et la branche stable, la branche release est étiquetée avec une version sémantique (par exemple, v1.2.0), déclenchant le déploiement sur le backend stable.
   • Les notes de version sont générées à des fins de documentation et partagées avec les parties prenantes.

---

Processus de correctif

1. Création de branches de correctifs :

   • Pour les correctifs urgents, créez une branche hotfix/xyz directement à partir de la dernière balise de production.
   • Les branches de correctifs suivent le même processus de stabilisation et de marquage que les branches de version.

2. Versionnage :

   • Les correctifs incrémentent la version du correctif (par exemple, de la v1.2.0 à la v1.2.1) conformément aux normes de Semantic Versioning (SemVer).

---

Nettoyage de branche

• Supprimez régulièrement les branches fusionnées pour éviter l'encombrement.
• Supprimez périodiquement les indicateurs de fonctionnalités inutilisés pour maintenir l'organisation.
• Automatisez la suppression de branche après la fusion à l'aide de GitHub Actions ou d'outils similaires.

---

Stratégies alternatives d'assurance qualité et de test

Au lieu des cookies, des stratégies supplémentaires pour acheminer le trafic d'assurance qualité en production incluent :

1. Routage basé sur l'en-tête :

   • QA ajoute un en-tête personnalisé (par exemple, X-QA-Test : true) à ses demandes.
   • Nginx achemine ces requêtes vers la nouvelle version pour les tests.

2. Routage basé sur IP :

   • Limiter le trafic vers la nouvelle version en fonction des adresses IP du contrôle qualité.

3. Routage basé sur des jetons d'authentification :

   • Le contrôle qualité se connecte avec un compte de test spécifique lié à un rôle ou un jeton qui garantit que les demandes sont acheminées vers la nouvelle version.

---

Conclusion

Ce processus de publication exploite le développement basé sur le tronc et les indicateurs de fonctionnalités basés sur l'environnement pour créer un flux de travail de déploiement évolutif, testable et sûr pour la production. En utilisant des environnements sandbox, le routage du trafic et des stratégies de test dédiées, les équipes peuvent fournir des fonctionnalités de haute qualité tout en minimisant les risques. Cette approche garantit que les problèmes sont détectés rapidement et résolus efficacement, ouvrant ainsi la voie à des déploiements de fonctionnalités et à des correctifs transparents.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!