En développement logiciel moderne, et plus particulièrement au moment de publier de nouvelles versions, il faut souvent déployer la même application avec des configurations différentes. Selon l'endroit où le logiciel est déployé et selon d'autres facteurs ou exigences, ces configurations peuvent modifier le comportement de l'application. Quelques exemples de ces variables : plusieurs zones géographiques, de nouvelles langues, des cas d'usage différents, etc.
Au choix du développeur
**Les configurations logicielles expliquées**
Quand je parle de configurations différentes, il est essentiel de comprendre que l'essentiel du logiciel reste identique. Seules quelques portions relativement limitées varient. Imaginons par exemple que vous gériez une chaîne de magasins et que vous deviez déployer un logiciel sur les caisses. La grande majorité des déploiements seront identiques : inutile de prévoir un logiciel entièrement différent pour chaque caisse selon l'emplacement du magasin. Même si, dans certaines situations, cela peut arriver.
Revenons à la configuration. Poursuivons avec l'exemple de l'application de caisse. Chaque poste qui exécute l'application doit avoir un identifiant unique : voilà de la configuration. Selon les pays, la langue par défaut peut varier : encore de la configuration. Et puis il y a les développeurs, qui ont besoin de leur propre environnement de dev : à nouveau, des configurations légèrement différentes. Mais dans tous les cas, le logiciel reste le même. Vous voyez l'idée.
Nous stockons déjà toutes les modifications du code source dans un système de gestion de versions. Dans certains cas, un processus compile ce code source en différents types d'artefacts binaires, d'archives ou de conteneurs Docker. La raison est simple : distribuer plus efficacement la bonne version du logiciel.
Séparer pour mieux valoriser et optimiser
L'artefact logiciel distribué doit correspondre à la configuration de l'environnement dans lequel il s'exécutera ; il s'agit généralement de différents éléments de configuration pertinents à plusieurs niveaux, avec une certaine hiérarchie. Cette configuration peut parvenir à l'application par plusieurs canaux : variables d'environnement, chargement de fichiers prédéfinis contenant les données de configuration, réponses d'appels d'API codés en dur ou configurés (par un autre moyen), entre autres.
L'idée centrale, c'est que cette configuration est dynamique et évolue dans le temps. Vous pourriez bien sûr tout regrouper et déployer l'ENSEMBLE de la configuration PARTOUT à chaque fois, en l'embarquant avec l'application. Mais c'est une démarche inefficace qui peut (et doit) être mieux optimisée. Pour y parvenir, adoptez une cadence distincte pour le déploiement et la publication des données de configuration, séparée de celle de l'application elle-même.
Et c'est là tout l'enjeu de l'optimisation : dissocier la gestion des versions et des données de configuration du code applicatif. Cette séparation est d'autant plus efficace lorsque la configuration dispose de son propre espace de versioning, avec un processus de déploiement dédié pour publier et diffuser les changements. Un processus découplé de celui des déploiements applicatifs, et qui suit sa propre cadence.
Qu'en pensez-vous ?
Merci de votre lecture ! Pour rester en contact, suivez-nous sur le DoiT Engineering Blog , sur LinkedIn DoiT et sur Twitter DoiT . Pour découvrir nos opportunités de carrière, rendez-vous sur https://careers.doit-intl.com .