Partager via

Stratégie de versioning et de publication des fonctionnalités d’Azure Developer CLI

  • Article

Les fonctionnalités d’Azure Developer CLI (azd) sont introduites et prises en charge selon une approche par phases. Les fonctionnalités commencent au stade alpha, puis passent au stade bêta et stable après avoir satisfait à plusieurs critères. Cet article détaille les définitions, les attentes et les exigences en matière d’avancement pour chaque phase. Consultez la liste complète de chaque fonctionnalité /commande prise en charge par azd et de sa phase en cours sur GitHub

Fonctionnalités alpha

Au départ, toutes les fonctionnalités sont des fonctionnalités alpha (par exemple, expérimentales). Cette phase vise à parvenir à une utilisation suffisante pour obtenir des commentaires significatifs sur la conception, le fonctionnement et l’expérience utilisateur de la fonctionnalité. Les fonctionnalités alpha peuvent être activées et gérées à l’aide de la commande azd config.

Important

Les fonctionnalités alpha sont uniquement recommandées pour les scénarios non critiques pour l’entreprise, mais avec prudence, car il existe un faible risque de changements incompatibles dans les versions ultérieures jusqu’à la version stable.

Définition

  • Ces fonctionnalités sont en cours de développement.
  • Elles sont cachées derrière un indicateur de fonctionnalité, auquel les utilisateurs intéressés doivent explicitement choisir.
  • Il n’y a aucune garantie quant à la stabilité ou à la prise en charge à long terme des fonctionnalités expérimentales.
  • Rien ne garantit que l’équipe produit prévoit de faire passer la fonctionnalité au stade de la préversion ou de la stabilité (il s’agit d’une expérimentation).

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 au niveau de l’étendue du groupe de ressources, exécutez :

    azd config set alpha.resourceGroupDeployments on

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

    azd config set alpha.resourceGroupDeployments off

    Pour en savoir plus, 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 a officiellement approuvé le passage 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 est réussie grâce à un nombre suffisant de commentaires de la part des utilisateurs.

Fonctionnalités bêta

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

Important

Les fonctionnalités bêta sont uniquement recommandées pour les scénarios non critiques pour l’entreprise, mais avec prudence, car il existe un faible risque de changements incompatibles dans les versions ultérieures jusqu’à la version stable.

Définition

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

Critères d’avancement (comment atteindre la version stable)

  • L’équipe produit a officiellement examiné et approuvé l’avancement de la fonctionnalité à la phase suivante.
  • La fonctionnalité est fonctionnellement complète et stable.
  • La fonctionnalité a été testée manuellement de manière approfondie et compte suffisamment de tests unitaires et d’intégration pour détecter les régressions et les bogues.
  • Les bogues restants sont acceptables et ne bloquent pas les utilisateurs (par exemple, améliorations de l’expérience utilisateur).
  • L’équipe produit a recueilli des signaux indiquant que l’expérience utilisateur est réussie grâce à des commentaires suffisants de la part des utilisateurs.
  • L’équipe produit estime que la fonctionnalité apporte une valeur ajoutée à l’expérience utilisateur de bout en bout.

Fonctionnalités stables

Définition

  • L’équipe produit supporte ces fonctionnalités.
  • Les changements cassants dans ces domaines sont inattendus.
  • L’équipe produit garantit que tus les changements cassants sont déployés de manière à en réduire l’impact.
  • Utilisation dans des scénarios critiques pour l’entreprise.

Demander de l’aide

Pour savoir comment signaler un bogue, demander de l'aide ou proposer une nouvelle fonctionnalité pour Azure Developer CLI, veuillez consulter la page Dépannage et assistance.