Vous avez une idée pour une fonctionnalité pointue. Vous vous lancez dans le développement de cette dernière à tâtons. Vous appuyez sur « Publier », faites vos tests et BAM! Tout fonctionne… ou presque… Vous venez de sortir de votre torpeur, après quelques crampes de cerveau à jongler avec diverses problématiques dans votre développement, pour vous rendre compte que… tout ça fonctionne très bien… si on reste dans un cadre statique dans l’environnement de développement! Plusieurs connexions et concepts demandent qu’on les adapte lorsqu’ils changent d’environnement, bien entendu.
Pour les moins habitués, lorsque l’on développe une application avec ses fonctionnalités, on crée nos composantes dans un environnement de développement. Il s’agit d’un lieu « sûr » et disponible pour les développeurs afin qu’ils créent la solution sans altérer l’application qui est utilisée par les utilisateurs / le client.
Ce qui veut dire que, très souvent, nous devons créer des processus dynamiques qui permettent l’adaptation d’un environnement à un autre. La solution la plus simple est d’utiliser les variables d’environnement. Il s’agit d’une composante qui prend une valeur par défaut (pour votre environnement de développement), mais qui peut être écrasée au déploiement de celle-ci dans un autre environnement.
Lors du déploiement d’une variable, la valeur de la variable peut être modifiée:
Cependant, cette solution apporte quelques désagréments. Il s’agit d’une composante et ne prend en compte qu’une seule valeur. Ce qui veut dire que, pour chaque comportement de la sorte de votre solution, vous devez créer une composante qui devra être déployée et modifiée au déploiement. Donc, amène une charge supplémentaire lorsque l’étendue des variables se multiplie. Ça semble être un moindre mal, mais reste néanmoins une gestion qui est souvent oublié ou altérée. Sans oublier que le tout n’est pas « pilotable » par la plupart des utilisateurs. En effet, si le client/utilisateur du système (qui ne joue pas de rôle dans le développement de la solution) désire vire d’autonomie dans son système et, par exemple, souhaite changer la valeur après des modifications de sites Sharepoint, et bien il est forcé de chercher de l’aide pour procéder.
Bien entendu, loin de moi l’idée de dénigrer cet outil de la plateforme, mais plutôt de réfléchir à son utilisation, qui peut être bénéfique pour plusieurs situations, soit dit en passant.
Variable ? Nahhh. Table ? Ouuiiii!
Je vous présente une alternative simple qui demande un peu d’effort pour sa création, mais qui offre une superbe maintenabilité pour vos systèmes. L’idée est de simplement créer une table de configurations système, visant à réunir toutes les « variables » dynamiques de votre système dans un format pilotable, facile à maintenir, facile à utiliser, permet une plus grande complexité et nécessitant qu’une simple migration ou intégration d’enregistrements. Comment on procède ? Je vous explique.
On crée une table avec un nom révélateur qui contient au minimum 2 champs: Nom et Valeur. Ensuite, libre à vous d’y ajouter de la complexité si nécessaire en ajoutant plusieurs colonnes.
Vous utilisez ensuite les mêmes noms d’un environnement à l’autre pour récupérer la valeur pour l’environnement en question.
Voilà! Simplement! Vous n’avez qu’à déployer une seule table après sa création et ajouter les enregistrements nécessaires dans les environnements ciblés (qui peut être fait manuellement ou par automatisme. L’idée est que la manoeuvre est simple et peut être fait par n’importe qui). Également, ce concept vous permet d’analyser l’ensemble de vos variables dans un seul et unique panorama.
Bon développement!