DevOps et AIS : quelle stratégie adopter pour optimiser sa plateforme d’intégration Azure ?

Dans notre précédent article « Comment décliner sa plateforme d’intégration en services Azure avec AIS », nous avons présenté les différents services proposés par Azure pour construire une plateforme d’intégration moderne. Dans ce nouvel article, nous allons découvrir comment les principes DevOps soutiennent ces services et cette plateforme. Nous mettrons en lumière les différents outils DevOps à notre disposition ainsi que les stratégies de CI/CD (intégration et déploiement continus), et les meilleures pratiques associées, assurant ainsi une collaboration fluide entre les équipes et une livraison rapide et fiable des solutions aux utilisateurs finaux.

Quels principes DevOps s’appliquent à notre plateforme d’Intégration ?

Les principes DevOps forment un ensemble de méthodologies visant à transformer la manière dont les équipes de développement et d’exploitation collaborent et déploient des solutions. Cette approche moderne privilégie l’automatisation, l’intégration continue, la livraison continue, l’infrastructure en tant que code (IaC), ainsi que la surveillance des systèmes pour assurer des déploiements plus rapides tout en garantissant leur fiabilité.

Les principes DevOps incluent généralement :

• Culture de collaboration et de communication : encourager une culture où les équipes de développement (Dev) et d’exploitation (Ops) travaillent ensemble (et ne forment qu’une équipe) de manière transparente, et collaborent efficacement.
• Automatisation : automatiser autant que possible les processus de développement, de test, de déploiement et de gestion des infrastructures pour améliorer l’efficacité et réduire les erreurs humaines.
• Intégration continue (CI) : intégrer fréquemment les modifications de code dans un référentiel partagé, suivi d’une série de tests automatisés pour détecter les problèmes rapidement.
• Livraison continue (CD) : assurer que chaque modification de code qui passe avec succès les tests automatisés est déployée rapidement, de manière fiable et cohérente dans l’ensemble des environnements.
• Infrastructure as Code (IaC) : gérer et provisionner l’infrastructure de manière automatique et reproductible en utilisant du code plutôt que des processus manuels.
• Surveillance et feedback : surveiller en permanence les performances des applications et des infrastructures en production, et utiliser les données pour identifier et résoudre les problèmes rapidement. Un article sera prochainement dédié à ce sujet.

Le déploiement des solutions legacy comme BizTalk est principalement manuel et semi-automatisé, impliquant plusieurs étapes distinctes pour la préparation, la gestion des artefacts, la configuration et le déploiement. Les développeurs testent localement, créent leurs packages de déploiement, puis déploient manuellement ou via des scripts. La configuration des composants se fait souvent manuellement, avec une supervision et une gestion directe en production. Les rollbacks sont complexes et nécessitent souvent des restaurations manuelles.

Ces méthodes sont limitées en termes de scalabilité, de temps, et d’automatisation complète, rendant les déploiements plus lents et sujets aux erreurs humaines.

La transition vers le Cloud avec des solutions de la suite Azure Integration Services (AIS) permet une automatisation complète des déploiements, que ce soient des infrastructures ou des charges de travail, réduisant les erreurs et les interventions manuelles. Elle offre une scalabilité automatique, s’adaptant dynamiquement aux charges de travail sans gestion d’infrastructure complexe. Les configurations deviennent plus simples et accessibles. Les déploiements sont plus rapides, modulaires et fiables, améliorant ainsi la réactivité aux exigences du marché. En outre, la maintenance est simplifiée grâce à la gestion des services par le fournisseur Cloud.

Lorsque l’on évoque le DevOps et le principe d’automatisation de déploiement, il est important de bien distinguer deux aspects, que ce soit dans le cadre d’une plateforme d’intégration mais également plus généralement dans le cadre de déploiement de charges de travail dans le Cloud : le déploiement de l’applicatif, et le déploiement de l’infrastructure qui héberge notre applicatif.

Il est conseillé de les séparer pour éviter une dépendance entre les deux, ce qui va permettre une plus grande évolutivité de la plateforme, ces deux aspects ayant des cycles de vie différents. Cela permettra aussi une meilleure sécurité en gérant finement les accès et permissions, ainsi que de faciliter la gestion des erreurs, et la reprise après incident. Nous verrons donc dans un premier temps comment déployer son infrastructure, et ensuite son applicatif.

Comment déployer l’infrastructure de sa plateforme d’intégration ?

