Intégration continue et livraison continue (création de Real-World Cloud Apps avec Azure)

  • Article
  • 5 minutes de lecture

par Rick Anderson, Tom Dykstra

Télécharger le projet fix it ou télécharger le livre électronique

The Building Real World Cloud Apps with Azure e-book 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 signifie que chaque fois qu’un développeur vérifie le code dans le référentiel source, une build est automatiquement déclenchée. La livraison continue (CD) effectue cette étape plus loin : après la réussite d’un test unitaire de build et automatisé, 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 la 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 lorsque vous en avez besoin, et vous pouvez réduire l’environnement lorsque vous avez terminé le test.

Flux de travail 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, nécessitent une révision manuelle et un processus d’approbation pour le déploiement de production. Pour un déploiement de production, vous pouvez vous assurer qu’il se produit lorsque des personnes clés de l’équipe de développement sont disponibles pour la prise en charge ou pendant des périodes de faible trafic. Mais il n’y a rien pour vous empêcher d’automatiser complètement vos environnements de développement et de test afin que tous les développeurs doivent effectuer des vérifications dans un changement 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 complète dans son contexte d’origine.

Flux de travail de livraison continue

Comment le cloud permet l’intégration continue et le cd rentables

L’automatisation de ces processus dans Azure est simple. É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. Avec chaque build que vous faites, vous pouvez lancer 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 quand vous avez terminé de le supprimer. Et si vous exécutez uniquement ce serveur pendant 2 heures ou 8 heures ou par jour, le montant d’argent que vous devez payer pour cela est minimal, car vous payez uniquement pour le temps qu’un ordinateur est en cours d’exécution. Par exemple, l’environnement requis pour l’application Fix it coûte essentiellement environ 1 % par heure si vous accédez à un niveau supérieur au 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 à développer des applications de la planification au déploiement.

  • Il prend en charge le contrôle de code source Git (distribué) et TFVC (centralisé).
  • Il offre un service de build élastique, ce qui signifie qu’il crée dynamiquement des serveurs de build lorsqu’ils sont nécessaires et les enlève quand ils sont terminés. Vous pouvez lancer automatiquement une build lorsque quelqu’un vérifie les modifications apportées au code source et que vous n’avez pas besoin d’allouer et de payer pour vos propres serveurs de build qui sont inactifs la plupart du temps. Le service de build 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 une 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 libérer l’application en production.
  • Il prend en charge la collaboration de salle 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 agile des projets.

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, consultez Azure DevOps Services. Inscrivez-vous à Azure DevOps Services.

Résumé

Les trois premiers modèles de développement cloud ont été 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 architecturaux 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