Intégration continue (CI) et déploiement continu (CD)

La plupart des projets sont un travail d'équipe. L'équipe peut être située à différents endroits ou au même endroit, et les membres de différents endroits doivent travailler en mode synchronisation afin que leurs modifications n'entrent pas en conflit avec les autres membres de l'équipe. Un système ne mûrira pas tant qu'il n'est pas utilisé dans divers scénarios ; ces scénarios pourraient être basés sur l'expérience d'experts du domaine ou provenir de l'environnement de production. Il est possible qu'un système tombe en panne dans l'environnement de production même s'il est considéré comme un système parfait. En termes d'applications Web, les conditions sont plus critiques en raison de problèmes de performances, de mauvaises expériences utilisateur,... Un système doit passer par un processus où, si un membre de l'équipe apporte des modifications, le code est intégré après les tests unitaires et la construction est ensuite déployée dans l'environnement associé.

Lorsque nous disons déploiement, le déploiement Xcopy vient immédiatement à l'esprit. Dans ce type de déploiement, vous créez et copiez simplement les fichiers associés et déployez/collez dans un environnement approprié.

Dans les fondements du déploiement, telles que l'intégration continue (CI) et le déploiement continu (CD), nous constatons principalement les sujets suivants :

• L'environnement Azure
• Publication/hébergement
• Le CI et CD utilisant TFS en ligne
• La différence entre CI et CD

Terminologie de déploiement

Avant d'aller plus loin, nous devons d'abord discuter des raisons pour lesquelles nous parlons de déploiement. Le cycle de déploiement est celui ayant un flux spécifique et nous devons comprendre la terminologie de déploiement. La terminologie de déploiement inclut simplement les étapes commençant par les modifications de code jusqu'à la publication.

La phase de construction (build stage)

Au stade de la construction, la source du service est compilée sans aucune erreur avec la réussite de tous les tests unitaires correspondants. Cette étape produit des artefacts de construction.

Intégration continue (CI)

Le CI force l'intégralité de l'application à être recréée chaque fois qu'un développeur effectue une modification : le code de l'application est compilé et un ensemble complet de tests automatisés est exécuté sur celui-ci. Cette pratique est née des problèmes d'intégration fréquente du code dans les grandes équipes. L'idée de base est de garder le delta, ou de modifier le logiciel, petit. Cela permet de s'assurer que le logiciel est dans un état fonctionnel. Même si un enregistrement effectué par un développeur casse le système, il est facile de le réparer en utilisant ce processus.

Déploiement

Le provisionnement du matériel, l'installation du système d'exploitation de base et la version correcte du cadre d'application .NET sont des conditions préalables au déploiement. La partie suivante consiste à faire avancer ces artefacts de construction en production à travers différentes étapes. La combinaison de ces deux parties est appelée étape de déploiement. Il n'y a pas de distinction entre les étapes de déploiement et de publication dans la plupart des applications.

Déploiement continu (CD)

Dans le CD, chaque construction (build) réussie est déployée dans un environnement préféré, par exemple, la production. Les environnements varient d'une organisation à l'autre. Ainsi, le CD n'est pas destiné à un environnement de production, mais vous pouvez également l'utiliser pour d'autres environnements tels que dev (développement), staging, preprod (Pré-production),... Le CD est plus important du point de vue d'une équipe technique. Sous CD, il existe plusieurs autres pratiques, telles que les tests unitaires automatisés, l'étiquetage, la gestion des versions des numéros de version et la traçabilité des modifications. Avec une livraison continue, l'équipe technique s'assure que les changements apportés à la production via divers environnements inférieurs fonctionnent comme prévu en production. Généralement, ceux-ci sont petits et déployés très rapidement.

Livraison continue

La livraison continue est différente du CD. Le CD vient du point de vue d'une équipe technique, tandis que la livraison continue est davantage axée sur la fourniture du code déployé le plus tôt possible au client. Pour s'assurer que les clients obtiennent le bon produit sans défaut, en livraison continue, chaque construction doit passer par tous les contrôles d'assurance qualité. Une fois que le produit passe la vérification de qualité satisfaisante, c'est aux parties prenantes de l'entreprise de décider quand le libérer.

Pipeline de construction et de déploiement

Le pipeline de génération et de déploiement fait partie de la mise en oeuvre de la livraison continue via l'automatisation. Il s'agit d'un flux de travail (workflow) d'étapes par lesquelles le code est validé dans le référentiel source. À l'autre extrémité du pipeline de déploiement, les artefacts à publier sont produits. Certaines des étapes pouvant constituer le pipeline d'une construction (build) et de déploiement sont les suivantes :

• Tests unitaires
• Tests d'intégration
• Couverture de code et analyse statique
• Tests de régression
• Déploiements dans un environnement intermédiaire
• Tests de charge/stress
• Déploiement vers le référentiel de publication

Réalisation (Release)

Une fonctionnalité commerciale mise à la disposition de l'utilisateur final est appelée la publication d'une fonctionnalité. Pour publier une fonctionnalité ou un service, les artefacts de construction (build) pertinents doivent être déployés au préalable. Habituellement, la bascule de fonctionnalité gère la publication d'une fonctionnalité. Si le drapeau de fonctionnalité (également appelé bascule de fonctionnalité) n'est pas activé en production, cela s'appelle une version sombre de la fonctionnalité spécifiée.

Conditions préalables à la réussite des déploiements de services RESTful

Le succès de tout déploiement de système dépend du style architectural et des pratiques suivies par l'équipe. Les services RESTful ont plus de chances de réussir avec l'adoption des pratiques suivantes :

