Intégration continue et livraison continue (création d’applications cloud Real-World avec Azure)

  • Article

par Rick Anderson, Tom Dykstra

Télécharger corriger le projet ou télécharger le livre électronique

Le livre électronique Building Real World Cloud Apps with Azure est basé sur une présentation développée par Scott Guthrie. Il explique 13 modèles et pratiques qui peuvent vous aider à développer des applications web pour le cloud. Pour plus d’informations sur le livre électronique, consultez le premier chapitre.

Les deux premiers modèles de processus de développement recommandés étaient Automatiser tout et Contrôle de code source, et le troisième modèle de processus les combine. L’intégration continue (CI) signifie que chaque fois qu’un développeur archive du code dans le référentiel source, une build est automatiquement déclenchée. La livraison continue (CD) va encore plus loin : une fois qu’une génération et des tests unitaires automatisés ont réussi, vous déployez automatiquement l’application dans un environnement où vous pouvez effectuer des tests plus approfondis.

Le cloud vous permet de réduire le coût de maintenance d’un environnement de test, car vous payez uniquement pour les ressources de l’environnement tant que vous les utilisez. Votre processus CD peut configurer l’environnement de test quand vous en avez besoin, et vous pouvez le mettre hors service lorsque vous avez terminé le test.

Workflow d’intégration continue et de livraison continue

En règle générale, nous vous recommandons d’effectuer une livraison continue à vos environnements de développement et de préproduction. La plupart des équipes, même chez Microsoft, ont besoin d’un processus de révision manuelle et d’approbation pour le déploiement en production. Pour un déploiement de production, vous souhaiterez peut-être vous assurer qu’il se produit lorsque des personnes clés de l’équipe de développement sont disponibles pour le support, ou pendant les périodes de faible trafic. Mais rien ne vous empêche d’automatiser complètement vos environnements de développement et de test afin qu’un développeur n’ait qu’à case activée dans une modification et qu’un environnement soit configuré pour les tests d’acceptation.

Le diagramme suivant d’un livre électronique Microsoft Patterns and Practices sur la livraison continue illustre un flux de travail classique. Cliquez sur l’image pour la voir en taille réelle dans son contexte d’origine.

Flux de travail de livraison continue

Comment le cloud permet un CI et un CD rentables

L’automatisation de ces processus dans Azure est facile. Étant donné que vous exécutez tout dans le cloud, vous n’avez pas besoin d’acheter ou de gérer des serveurs pour vos builds ou vos environnements de test. Et vous n’avez pas besoin d’attendre qu’un serveur soit disponible pour effectuer vos tests. À chaque build que vous effectuez, vous pouvez faire tourner un environnement de test dans Azure à l’aide de votre script d’automatisation, exécuter des tests d’acceptation ou des tests plus approfondis sur celui-ci, puis, lorsque vous avez terminé, il suffit de le détruire. Et si vous n’exécutez ce serveur que pendant 2 heures ou 8 heures ou un jour, la somme d’argent que vous devez payer pour ce serveur est minime, car vous payez uniquement pour la durée d’exécution d’une machine. Par exemple, l’environnement requis pour l’application Corriger le coût est d’environ 1 % par heure si vous accédez à un niveau supérieur à partir du niveau gratuit. Au cours d’un mois, si vous n’avez exécuté l’environnement qu’une heure à la fois, votre environnement de test coûte probablement moins cher qu’un latte que vous achetez chez Starbucks.

Azure DevOps Services

Azure DevOps Services fournit un certain nombre de fonctionnalités pour vous aider dans le développement d’applications, de la planification au déploiement.

  • Il prend en charge à la fois le contrôle de code source Git (distribué) et TFVC (centralisé).
  • Il offre un service de génération élastique, ce qui signifie qu’il crée dynamiquement des serveurs de build quand ils sont nécessaires et les retire quand ils sont terminés. Vous pouvez lancer automatiquement une build lorsque quelqu’un vérifie les modifications de code source et que vous n’avez pas besoin d’allouer et de payer vos propres serveurs de build qui sont inactifs la plupart du temps. Le service de génération est gratuit tant que vous ne dépassez pas un certain nombre de builds. Si vous prévoyez d’effectuer un volume élevé de builds, vous pouvez payer un peu plus pour les serveurs de build réservés.
  • Il prend en charge la livraison continue vers Azure.
  • Il prend en charge les tests de charge automatisés. Le test de charge est essentiel pour une application cloud, mais il est souvent négligé jusqu’à ce qu’il soit trop tard. Le test de charge simule l’utilisation intensive d’une application par des milliers d’utilisateurs, ce qui vous permet de trouver des goulots d’étranglement et d’améliorer le débit avant de la mettre en production.
  • Il prend en charge la collaboration des salles d’équipe, ce qui facilite la communication et la collaboration en temps réel pour les petites équipes agiles.
  • Il prend en charge la gestion de projet agile.

Pour plus d’informations sur les fonctionnalités d’intégration et de livraison continues de Azure DevOps Services, consultez la documentation Azure DevOps.

Si vous recherchez une solution de gestion de projet clé en main, de collaboration d’équipe et de contrôle de code source, case activée Azure DevOps Services. Inscrivez-vous à Azure DevOps Services.

Résumé

Les trois premiers modèles de développement cloud ont porté sur la façon d’implémenter un processus de développement reproductible, fiable et prévisible avec un temps de cycle faible. Dans le chapitre suivant , nous commençons à examiner les modèles d’architecture et de codage.

Ressources

Pour plus d’informations, consultez Déployer une application web dans Azure App Service.

Consultez également les ressources suivantes :

PrécédentSuivant