Automatisation des déploiements
Dans mon précédent article, nous avons parlé de l’automatisation de la qualité et de la sécurité de son application. Mais la finalité de l’automatisation, à la base, c’est de pouvoir facilement la déployer sur nos environnements cible.
Avant de pouvoir déployer notre application, il faut déjà « packager » l’application, et suivant les technologies utilisées, c’est plus ou moins complexe.
On transpile ou on compile ?
Pour éviter les confusions de vocabulaire, je souhaites commencer par une nuance qui me paraît importante à souligner, entre compilation et transpilation.
Lorsqu’on parle de compiler son programme, c’est pour cibler le format binaire, ou bien un format de bytecode.
Le format binaire utilise des instructions spécifiques au CPU sur lequel sera exécuté le programme. Il est donc fortement lié au matériel de l’utilisateur qui va se servir de notre programme.
Le bytecode est un format un peu plus haut niveau, qui lui est portable dans tout système pour lequel il existe un environnement d’exécution de ce bytecode. Par exemple, des langages comme Java ou Python permettent une compilation vers un format bytecode.
La transpilation est le mécanisme de traduction d’un code développé en local vers Javascript, HTML et/ou CSS, pour le rendre exploitable par le navigateur web. La transpilation n’est pas spécifique au web, car elle vise une traduction d’un langage haut niveau (comme Typescript) vers un autre langage haut niveau (comme Javascript), mais le web est de loin le cas le plus courant.
Pour le navigateur web, nous pouvons également cibler le wasm, qui reprend un format plus bas niveau pour accroître la performance. Cette possibilité brouille un peu les pistes, mais il s’agit pour le coup de compilation, car wasm est un format binaire.
La transpilation est considérée comme un cas particulier de compilation, mais je préfère personnellement bien noter la nuance, car l’usage n’est pas le même.
Packaging d’application
Fort bien. Que nous le compilions, ou nous le transpilions, nous devont ensuite distribuer notre application.
Pour celà, nous allons empaqueter notre application. Et le terme n’est pas anodin : il s’agit bel et bien de la mettre … dans un paquet !
Le type de packaging peut se ranger dans deux catégories différentes.
En fonction du langage de programmation, ou plus exactement l’outil de packaging de ce langage. Par exemple, nous aurons des paquets pip pour Python, ou des paquets npm pour Javascript.
En fonction du système d’exploitation ciblé : Typiquement, sous Linux, on aura des paquets deb pour les distributions Debian ou Ubuntu, ou des paquets rpm pour les distributions Red Hat ou Suse. Nous avons également les paquets dmg sous Mac, et msi sous Windows (à noter que les exe, qui sont directement exécutables, sont également très courants, sous Windows).
Il existe aussi un mode de packaging plus « artisanal » : on peut utiliser un format compressé comme un fichier zip, ou ce qu’on appelle une tarball (la principale différence à comprendre à notre niveau, étant que ces formats se distinguent sur la façon de compresser les fichiers). Dans un cas comme dans l’autre, nous parlons aussi d’archive, pour désigner le fichier compressé. Il faut garder à l’esprit que, bien souvent, les formats dépendants du langage de programmation ou du système d’exploitation utilisent les mêmes règles de compressions que les fichiers zip ou tarball. L’ajout concerne surtout la façon dont les fichiers sont organisés à l’intérieur de l’archive, et parfois l’ajout de quelques métadonnées décrivant le contenu du paquet.
Déploiement de son application
Parce qu’on n’a pas fait tout ça pour rien, quand même !
Le déploiement peut se décomposer en quatre grandes étapes.
La première étape consiste à envoyer notre paquet sur l’environnement cible (intégration, pré-production, production, … cf. R2PL pour plus de détails) : Pour cela, on peut utiliser une connexion FTP (SFTP, pour la sécurité, comme HTTPS est la version sécurisée de HTTP), ou bien SSH (un protocole qui permet d’ouvrir un accès sécurisé entre deux ordinateurs/serveurs).
Ensuite, on va extraire et installer le paquet : Cette étape se résume bien souvent à déplacer les fichiers à l’emplacement adéquat sur le serveur. Les paquets, qu’ils soient spécifiques au langage de programmation ou au système d’exploitation ont cet avantage qu’ils permettent d’automatiser ce placement des fichiers.
Une fois l’application installée, on passe à l’étape de configuration. Cette partie est spécifique à l’application mais aussi à l’environnement sur lequel le déploiement est fait. Pour un environnement de production, il faut être particulièrement attentif aux paramètres d’authentification et d’accès aux dépendances, pour s’assurer qu’aucune donnée sensible (exploitable pour obtenir l’accès à la plateforme de l’application) ne soit exposée. Celles-ci doivent être stockées de façon sécurisée au niveau de la CI (Gitlab CI ou Github Action), de sorte qu’elle ne soient pas exposées. Par exemple, Gitlab propose un mécanisme pour cacher le contenu des variables d’environnement dans les logs. Pour aller plus loin, il est également possible d’intégrer une solution comme Hashicorp Vault, grâce à quelques lignes supplémentaires dans sa configuration de sa pipeline de CI.
Tout ceci fait, on peut enfin passer au vif du sujet : Exécuter l’application. Il s’agit bien souvent de l’enregistrer dans le serveur avec lequel elle est exposée aux clients, typiquement un serveur NginX.
Conclusion
Lorsqu’on « vibecode » son application, on ne penses pas forcément au déploiement. L’IA va alors nous orienter vers des solutions adaptées à une version test de notre application.
Mais avec les bons outils, on peut rapidement industrialiser les déploiements et maintenir notre application en production.
Après avoir bien contrôlé la qualité et la sécurité de son code, une bonne pipeline permet de :
- Compiler (ou transpiler) son code,
- Le packager pour l’environnement cible, et
- Le déployer sans souffrance.
Write a comment