Partager via

Cycle de vie de développement

  • Article

La stratégie de cycle de vie du développement fournit des considérations et recommandations de conception clés pour le référentiel, la branche, les générations automatisées, le déploiement et la stratégie de restauration lors de la création automatique de la zone d’atterrissage.

Stratégie de référentiel

Remarques relatives à la conception

  • Envisagez d’adopter un système de contrôle de version comme Git pour offrir à votre équipe plus de flexibilité en matière de partage et de gestion du code.

    • Git est le système de contrôle de version standard du secteur. Il s’agit d’un système de contrôle de version distribué, où votre copie locale du code est une version complète du référentiel.

  • Comprendre la structure de référentiel mono-référentiel multi-référentiel.

    • Dans les structures mono-référentiel, tout le code source réside dans un seul référentiel.
    • Dans les structures multi-référentiel, tous les projets sont organisés en référentiels distincts.

  • Choisissez un paramètre de visibilité qui correspond au contenu de votre référentiel.

    • Les référentiels publics sont accessibles de manière anonyme.
    • Les référentiels privés exigent que les utilisateurs aient accès au référentiel et soient connectés pour accéder aux services.
    • Vous pouvez définir une visibilité publique et privée pour Azure DevOps Projects et les référentiels GitHub.

  • Envisagez de définir des autorisations de référentiel qui vous aident à contrôler qui peut contribuer à votre code source et à gérer d’autres fonctionnalités.

  • Envisagez d’utiliser le déploiement de ressources Infrastructure en tant que code (IaC) sur Azure. L’IaC vous permet de gérer l’infrastructure dans un modèle déclaratif, ce qui contribue à réduire l’effort de configuration, à garantir la cohérence entre les déploiements et à éviter la configuration manuelle de l’environnement.

  • Azure prend en charge l’IaC pour les zones d’atterrissage via :

Recommandations de conception

  • Utilisez Git comme système de contrôle de version.

  • Utiliser des référentiels privés lors de la création de zones d’atterrissage Azure

  • Utilisez des référentiels publics pour partager des informations non confidentielles telles que des exemples d’automatisation, de la documentation publique et du matériel de collaboration open-source.

  • Adoptez une approche Infrastructure as Code (IaC) pour déployer, gérer, gouverner et supporter les ressources cloud.

Stratégie de branche

Remarques relatives à la conception

  • Envisagez d’utiliser une stratégie de branche qui permet aux équipes de collaborer mieux et de gérer efficacement le contrôle de version.

  • Envisagez d’utiliser des conventions d’affectation de noms spécifiques pour vos branches.

  • Envisagez d’utiliser des autorisations de branche pour contrôler les fonctionnalités utilisateur.

  • Envisagez d’utiliser des stratégies de branche pour aider vos équipes à protéger les branches importantes du développement. Des stratégies qui peuvent aider à faire respecter les normes de qualité du code et de gestion des changements. Voici quelques exemples de stratégies de branche :

  • L’adoption d’une stratégie de demande de tirage peut vous aider à garder le contrôle des modifications de code fusionnées dans les branches.

    • Définir une stratégie de fusion.
    • Les demandes de tirage doivent être simples, avec un nombre de fichiers minimal pour aider les réviseurs à valider les modifications plus efficacement.
    • Les demandes de tirage doivent avoir des titres et des descriptions clairs afin que les réviseurs sachent ce qu’ils doivent attendre lors de la révision du code.
    • Vous pouvez utiliser des modèles de demande de tirage.
    • Vous pouvez supprimer des branches d’origine une fois les demandes de tirage terminées, ce qui vous permet de mieux contrôler et de mieux gérer les branches.

Recommandations de conception

  • Adoptez un modèle de développement basé sur les jonctions (trunks), dans lequel les développeurs valident dans une branche unique. Ce modèle facilite l’intégration continue. Tout le travail sur les fonctionnalités est effectué sur le « trunk » et les conflits de fusion sont ensuite résolus lors de la validation.

  • Vos équipes définissent et utilisent des conventions d’affectation de noms cohérentes pour les branches afin d’identifier le travail effectué.

  • Définissez des autorisations pour contrôler qui peut lire et mettre à jour le code dans une branche de votre référentiel Git. Vous pouvez définir des autorisations pour des utilisateurs individuels et pour des groupes.

  • Définir des stratégies de branche :

    • Exiger l’utilisation des demandes de tirage pour les fusions de branche dans la branche principale.
    • Exiger un nombre minimal de réviseurs pour les demandes de tirage.
    • Réinitialiser tous les votes d’approbation pour supprimer tous les votes d’approbation, mais conserver les votes pour rejeter ou attendre chaque fois qu’une branche source change.
    • Inclure automatiquement les réviseurs du code.
    • Vérifiez la résolution des commentaires.

  • Définissez une stratégie de fusion Squash, ce qui vous permet de condenser l’historique Git des branches de rubrique lorsque vous effectuez des demandes de tirage. Au lieu d’ajouter chaque validation sur une branche de rubrique à l’historique de la branche par défaut, une fusion Squash ajoute toutes les modifications de fichier à une seule nouvelle validation sur la branche par défaut.