L’Infrastructure as Code (IaC) est une méthode de gestion de l’infrastructure utilisant des scripts de configuration, plutôt que des processus manuels. Cette approche permet d’automatiser la création et la gestion des ressources, réduisant ainsi les erreurs humaines et augmentant l’efficacité. Les configurations sont versionnées, facilitant la collaboration et la traçabilité des changements. L’IaC assure une consistance et une répétabilité des environnements, que ce soit pour le développement, les tests ou la production.

L’ensemble des services AIS peuvent aujourd’hui être déployés au moyen de scripts, en utilisant un ou une combinaison d’outils.

Parmi les principaux, on retrouve :

• Terraform :
  • Description : outil open-source qui utilise le langage HCL pour gérer l’infrastructure.
  • Usage : déploiement via la ligne de commande Terraform.
• Bicep :
  • Description : langage de déploiement simplifié pour Azure, qui est une alternative plus lisible et plus facile à écrire par rapport aux modèles ARM JSON.
  • Usage : déploiement via Azure CLI ou PowerShell en utilisant les fichiers .bicep.

• Azure Resource Manager (ARM) Templates :
  • Description : utilise des fichiers JSON pour définir et déployer des ressources Azure de manière déclarative. Les modèles ARM permettent une gestion intégrée et un déploiement cohérent des ressources.
  • Usage : déploiement via le portail Azure, Azure CLI, ou PowerShell.
• Azure CLI :
  • Description : interface en ligne de commande fournie par Microsoft pour interagir avec Azure. Permet de créer, configurer et gérer des ressources Azure via des lignes de commandes.
  • Usage : déploiement via le terminal ou des scripts shell.
• Azure PowerShell :
  • Description : module PowerShell dédié à Azure, permettant de gérer les ressources en utilisant des cmdlets PowerShell spécifiques à Azure.
  • Usage : déploiement via des scripts PowerShell.

Organiser ses scripts d’Infrastructure as Code (IaC) en modules distincts pour chaque composant (API Management, Logic Apps, Service Bus…) est crucial pour maintenir une gestion efficace et évolutive de l’infrastructure. Cette approche modulaire permet de déployer, réutiliser et de tester indépendamment chaque composant, simplifiant les mises à jour et la maintenance. Les modules, qu’ils soient développés par son équipe ou son entreprise, garantissent que les ressources suivent des normes prédéfinies. L’utilisation des politiques Azure en conjonction avec les modules peut renforcer ces normes.

En parallèle des modules, l’utilisation de fichiers de configuration spécifiques aux environnements assure que les déploiements sont adaptables et cohérents à travers différents contextes (développement, test, production).

Cette séparation facilite la collaboration en permettant à différentes équipes de travailler sur des parties distinctes de l’infrastructure sans interférence.

Ci-dessous un exemple d’organisation modulaire d’un projet Terraform pouvant être découpé en différentes couches de déploiement :

Pour tester les scripts Infrastructure as Code (IaC), il est possible de valider la syntaxe des fichiers avec des outils intégrés comme Terraform validate ou az bicep build. Pour les déploiements, il est conseillé d’exécuter les scripts dans des environnements de test pour vérifier leur bon fonctionnement avant la mise en production.

La configuration de pipelines d’intégration continue (CI) permet automatiser les tests à chaque modification du code. Les déploiements peuvent aussi être automatisés via des pipelines, dans des outils comme Azure DevOps, GitHub Actions, Jenkins, GitLab…

Les points clés à retenir : 

• Les templates IaC permettent le déploiement de 1 à n environnements ISO (ou quasi ISO pour des environnements de DEV sous-dimensionnés par exemple) ;
• Utilisez des modules et templates pour organiser et automatiser le déploiement des ressources Azure. L’approche modulaire permet de déployer les composants par couche, groupement logique, etc.
• Utilisez un système de contrôle de version (comme Git) pour gérer les scripts IaC ;
• Configurez des pipelines d’intégration continue et de déploiement continu (CI/CD) pour automatiser le test, la validation et le déploiement des scripts IaC ;
• Il est conseillé d’avoir une gestion centralisée des variables d’environnement et sécurisée des secrets ;
• Il est important de tester ses scripts d’infrastructure avant de les déployer pour éviter toute régression.

Bien que les outils comme ARM et Bicep offrent des avantages spécifiques dans le contexte d’Azure, nous préconisons l’utilisation de Terraform en raison de sa flexibilité et de ses fonctionnalités avancées. Terraform, en tant qu’outil open-source, permet une gestion multi-Cloud et multi-provider, offrant une solution plus universelle et évolutive pour des besoins d’infrastructure complexes. Sa syntaxe est également souvent jugée plus lisible et plus facile à comprendre que les fichiers JSON des modèles ARM, ou que le langage PowerShell par exemple.

