Déployer une application Compose Multiplatform sur plusieurs plateformes est une chose. Faire en sorte que ces builds fonctionnent de manière fiable dans un environnement CI/CD en est une autre.
Après avoir travaillé sur le pipeline de mon application Compose Multiplatform, j’ai finalement réussi à automatiser et déployer les trois cibles que je souhaitais :
- 📱 Android
- 🌐 WebAssembly (WASM)
- 🖥️ Desktop
Le résultat est donc un succès, mais le chemin pour y arriver m’a permis de mettre en évidence plusieurs contraintes intéressantes, notamment liées à l’environnement de build.
🎯 L’objectif
L’objectif était relativement simple sur le papier : construire automatiquement les différentes plateformes de mon application Compose Multiplatform depuis une pipeline CI/CD.
L’idée était d’avoir un processus capable de produire les artefacts nécessaires pour chaque cible sans avoir à effectuer manuellement les builds en local.
En pratique, chaque plateforme possède ses propres exigences.
Et c’est là que ça devient intéressant.
📱 Android : rien à signaler
Pour Android, le build s’est déroulé sans difficulté particulière.
L’environnement CI disposait des dépendances nécessaires pour compiler le projet, et la génération de l’application Android a fonctionné comme prévu.
C’est probablement la cible la plus classique dans ce contexte : Gradle, le SDK Android et les outils associés sont bien établis dans les environnements CI modernes.
Le build Android a donc été relativement direct à intégrer dans le pipeline.
🌐 WASM : le petit détail qui casse tout
La partie WebAssembly a été un peu plus surprenante.
Le build fonctionnait correctement en local, mais l’environnement CI rencontrait un problème lié à une dépendance système.
La solution a été d’installer explicitement le package libatomic1 avant de lancer le build :
apt-get update && apt-get install -y libatomic1
Une fois cette dépendance installée, le build WASM pouvait être exécuté correctement.
C’est un bon rappel d’une réalité du CI/CD :
Un projet peut parfaitement fonctionner sur sa machine de développement tout en échouant dans un environnement CI simplement parce que l’image de build ne possède pas les mêmes dépendances système.
Dans mon cas, le problème n’était donc pas directement lié au code Compose Multiplatform, mais à l’environnement Linux utilisé pour effectuer la compilation WASM.
Une petite ligne de commande, beaucoup de temps gagné
C’est typiquement le genre de problème qui peut sembler anodin une fois résolu.
Mais avant de trouver la cause, le message d’erreur ne pointe pas forcément immédiatement vers :
libatomic1
Une fois la dépendance identifiée et ajoutée à l’environnement de build, le problème disparaît.
🖥️ Desktop : le cas particulier de Windows
La cible Desktop a présenté une contrainte différente.
Pour cette plateforme, le build devait être exécuté sur un environnement Windows.
Cela signifie qu’une pipeline Linux classique ne suffit pas nécessairement pour produire l’artefact Desktop attendu.
Il faut donc prendre en compte le système d’exploitation de l’environnement CI lui-même.
C’est une différence importante avec Android ou WASM :
Android → environnement CI standard
WASM → environnement Linux + libatomic1
Desktop → environnement Windows
Le pipeline doit donc être pensé en fonction des contraintes propres à chaque cible.
🧩 Un pipeline CI/CD réellement multiplateforme
Au final, le build ressemble davantage à une orchestration de plusieurs environnements qu’à un simple job unique.
Chaque plateforme possède son propre contexte :
| Plateforme | Environnement | Particularité |
|---|---|---|
| Android | Linux | Aucun problème particulier |
| WASM | Linux | Installation de libatomic1 |
| Desktop | Windows | Build nécessitant Windows |
C’est probablement l’un des principaux enseignements de cette expérience.
Multiplateforme ne signifie pas nécessairement environnement de build unique.
Le code source peut être partagé entre les plateformes grâce à Compose Multiplatform, mais les contraintes de compilation restent propres à chaque cible.
🚀 Le résultat : un pipeline fonctionnel
Après avoir identifié et corrigé ces différentes contraintes, j’ai finalement réussi à faire fonctionner les trois builds :
Android ✅
WASM ✅
Desktop ✅
L’application peut désormais être construite dans le cadre du processus CI/CD avec une stratégie adaptée à chaque plateforme.
Et c’est probablement la partie la plus satisfaisante du projet : passer d’un build qui fonctionne uniquement sur la machine du développeur à un processus reproductible et automatisé.
💡 Ce que j’en retiens
Cette expérience m’a surtout rappelé une chose :
Le CI/CD ne consiste pas simplement à lancer une commande de build sur un serveur.
Il faut comprendre l’environnement dans lequel chaque cible est compilée, identifier ses dépendances et accepter que certaines plateformes imposent leurs propres contraintes.
Dans ce projet, les trois plateformes utilisent le même socle Compose Multiplatform, mais leur chaîne de compilation n’est pas identique.
C’est justement là que l’architecture CI/CD devient intéressante.
On ne cherche pas à forcer toutes les plateformes à fonctionner de la même manière.
On cherche plutôt à construire une pipeline capable de respecter les contraintes de chacune.
🏁 Conclusion
Le déploiement CI/CD de mon application Compose Multiplatform est maintenant opérationnel sur les trois cibles :
Android, WASM et Desktop.
Les difficultés rencontrées ont finalement été assez ciblées :
- aucune contrainte particulière pour Android ;
- installation de
libatomic1pour permettre le build WASM sur Linux ; - utilisation d’un environnement Windows pour le build Desktop.
Ce n’était donc pas un énorme obstacle technique, mais plutôt un exercice intéressant autour de la reproductibilité des builds, de la gestion des environnements et des spécificités propres au multiplateforme.
Et surtout, c’est une étape importante dans le projet : le code est multiplateforme, mais maintenant le processus de livraison l’est aussi.
Mission accomplie. 🚀
No responses yet