Builds automatisés

Remarques relatives à la conception

  • Envisagez d’implémenter l’intégration continue (CI). L’intégration continue consiste à fusionner tous les codes des développeurs dans une base de code centrale à intervalles réguliers et à exécuter automatiquement des processus de construction et de test standard.

  • Envisagez d’utiliser des déclencheurs d’intégration continue :

    • Git Azure Repos. Vous pouvez configurer des branches, des chemins et des étiquettes en tant que déclencheurs pour exécuter une génération d’intégration continue.
    • GitHub. Vous pouvez configurer des branches, des chemins et des étiquettes comme déclencheurs pour exécuter une build d’intégration continue.

  • Envisagez d’inclure des tests unitaires d’IaC dans votre processus de génération pour valider la syntaxe.

  • Envisagez d’inclure des tests unitaires dans le processus de génération de votre application. Passez en revue les tâches disponibles pour Azure DevOps Pipeline.

  • Utilisez des connexions de service Azure DevOps ou des secrets GitHub pour gérer les connexions à Azure. Chaque connexion doit disposer d’un accès privilégié approprié aux ressources Azure.

  • Envisagez d’utiliser des secrets Azure Key Vault pour stocker et gérer les informations sensibles, comme les mots de passe, les clés d’API ou les certificats.

  • Les agents Azure DevOps peuvent être auto-hébergés ou hébergés par Microsoft.

    • La maintenance et les mises à niveau sont prises en charge lorsque vous utilisez des agents hébergés par Microsoft. Chaque fois qu’un travail de génération est exécuté, une nouvelle machine virtuelle est créée.
    • Vous configurez et gérez des agents auto-hébergés par vous-même pour exécuter des travaux de génération.

Recommandations de conception

  • Utilisez l’intégration continue pour automatiser les générations et les tests du code chaque fois qu’un membre de l’équipe valide des changements dans le contrôle de version.

  • Incluez des tests unitaires pour le code IaC et l’application dans le cadre de votre processus de génération.

  • Si possible, utilisez des pools hébergés par Microsoft plutôt que des pools auto-hébergés, car ils offrent une isolation et une machine virtuelle propre pour chaque exécution de pipeline.

  • Lorsque vous connectez Azure DevOps ou GitHub à Azure via des connexions de service ou des secrets GitHub, veillez à toujours définir l’étendue afin qu’elles puissent accéder uniquement aux ressources requises.

  • Utilisez Key Vault pour éviter de coder en dur des informations sensibles telles que les identifiants (mots de passe des utilisateurs des machines virtuelles), les certificats ou les clés. Utilisez ensuite les secrets comme variables dans vos travaux de génération et de mise en production.

Stratégie de déploiement

Remarques relatives à la conception

  • Envisagez d’utiliser la livraison continue (CD). Le déploiement continu implique la génération, le test, la configuration et le déploiement d’une build vers un environnement.

  • Envisagez d’utiliser des environnements. Les environnements vous permettent de cibler une collection de ressources à partir d’un travail de livraison. Voici quelques exemples de noms d’environnement courants :

    • Dev
    • Test
    • QA
    • Préproduction
    • Production

  • Envisagez d’intégrer IaC dans votre stratégie pour valider et confirmer les modifications avant le déploiement.

Recommandations de conception

  • Utilisez la livraison continue (CD) pour vous assurer que le code est toujours prêt à être déployé, en automatisant la génération, le test et le déploiement du code dans des environnements similaires à l’environnement de production. Ajoutez une livraison continue pour créer une intégration CI/CD complète qui vous aide à détecter les défauts de code dès que possible et garantit que vous pouvez rapidement publier des mises à jour testées correctement.

  • Utilisez des environnements dans le cadre de votre stratégie de déploiement. Les environnements offrent des avantages comme les suivants :

    • Historique de déploiement
    • Traçabilité des validations et des éléments de travail
    • Intégrité des ressources de diagnostic
    • Sécurité

  • Incluez des contrôles pré-déploiement IaC afin de prévisualiser les modifications et de voir si une ressource est créée, modifiée ou supprimée.

Stratégie de restauration

Remarques relatives à la conception

  • Envisagez de créer un plan de restauration. La restauration d’un déploiement implique de rétablir un état de déploiement correct connu et offre une capacité cruciale à récupérer à partir d’un déploiement ayant échoué.

  • Envisagez d’utiliser la fonctionnalité annuler les modifications dans Git si vous devez revenir à des modifications dans un commit, annuler des modifications non validées ou réinitialiser une branche à un état précédent.

Recommandations de conception

  • Adoptez l’utilisation de Git undo changes pour revenir à des modifications sur des fichiers validés, annuler des modifications non validées ou réinitialiser une branche à un état antérieur.