Modèle DevOps

Codez à partir d’un emplacement unique et déployez sur plusieurs cibles dans des environnements de développement, de test et de production qui peuvent se trouver dans votre centre de données local, vos clouds privés ou le cloud public.

Contexte et problème

La continuité, la sécurité et la fiabilité du déploiement d’applications sont essentielles aux organisations et critiques pour les équipes de développement.

Les applications nécessitent souvent un code refactorisé pour s’exécuter dans chaque environnement cible. Cela signifie qu’une application n’est pas entièrement portable. Elle doit être mise à jour, testée et validée lors de son déplacement dans chaque environnement. Par exemple, le code écrit dans un environnement de développement doit ensuite être réécrit pour fonctionner dans un environnement de test et réécrit lorsqu’il atterrit enfin dans un environnement de production. De plus, ce code est spécifiquement lié à l’hôte. Cela augmente le coût et la complexité de la maintenance de votre application. Chaque version de l’application est liée à chaque environnement. La complexité et la duplication accrues augmentent le risque de sécurité et de qualité du code. En outre, le code ne peut pas être redéployé facilement lorsque vous supprimez les hôtes ayant échoué ou que vous déployez des hôtes supplémentaires pour gérer les augmentations de la demande.

Solution

Le modèle DevOps vous permet de générer, tester et déployer une application qui s’exécute sur plusieurs clouds. Ce modèle unit la pratique de l’intégration continue et de la livraison continue. Avec l’intégration continue, le code est généré et testé chaque fois qu’un membre de l’équipe valide une modification du contrôle de version. La livraison continue automatise chaque étape comprise entre une build et un environnement de production. Ensemble, ces processus créent un processus de mise en production qui prend en charge le déploiement dans différents environnements. Avec ce modèle, vous pouvez rédiger votre code, puis déployer le même code dans un environnement local, différents clouds privés et les clouds publics. Les différences d’environnement nécessitent une modification d’un fichier de configuration plutôt que des modifications apportées au code.

Avec un ensemble cohérent d’outils de développement dans des environnements locaux, de cloud privé et de cloud public, vous pouvez implémenter une pratique d’intégration continue et de livraison continue. Les applications et services déployés à l’aide du modèle DevOps sont interchangeables et peuvent s’exécuter dans l’un de ces emplacements, en tirant parti des fonctionnalités et fonctionnalités locales et du cloud public.

L’utilisation d’un pipeline de mise en production DevOps vous aide à :

• Lancez une nouvelle build basée sur les validations de code dans un référentiel unique.
• Déployez automatiquement votre code nouvellement créé dans le cloud public pour les tests d’acceptation des utilisateurs.
• Déployez automatiquement sur un cloud privé une fois que votre code a réussi à tester.

Problèmes et considérations

Le modèle DevOps est destiné à garantir la cohérence entre les déploiements, quel que soit l’environnement cible. Toutefois, les fonctionnalités varient selon les environnements cloud et locaux. Tenez compte des points suivants :

• Les fonctions, points de terminaison, services et autres ressources de votre déploiement sont-ils disponibles dans les emplacements de déploiement cibles ?
• Les artefacts de configuration sont-ils stockés dans des emplacements accessibles dans les clouds ?
• Les paramètres de déploiement fonctionneront-ils dans tous les environnements cibles ?
• Les propriétés spécifiques aux ressources sont-elles disponibles dans tous les clouds cibles ?

Pour plus d’informations, consultez Développer des modèles Azure Resource Manager pour la cohérence cloud.

En outre, tenez compte des points suivants lors de la décision d’implémenter ce modèle :

Scalabilité

Les systèmes d’automatisation du déploiement sont le point de contrôle clé dans les modèles DevOps. Les implémentations peuvent varier. La sélection de la taille correcte du serveur dépend de la taille de la charge de travail attendue. Les machines virtuelles coûtent plus cher que les conteneurs. Pour utiliser des conteneurs pour la mise à l’échelle, votre processus de génération doit toutefois s’exécuter avec des conteneurs.

Disponibilité

La disponibilité dans le contexte du DevPattern signifie pouvoir récupérer toutes les informations d’état associées à votre flux de travail, telles que les résultats de test, les dépendances de code ou d’autres artefacts. Pour évaluer vos besoins en disponibilité, tenez compte de deux métriques courantes :

• L’objectif de temps de récupération (RTO) spécifie la durée pendant laquelle vous pouvez passer sans système.

• L’objectif de point de récupération (RPO) indique la quantité de données que vous pouvez vous permettre de perdre si une interruption du service affecte le système.

Dans la pratique, RTO et RPO impliquent la redondance et la sauvegarde. Dans le cloud Azure global, la disponibilité n’est pas une question de récupération matérielle, qui fait partie d’Azure, mais vous garantit plutôt de maintenir l’état de vos systèmes DevOps. Sur Azure Stack Hub, la récupération matérielle peut être une considération.

Une autre considération majeure lors de la conception du système utilisé pour l’automatisation du déploiement est le contrôle d’accès et la gestion appropriée des droits nécessaires pour déployer des services dans des environnements cloud. Quels droits sont nécessaires pour créer, supprimer ou modifier des déploiements ? Par exemple, un ensemble de droits est généralement requis pour créer un groupe de ressources dans Azure et un autre pour déployer des services dans le groupe de ressources.

Gérabilité

La conception de n’importe quel système basé sur le modèle DevOps doit prendre en compte l’automatisation, la journalisation et les alertes pour chaque service dans le portefeuille. Utilisez des services partagés, une équipe d’application, ou les deux, et suivez également les stratégies de sécurité et la gouvernance.

Déployez des environnements de production et des environnements de développement/test dans des groupes de ressources distincts sur Azure ou Azure Stack Hub. Vous pouvez ensuite surveiller les ressources de chaque environnement et cumuler les coûts de facturation par groupe de ressources. Vous pouvez également supprimer des ressources en tant qu’ensemble, ce qui est utile pour les déploiements de test.

Quand utiliser ce modèle

Utilisez ce modèle si :

• Vous pouvez développer du code dans un environnement qui répond aux besoins de vos développeurs et le déployer dans un environnement spécifique à votre solution, où il peut être difficile de développer du nouveau code.
• Vous pouvez utiliser le code et les outils souhaités par vos développeurs, tant qu’ils sont en mesure de suivre le processus d’intégration continue et de livraison continue dans le modèle DevOps.

Ce modèle n’est pas recommandé :

• Si vous ne pouvez pas automatiser l’infrastructure, l’approvisionnement des ressources, la configuration, l’identité et les tâches de sécurité.
• Si les équipes n’ont pas accès aux ressources cloud hybrides pour implémenter une approche d’intégration continue/de développement continu (CI/CD).

Étapes suivantes

Pour en savoir plus sur les rubriques présentées dans cet article :

• Consultez la documentation Azure DevOps pour en savoir plus sur Azure DevOps et les outils connexes, notamment Azure Repos et Azure Pipelines.
• Consultez la famille de produits et de solutions Azure Stack pour en savoir plus sur l’ensemble du portefeuille de produits et de solutions.

Lorsque vous êtes prêt à tester l’exemple de solution, passez au guide de déploiement de solution CI/CD hybride DevOps. Le guide de déploiement fournit des instructions pas à pas pour déployer et tester ses composants. Vous découvrez comment déployer une application sur Azure et Azure Stack Hub à l’aide d’un pipeline d’intégration continue/livraison continue hybride (CI/CD).