Share via

Gestion des versions et stratégie de mise en production des fonctionnalités Azure Developer CLI

  • Article

Les fonctionnalités azure Developer CLI (azd) sont introduites et prises en charge à l’aide d’une approche par phases. Les fonctionnalités commencent à l’étape alpha , puis passent à la version bêta et stable après avoir rencontré différents critères. Cet article décrit les définitions, les attentes et les exigences d’avancement pour chaque phase. Consultez la liste complète de chaque fonctionnalité /commande prise en charge par azd et de sa phase actuelle sur GitHub

Fonctionnalités alpha

Toutes les fonctionnalités commencent par des fonctionnalités alpha (par exemple, expérimentales). Dans cette phase, l’objectif est de recevoir suffisamment d’utilisation pour obtenir des commentaires significatifs sur la conception, la fonctionnalité et l’expérience utilisateur de la fonctionnalité. Les fonctionnalités alpha peuvent être activées et gérées à l’aide de la azd config commande.

Important

Les fonctionnalités alpha ne sont recommandées que pour les scénarios non critiques pour l’entreprise, car il existe une petite probabilité de modifications incompatibles dans les versions ultérieures menant à une stabilité.

Définition

  • Ces fonctionnalités sont en cours de développement actif.
  • Les fonctionnalités sont masquées derrière un indicateur de fonctionnalité, auquel les utilisateurs intéressés doivent opter explicitement.
  • Il n’existe aucune garantie quant à la stabilité à long terme ou à la prise en charge des caractéristiques expérimentales.
  • Aucun engagement que la fonctionnalité est quelque chose que l’équipe produit prévoit de passer à la préversion ou à la phase stable (il s’agit d’une expérience).

Comment opter pour les fonctionnalités alpha

  1. Pour répertorier les fonctionnalités expérimentales disponibles, exécutez :

    azd config list-alpha

  2. Pour activer une fonctionnalité expérimentale spécifique, par exemple resourceGroupDeployments pour prendre en charge les déploiements d’infrastructure dans l’étendue du groupe de ressources, exécutez :

    azd config set alpha.resourceGroupDeployments on

  3. Pour désactiver la resourceGroupDeployments fonctionnalité, exécutez :

    azd config set alpha.resourceGroupDeployments off

    Pour plus d’informations, consultez le dépôt GitHub azure-dev .

Critères d’avancement (comment atteindre la version bêta)

  • La fonctionnalité a été correctement spécifiée et approuvée par l’équipe produit.
  • L’équipe produit s’est officiellement signée sur l’avancement de la fonctionnalité à la phase suivante.
  • La fonctionnalité est documentée et le texte d’aide est disponible dans le produit.
  • Confirmation que l’expérience utilisateur réussit par le biais de commentaires utilisateur suffisants.

Fonctionnalités bêta

L’objectif de cette phase est d’améliorer l’expérience de fonctionnalité et d’avancer au-delà de la preuve de concept.

Important

Les fonctionnalités bêta ne sont recommandées que pour les scénarios non critiques pour l’entreprise, car il existe une petite probabilité de modifications incompatibles dans les versions ultérieures menant à une stabilité.

Définition

  • Contrairement aux fonctionnalités alpha , un utilisateur n’a pas besoin d’effectuer une action explicite pour utiliser une fonctionnalité bêta .
  • Un nombre réduit de changements cassants entre les versions pour les fonctionnalités bêta à mesure que les mises à jour matures des fonctionnalités sont effectuées en fonction des commentaires des clients.
  • Les changements cassants sont documentés avec des explications sur la façon de digester ces sauts.
  • Les commandes bêta sont indiquées comme telles (bêta) dans l’aide du produit azd.

Critères d’avancement (comment atteindre stable)

  • L’équipe produit a officiellement examiné et signé l’avancement des fonctionnalités à la prochaine phase.
  • La fonctionnalité est fonctionnellement complète et stable.
  • La fonctionnalité a été soigneusement testée manuellement et dispose de tests unitaires et d’intégration suffisants pour intercepter les régressions et les bogues.
  • Les bogues restants sont acceptables et non bloquants pour les utilisateurs (par exemple, améliorations de l’expérience utilisateur).
  • L’équipe produit a reçu des signaux indiquant que l’expérience utilisateur réussit par le biais de commentaires utilisateur suffisants.
  • L’équipe produit estime que la fonctionnalité ajoute vraiment de la valeur à l’expérience utilisateur de bout en bout.

Fonctionnalités stables

Définition

  • L’équipe produit se trouve derrière ces fonctionnalités.
  • Les changements cassants dans ces domaines sont inattendus.
  • L’équipe produit garantit que toutes les modifications cassants sont déployées de manière à réduire l’impact.
  • Utiliser dans les scénarios critiques pour l’entreprise.

Demander de l’aide

Pour plus d’informations sur la façon de déposer un bogue, de demander de l’aide ou de proposer une nouvelle fonctionnalité pour l’interface CLI développeur Azure, visitez la page de dépannage et de support .