• Des équipes autonomes : Amazon, pionnier des architectures SOA et microservices, suit le paradigme des Two Pizza Teams. Cela signifie généralement qu'une équipe de microservices ne comptera pas plus de 7 à 10 membres. Ces membres de l'équipe auront toutes les compétences et les rôles nécessaires ; par exemple, le développement, les opérations et l'analyste d'affaires. Une telle équipe de service gère le développement, les opérations et la gestion d'un microservice.
• CI et CD : Le CI et CD sont des conditions préalables à la mise en oeuvre de services RESTful faisant partie d'un système basé sur un style architectural de microservices. Des équipes plus petites et autonomes, pouvant intégrer leur travail fréquemment, sont des précurseurs du succès des microservices. Cette architecture n'est pas aussi simple qu'un monolithe. Cependant, l'automatisation et la possibilité de pousser les mises à niveau du code permettent régulièrement aux équipes de gérer la complexité. Des outils, tels que Team Foundation Online Services (TFS), TeamCity et Jenkins, sont des chaînes d'outils très populaires dans cet espace.
• Infrastructure en tant que code : l'idée de représenter les composants matériels et d'infrastructure, tels que les réseaux avec du code, est nouvelle. Il vous aide à rendre les environnements de déploiement, tels que l'intégration, les tests et la production, exactement identiques. Cela signifie que les développeurs et les ingénieurs de test seront en mesure de reproduire facilement les défauts de production dans des environnements inférieurs. Avec des outils tels que CFEngine, Chef, Puppet, Ansible et Powershell DSC, vous pouvez écrire toute votre infrastructure en tant que code. Avec ce changement de paradigme, vous pouvez également mettre votre infrastructure sous un système de contrôle de version et l'expédier en tant qu'artefact lors du déploiement.
• Utilisation de l'infonuagique de calcul : l'infonuagique de calcul est un grand catalyseur pour l'adoption des microservices. Il n'est cependant pas obligatoire, en tant que tel, pour le déploiement de microservices. L'infonuagique de calcul est doté d'une échelle, d'une élasticité et d'une capacité de provisionnement rapide presque infinies. Il va de soi que l'infonuagique est un allié naturel des microservices. Ainsi, la connaissance et l'expérience de l'infonuagique Azure vous aideront à adopter les microservices.

L'environnement Azure

L'infonuagique Azure est un service Microsoft proposant divers services infonuagique. Le Azure est une plateforme infonuagique vous aidant à créer, déployer et gérer des applications à l'échelle mondiale.

Infonuagique

En termes simples, l'infonuagique est un magasin/lieu fournissant divers services informatiques, à savoir l'entreposage, les bases de données, les serveurs et les logiciels, sur Internet. Ces services peuvent être vendus par n'importe qui et les fournisseurs/entreprises fournissant ces services d'infonuagique sont appelés fournisseurs d'infonuagique. L'infonuagique n'est pas un nouveau terme, il existe depuis un certain temps, c'est juste que maintenant il est devenu populaire. Si vous utilisez des services en ligne vous aidant à envoyer ou à recevoir vos courriels à destination ou en provenance d'autres personnes, il s'agit d'infonuagique. Avec l'aide de l'infonuagique, vous pouvez faire presque tout ce que vous voulez. Ces prestations comprennent :

• Création de nouvelles applications
• Entreposer des données
• Hébergement, déploiement d'applications
• Et il existe de nombreuses autres activités, selon les services proposés par votre fournisseur d'infonuagique ou le type d'abonnement dont vous disposez.

Les avantages de l'infonuagique

De nos jours, l'infonuagique a des avantages a être utilisé :

• Choisissez et commencez : si vous avez un abonnement à l'informatique en nuage, vous n'aurez pas besoin de réfléchir, choisissez simplement votre service et commencez de n'importe où. Vous avez juste besoin d'un Internet pour commencer.
• Coût : lorsque vous optez pour l'infonuagique, il n'est pas nécessaire de penser à dépenser de l'argent pour acheter du matériel coûteux ou une infrastructure connexe. Vous pouvez obtenir les types de matériel dont vous avez besoin et ceux-ci sont rentables.
• Vitesse : vous pouvez commander de nouvelles ressources rapidement ; ces services sont très performants.
• Disponibilité : L'avantage le plus important de l'infonuagique est que vous n'avez pas besoin de penser à la disponibilité des services, car ils sont disponibles dans le monde entier. Par exemple, si vous avez commandé une machine virtuelle au Brésil, vous n'avez pas à vous soucier de l'utilisation de cette machine même si vous vous trouvez dans une autre partie du monde.

Modèles de services d'infonuagique

Il existe une liste énorme de services d'infonuagique, mais les meilleurs types de services d'infonuagique sont définis comme suit (les autres types sont basés uniquement sur ces types de services) :

• Infrastructure en tant que service (IaaS) : elle fournit l'infrastructure, à savoir l'entreposage, les machines virtuelles,...
• Plateforme en tant que service (PaaS) : cela fournit un environnement à la demande pour des activités telles que le développement ou les tests, ou la gestion d'applications.
• Logiciel en tant que service (SaaS) : il fournit des applications logicielles à la demande. Il peut exister différents modèles d'abonnement du fournisseur d'infonuagique sous lesquels vous pouvez vous abonner à des applications logicielles spécifiques.

Structure de l'environnement Azure

L'environnement Azure fournit un moyen d'obtenir ses différents services en utilisant Internet. Le schéma suivante représente un aperçu typique de tous les modèles de services d'infonuagiques :

Il présente IaaS comme un modèle très simplifié fournissant des serveurs et d'entreposage, et SaaS comme le modèle avancé fournissant presque tous les services d'infonuagique.