Comment déployer l’applicatif de sa plateforme d’intégration ?

Nous venons de présenter le déploiement de l’infrastructure, qui consiste en des déploiements ponctuels pour initialiser et faire évoluer les services de notre plateforme. Dans cette section, nous allons nous concentrer sur le déploiement de la partie applicative. Cela consiste à déployer et configurer les applications nécessaires à l’exécution des flux de travail et processus métier sur l’infrastructure existante.

Déployer l’applicatif hébergé par notre plateforme d’intégration nécessite l’utilisation de différents outils et langages, en raison de la diversité des technologies et solutions que nous utilisons. Pour certains services, nous pouvons tirer parti des outils proposés par Microsoft, par exemple pour déployer les APIs dans API Management, qui offrent de grandes possibilités de personnalisation. Pour des services comme Service Bus, où il n’existe pas de solution clé en main et où nous souhaitons éviter de passer par le portail Azure, nous devons utiliser des outils comme PowerShell ou Terraform.

Pour les différentes solutions AIS, voici les principaux outils pouvant être utilisés :

• API Management :
  • APIOps : cette solution, développée par la communauté et disponible en OpenSource, applique les concepts GitOps et DevOps. Elle permet d’extraire la définition des APIs d’une instance API Management, et de publier des APIs, tout en respectant les principes DevOps (code source versionné, validation des modifications au moyen de Pull-Request…).
  • Autre solution : une autre possibilité pour publier ses APIs dans API Management est d’utiliser des scripts PowerShell. Ils sont néanmoins plus complexes à mettre en œuvre et à maintenir que la solution APIOps.
• Logic Apps :

Ici, il faut distinguer le cas des Logic Apps Consumption (multi-tenant) et Standard (single-tenant), qui n’ont pas le même modèle de déploiement.

• • Consumption : le déploiement de l’infrastructure et de l’applicatif intervient en même temps. Il est possible d’utiliser des outils tels que les templates ARM, des scripts Terraform ou Bicep. Il est également possible d’extraire le template de déploiement en utilisant la commande Get-LogicAppTemplate, après avoir installé le client ARM client tool.
  • Standard : utilisations de pipelines CICD avec des commandes spécifiques. Voir cet article du blog Cellenza pour plus de détails.

• Function Apps : de la même manière que pour les Logic Apps Standard, on utilise une pipeline CI/CD. Le pipeline doit inclure des étapes pour construire le projet .NET, exécuter des tests (si définis), et déployer les artefacts générés vers Azure Function Apps en utilisant des tâches spécifiques comme la tâche AzureFunctionApp@2.
• Service Bus/Event Grid : pour déployer des Queues, Topics ou Souscriptions dans une instance Service Bus ou Event Grid de manière automatisée, on utilise principalement soit des templates ARM, des scripts Terraform ou des commandes Azure CLI.  On intègre souvent ces scripts à la solution d’intégration qui utilisera ces composants, comme des Logic Apps ou Azure Function.
• Data Factory : pour déployer dans Azure Data Factory, on utilise des pipelines CI/CD pour transférer les pipelines Data Factory, au format de templates ARM, entre différents environnements (développement, test, production). On effectue le développement dans une branche de collaboration et on déploie dans les environnements de test et production avec la branche de publication.

Les secrets nécessaires pour les APIs ou les intégrations doivent être publiés directement dans le coffre-fort des clés (Key Vault) pour automatiser la gestion des secrets et éviter toute intervention manuelle après le déploiement.

Ci-dessous un schéma présentant un exemple de chaîne CICD pour déployer l’infrastructure et l’applicatif, avec les différents rôles de validateur sur projet :

Les repository contenant le code source sont distincts pour chaque solution d’intégration : un repo pour l’API Management (APIM), un autre pour chaque Logic Apps contenant le(s) workflow(s) (incluant les connecteurs et services externes comme les queues et topics), et de même pour les Function Apps.

Concernant les tests, ils peuvent être automatisés avec divers outils tels que Postman pour les APIs dans API Management ou xUnit pour les tests unitaires des Function Apps. Ces outils de test peuvent être intégrés avec différents systèmes, mais nous recommandons généralement Azure DevOps ou GitHub Actions pour leur compatibilité avec l’écosystème Azure. D’autres outils comme GitLab et Jenkins sont également disponibles sur le marché.

 Les points clés à retenir :

