Qu’est-ce que la CI/CD et pourquoi en avons-nous besoin ?

L’intégration continue (CI) et le déploiement continu (CD) sont comme une équipe parfaitement coordonnée de football. Chaque passe représente une étape automatisée, menant à un but : la mise en production fluide d’une application. Ce procédé vise à automatiser les tests afin de réduire les bugs et les régressions, les builds dans un environnement maîtrisé et les déploiements pour réduire les erreurs humaines, accélérer les cycles de livraison et garantir la qualité du code. 

Dans un contexte de projet MuleSoft, un pipeline CI/CD permet d’assurer une livraison fiable des services dans des environnements distribués tout en assurant une cadence fluide, comme une équipe de sprinters passant le relais.

Le déploiement MuleSoft

Le déploiement d’une application MuleSoft peut être effectué de plusieurs manières, chacune ayant ses propres avantages et inconvénients. Dans cet article, nous allons vous présenter certains parmi les plus utilisés.

1. Via Anypoint Studio (IDE de MuleSoft)

Anypoint Studio offre une interface intuitive pour concevoir, tester et déployer des applications Mule. Le déploiement peut se faire directement depuis l’IDE en se connectant à Anypoint Platform. Bien que cette méthode soit particulièrement pratique pour les développeurs lors de la phase de développement, elle n’est pas adaptée aux environnements de production, car elle manque d’automatisation et de contrôle de version.

2. Chargement manuel d’un JAR sur CloudHub

Cette méthode peut être comparée à un athlète individuel devant porter tout l’enjeu de la compétition sur ses épaules. 

Dans cette méthode de déploiement, il faut construire un fichier JAR de l’application et le charger manuellement sur CloudHub via Anypoint Platform. Cela peut convenir pour des tests ponctuels d’infrastructure ou de déployer un outil de diagnostic / démo qu’on a sous la main. Cependant, ce procédé possède des failles de sécurité, car en récupérant le JAR nous avons le projet. De plus cette méthode possède plusieurs facteurs de risque de bug et manque de flexibilité pour des équipes DevOps professionnelles.

3. Utilisation de Mule Maven Plugin

Le Mule Maven Plugin est comme un entraîneur chevronné qui planifie chaque détail pour garantir une exécution impeccable. C’est l’approche la plus robuste et professionnelle pour déployer des applications MuleSoft, en particulier lorsqu’il s’agit de mettre en place un pipeline CI/CD.

Avec Mule Maven Plugin, nous avons la possibilité de facilement intégrer les déploiements dans des outils comme Jenkins, GitLab CI/CD, Azure DevOps et plein d’autres. Cette méthode de déploiement permet de sécuriser les données comme les identifiants d’authentification ou les clés API en les injectant durant le build de l’application plutôt que de les stocker dans Git ou sur des postes de travail, offrant une sécurité accrue et réduisant les risques de fuite. Sans oublier la facilité d’automatisation avec les commandes Maven et la flexibilité que ça peut apporter. 

Déploiement avec le Mule Maven Plugin

Pourquoi choisir Mule Maven Plugin ?

En tant que surcouche de Maven, Mule Maven Plugin s’intègre facilement aux systèmes de déploiement supportant Maven, comme nous avons vu dans le paragraphe précédent.

Sans oublier des nombreux avantages directs:

• Automatisation : Il permet d’automatiser le processus de build et de déploiement en utilisant les fonctionnalités avancées de Maven.
• Contrôle des versions : En intégrant Git, vous pouvez suivre les modifications et revenir rapidement à une version stable en cas de besoin.
• Support multi-environnements : Grâce à ses configurations flexibles, il facilite les déploiements dans différents environnements (DEV, TEST, PROD).
• Sécurité des données : Mule Maven Plugin permet d’injecter les secrets (ex. : identifiants, mots de passe) directement au moment du build, sans qu’ils soient stockés dans Git ou sur des postes de travail. Cela garantit une confidentialité optimale et réduit les risques de fuite.

Étapes pour configurer le déploiement

1. Configurer votre fichier settings.xml
Pour les utilisateurs de maven classic, ce sera comme une petite piqûre de nostalgie. Cependant, il est important de mentionner la configuration de fichier settings.xml. C’est ce fichier qui va permettre à votre plugin maven d’aller chercher des dépendances en local ou sur des dépôts distants si besoin. Dans le contexte MuleSoft, ce fichier va également renseigner Mule Maven comment se connecter à votre CloudHub et (spoiler alert) utiliser les identifiants qui peuvent vous être fournis par l’équipe de support MuleSoft pour récupérer des dépendances de dépôt Nexus.

2. Préparer le fichier pom.xml
Le fichier pom.xml contient les dépendances et configurations requises pour le déploiement. Voici les éléments à configurer :

• • Configuration des repositories (ex. : MuleSoft Enterprise Repository).
  • Propriétés pour les identifiants client et secrets.
  • Plugin Mule Maven avec les détails de l’environnement cible.
    

3. Configurer les identifiants dans Anypoint Platform
Créez une application connectée pour générer des identifiants (Client ID et Secret). Ces derniers peuvent être référencés dans le fichier pom.xml pour simplifier les configurations. Cependant, pour une sécurité optimale, il est recommandé de les injecter dynamiquement comme variables d’environnement durant le processus de build, afin d’éviter qu’ils ne soient exposés dans le code ou les postes de travail.

4. Commandes Maven
Les commandes suivantes sont souvent utilisées pour les tests:

• • mvn clean test : permet de lancer l’intégralité des tests unitaires du projet. 
  • mvn clean test -Dmunit.tags=<munit-tag> : permet de lancer les tests possédant un tag spécifique défini au niveau de chaque test unitaire au sein du projet. 
  • mvn clean test -Dmunit.test=<regex-test-suite> : permet de lancer un test spécifique ou un ensemble de tests qui matche une expression regex.

Les commandes suivantes sont souvent utilisées pour le déploiement:

• mvn clean package : Pour construire l’artefact. Par exemple, si vous devez inclure des secrets ou des mots de passe, vous pouvez les passer comme variables Maven dynamiques au moment du build, sans les enregistrer dans le code ou sur un poste de travail :

mvn clean package
-Danypoint.platform.client.id=client-id-value
\-Danypoint.platform.client.secret=client-secret-value
\-Denv.password=my-secure-password
\-DskipTests

Ainsi, ces informations sensibles sont injectées uniquement pendant le processus et restent sécurisées.

• mvn deploy : Pour déployer l’artefact sur Anypoint Platform.

5. Intégration dans un pipeline CI/CD

• • Utilisez un outil comme Jenkins ou GitLab pour automatiser l’exécution des commandes Maven.
  • Configurez des triggers pour exécuter le pipeline sur chaque commit ou merge dans des branches spécifiques.
  • Ajoutez des étapes de validation, comme des tests unitaires avec MUnit, avant le déploiement final.

Conclusion

Avec un pipeline CI/CD bien huilé et l’utilisation du Mule Maven Plugin, vos projets MuleSoft bénéficient d’une structure stable et évolutive. Ce processus garantit une livraison fluide, tout comme une équipe de rugby coordonnant chaque passe pour marquer un essai. Les secrets restent sécurisés grâce à leur injection dynamique lors des builds, et les tests unitaires via MUnit permettent de contrôler les régressions et d’assurer la qualité. Enfin, la possibilité de rollback rapide en cas de problème offre une confiance accrue à chaque déploiement.