Flux de travail de développement de bout en bout

Un flux de travail moderne de développement Azure relie le contrôle de code source, l'intégration et la livraison continues, l'infrastructure de conteneurs et l'observabilité en une boucle interne fluide, de la validation du code jusqu'à la production observable. Les principaux composants sont : GitHub (source), GitHub actions (chaîne de compilation et de déploiement), Azure Container Registry (stockage des images), Azure Container Apps (environnement d'exécution) et Application Insights (observabilité). Chaque modification passe automatiquement de l'ordinateur portable du développeur à la production en quelques minutes, avec des contrôles de qualité à chaque étape.

Organisez votre code dans un référentiel GitHub en utilisant un développement basé sur le tronc ou une stratégie de branches GitFlow. Pour la plupart des microservices, le développement basé sur le tronc (branches de fonctionnalités à courte durée de vie fusionnées quotidiennement dans main) réduit les conflits d'intégration et maintient la chaîne simple. Utilisez des règles de protection des branches sur main pour exiger la révision des demandes d'extraction et la réussite des vérifications d'intégration continue avant la fusion. Un fichier CODEOWNERS garantit que les modifications apportées aux services critiques nécessitent l'approbation des ingénieurs expérimentés de l'équipe concernée.

La chaîne d'intégration continue s'exécute à chaque demande d'extraction. Un flux de travail courant est le suivant : extraire le code → restaurer les dépendances → exécuter les tests unitaires → exécuter les tests d'intégration → créer l'image Docker → envoyer l'image vers Azure Container Registry. L'image est étiquetée avec le SHA de la validation git pour assurer sa traçabilité. Utilisez l'authentification basée sur OIDC de GitHub Actions vers Azure (via une identité fédérée) afin d'éviter de stocker des secrets de principaux de service Azure dans GitHub : il s'agit d'un équivalent d'identité managée pour les chaînes d'intégration continue.

Une fois la chaîne d'intégration continue réussie après une fusion dans main, la chaîne de livraison continue déploie automatiquement l'application dans l'environnement de préproduction. La chaîne met à jour l'étiquette d'image de l'application Container Apps avec le SHA qui vient d'être créé, attend que la nouvelle révision soit saine, puis exécute des tests de bon fonctionnement sur l'URL de préproduction. Ces tests vérifient que les points de terminaison d'API critiques renvoient les réponses attendues. Si les tests échouent, la chaîne annule le déploiement en redirigeant le trafic d'entrée vers la révision précédente, sans intervention manuelle.

Après la validation de la préproduction, la chaîne de livraison continue s'interrompt sur une porte d'approbation. Les protections d'environnement de GitHub Actions vous permettent de configurer les réviseurs requis pour l'environnement production. La chaîne envoie une notification Slack à l'ingénieur d'astreinte, qui examine les résultats des tests de préproduction, les différences et les incidents ouverts avant d'approuver. Ce n'est qu'après l'approbation que la chaîne poursuit le déploiement de la même image identifiée par le SHA en production. Cette étape avec intervention humaine est essentielle pour les services à fort trafic ou soumis à une réglementation.

Une fois le déploiement effectué en production, Application Insights fournit une visibilité en temps réel. Le SDK App Insights (ou l'instrumentation automatique pour les environnements d'exécution pris en charge) suit : les taux de requêtes, taux d'échec et latences (les trois signaux clés), les appels aux dépendances (bases de données, Service Bus et autres API), ainsi que les exceptions avec leurs traces de pile complètes. L'Application Map visualise la manière dont les services s'appellent entre eux et met en évidence les dépendances qui contribuent le plus aux échecs ou à la latence.

Utilisez les Annotations Application Insights pour marquer les événements de déploiement sur vos graphiques de métriques. Lorsqu'une annotation de mise à disposition est créée (via l'action azure/appinsights-annotation de GitHub Actions), elle apparaît sous la forme d'une ligne verticale sur tous les graphiques de métriques App Insights. Vous voyez ainsi immédiatement si un pic de latence ou une hausse du taux d'erreur est corrélé à un déploiement récent, ce qui réduit considérablement le temps moyen de diagnostic (MTTD) pendant les incidents.

Pour les chaînes les plus résilientes, mettez en œuvre une annulation automatique. Après le déploiement en production, la chaîne attend 10 minutes, puis interroge Application Insights afin d'obtenir le taux d'erreur. Si celui-ci dépasse un seuil configurable (par exemple, >5 %), la chaîne annule automatiquement le déploiement en redirigeant le trafic d'entrée de Container Apps à 100 % vers la révision précédente. Ce modèle de livraison progressive réduit l'ampleur des conséquences d'un mauvais déploiement et permet aux équipes de déployer en toute confiance, même pour des modifications complexes ou sensibles.

Les développeurs doivent pouvoir exécuter et tester localement l'ensemble de la pile sans se connecter aux ressources Azure de production. Utilisez Azure Storage Emulator (Azurite) pour le stockage local d'objets blob et de files d'attente, Cosmos DB Emulator pour les tests de base de données locaux et Service Bus Emulator pour la messagerie locale. La variable d'environnement AZURE_ENVIRONMENT=local peut faire basculer DefaultAzureCredential vers l'utilisation de chaînes de connexion pointant vers les émulateurs, tandis que le même code utilise une identité managée dans Azure. Docker Compose orchestre toutes les dépendances locales avec une seule commande docker compose up.

Intégrez la sécurité à chaque étape du flux de travail du développeur : Dependabot recherche les dépendances vulnérables dans les demandes d'extraction ; GitHub Advanced Security (analyse du code avec CodeQL) détecte les vulnérabilités telles que les injections SQL et les secrets codés en dur ; Microsoft Defender for DevOps s'intègre à GitHub pour présenter les recommandations de sécurité Azure à côté des modifications du code ; et l'analyse des vulnérabilités par ACR Defender vérifie les images de conteneurs à la recherche de CVE affectant le système d'exploitation ou la couche applicative après chaque envoi. Les résultats de sécurité apparaissent sous forme de commentaires dans les demandes d'extraction et peuvent donc être traités avant la fusion.

Le flux de travail complet du développeur forme une boucle de rétroaction continue : un développeur valide du code, l'intégration continue crée et teste l'image du conteneur, l'image est envoyée vers ACR avec le SHA de la validation comme étiquette, la livraison continue déploie en préproduction et exécute les tests de bon fonctionnement, une personne approuve le déploiement en production, la chaîne déploie en production et crée une annotation de mise à disposition, puis Application Insights surveille les taux d'erreur et déclenche une annulation automatique si les seuils sont dépassés. L'infrastructure en tant que code (Bicep ou Terraform) du même référentiel garantit que la chaîne, l'application Container Apps et la configuration de surveillance sont toutes gérées par versions avec le code de l'application.

Vérifiez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris que le flux de travail de développement de bout en bout relie le contrôle du code source GitHub, l'intégration et la livraison continues avec GitHub Actions, Azure Container Registry, Container Apps et Application Insights ; que les annotations de mise à disposition corrèlent les déploiements avec les évolutions des métriques pour accélérer le diagnostic des incidents ; et que l'annulation automatique fondée sur les requêtes de taux d'erreur réduit l'ampleur des conséquences des mauvais déploiements. Nous allons maintenant passer à la préparation de l'examen avec une révision complète des concepts du cloud et de l'architecture Azure.