• Il est important d’automatiser autant que possible les déploiements pour réduire les interventions manuelles et limiter les erreurs humaines ;
• Segmenter les pipelines avec d’un côté les pipelines CI (Continuous Integration) pour packager applications et automatiser les tests et CD (Continuous Deployment) pour déployer le code dans les différents environnements ;
• Il est recommandé de privilégier les déploiements par workload ou par interface pour une meilleure gestion et une plus grande flexibilité ;
• Utiliser un repository distinct pour chaque solution ou application afin de maintenir une organisation claire et structurée du code source ;
• Gérer de manière centralisée et sécurisée les variables d’environnement et les secrets pour protéger les informations sensibles et faciliter la gestion des configurations.

Challenges et bonnes pratiques

Bien que Microsoft et la communauté proposent régulièrement de nouvelles solutions pour améliorer l’expérience DevOps autour des services Azure Integration Services (AIS), il reste néanmoins certains défis auxquels les équipes peuvent être confrontées lors de la mise en œuvre de solutions complexes. Dans cette section, nous présentons certains challenges pouvant apparaitre et mettons en lumière les meilleures pratiques pour les surmonter, afin d’optimiser l’efficacité et la robustesse des processus DevOps.

Challenges

Voici certains défis auxquelles font face les équipes :

• Des solutions et langages différents pour déployer l’applicatif de chaque service d’intégration Azure ;
• Des contraintes techniques de déploiement qui peuvent impacter l’existant et entraîner des temps d’indisponibilité ;
• Une gestion complexe des branches de déploiement pour certains services (ex: Data Factory) ;
• Une équipe d’intégration devant avoir une bonne connaissance DevOps / Git ;
• Certains outils DevOps évoluent rapidement et sont maintenus par la communauté ;
• La mise en place des tests parfois complexe sur certains services.

Bonnes pratiques

Voici quelques bonnes pratiques que nous vous invitons à adopter :

• Versionner l’ensemble du code, que ce soit les scripts d’infrastructure ou le code applicatif (ex : outil Git) ;
• Paramétrer l’ensemble des variables d’environnement et avoir une gestion centralisée (ex : Azure DevOps Libraries) ;
• Mettre en place une stratégie de branching définie et claire (ex : basée sur Git workflow) ;
• Rendre obligatoire la revue de code (ex : utilisation des policies sur branche dans Azure DevOps avec obligation de Pull Request) ;
• Configurer la validation manuelle des déploiements, notamment pour la Production ;
• Définir une stratégie de test pour l’infrastructure et l’applicatif ;
• Documenter le code infrastructure et applicatif (ex : Azure DevOps Wiki).

Ce qu’il faut retenir

En conclusion, l’intégration des principes DevOps dans la gestion des services Azure Integration Services (AIS) représente une avancée majeure vers une plus grande efficacité et fiabilité dans le développement et le déploiement des solutions d’Intégration.

La transition vers des méthodes modernes comme l’Infrastructure as Code (IaC) et les pipelines CI/CD facilite non seulement l’automatisation des processus mais aussi l’élimination des erreurs humaines, tout en optimisant la scalabilité et la maintenabilité des solutions.

Certains défis demeurent, liés à la diversité des outils pour les déploiements et à la gestion des branches de déploiement complexes pour certains outils. Pour surmonter ces obstacles, il est crucial de rester attentif aux évolutions proposées par Microsoft et la communauté, et d’adopter des bonnes pratiques telles que le versionning du code et la mise en place d’une stratégie de branching claire. Il est important de garder à l’esprit que l’objectif est d’automatiser entièrement les processus de déploiement, y compris la création d’infrastructure partagée, le déploiement du code, et la configuration des variables d’environnement. Ainsi, en suivant ces recommandations, la plateforme d’intégration AIS pourra tirer pleinement parti des avantages des pratiques DevOps.

Dans le prochain article, nous reviendrons sur la surveillance et le monitoring des solutions et flux au sein de notre plateforme d’intégration AIS, en explorant les meilleures pratiques et les outils essentiels pour assurer une visibilité complète et une gestion proactive des performances et des incidents.

Vous souhaitez en savoir plus sur le développement d’une plateforme d’intégration moderne ? Consultez les autres articles de cette série :

• Pourquoi développer une plateforme d’intégration moderne ?
• Comment décliner sa plateforme d’intégration en services Azure avec AIS ?
• Pourquoi utiliser Azure Integration Services ?
• Comment superviser sa plateforme d’Intégration : enjeux et bonnes pratiques