Cas pratique ! Dans tout environnement il faut valoriser ses constantes. Que ce soit le nom de l’environnement lui-même, d’un serveur tiers, d’une arborescence… ce n’est pas ce qu’il manque. A la B. Mouret, un fichier de configuration avec toutes ces constantes est défini pour chaque environnement. Malheureusement, quand par exemple une arborescence est redéfinie, il faut, passez-moi l’expression, se pastiller l’ensemble des fichiers à réviser. Comment procéder autrement ?
Voyons donc ici un ensemble de pratiques qu’appliquera la B. Mouret pour tendre vers plus de Continuous Delivery. Au travers de ces quelques principes simples, c’est tout une uniformisation qui en découlera et en conséquence une facilité de maintenance et d’automatisation.
La règle d’or
La règle d’or est de n’avoir une valeur que dans une seule valorisation.
Si vous définissez deux arborescences distinctes qui contient toutes deux par exemple log, c’est qu’un défaut d’uniformisation vous l’impose. C’est sans doute l’occasion de gommer cet exotisme voire de définir votre norme d’arborescence. Si sont définies les deux valeurs Production_Kiwi et Production_Mangue c’est qu’il faut variabiliser Production.
Pas de numéro de version
Une petite parenthèse sur un des principes à appliquer constamment est de ne jamais utiliser le numéro de version dans une définition. C’est à bannir ! Certains me diront que parfois deux versions cohabitent qu’il faut distinguer, comment procéder ? La réponse est : créer des liens.
Pour exemple, l’arborescence /apps/keops_1404. Il faut lui créer un lien /apps/keops -> /apps/keops_1404 , et c’est ce lien qui servira de valeur pour votre constante. Quand vous passerez en version /apps/keops_1410, vous n’aurez (votre automatisation, il va sans dire) qu’à redéfinir le lien /apps/keops -> /apps/keops_1410 .
Ce n’est pas l’objet de cet article, mais je ne peux m’empêcher de fermer la parenthèse en précisant qu’avec une telle pratique le changement vers n’importe quelle version est d’autant plus facile qu’il ne tient qu’à la définition de ce lien.
Découpage
Pour revenir à la B. Mouret, l’erreur commise est de n’avoir envisagé la définition de ses constantes que dans un seul fichier. En effet, la bonne pratique est de séparer par qualité. La valorisation s’effectuera donc en plusieurs passes en s’appuyant sur les différents fichiers de configuration.
Pragmatiquement, pour la B. Mouret, la configuration est séparée en 3 parties : environnement, site, des patrons.
Valorisation environnementale
La définition de l’environnement est transverse et contient tout ce qui définit les environnements de même qualité, production, pré-production, simulation, recette, qualification, ou autre. Chez la B. Mouret, les trois environnements sont : production, simulation, et test.
Pour donner en exemple le fichier env.cfg de production on y lit :
ENV_LETTER=p
ENV_3L=prd
Et vous l’aurez compris, on trouvera ENV_LETTER=s, ENV_3L=sim pour la simulation, et ENV_LETTER=t, ENV_3L=tst pour la test.
Petit arrêt sur image. J’ai pour habitude d’une part de mettre les constantes en majuscules, d’autre part de les préfixer par un trigramme dérivé du fichier de configuration. Aucune idée si cette petite pratique en est une bonne, mais elle me permet de suite d’identifier les constantes et la localisation de leur définition.
Valorisation locale
La définition du site est propre (devinez à quoi ?) à chaque site et contient tout ce qui lui est spécifique. Pour distinguer les pays, autant se servir de la norme ISO-3166 sur 2 caractères. Quant au site lui-même, chez la B. Mouret le choix s’est porté sur une abréviation connue des administrateurs Debian (Cf. 1.3.2 – What are i18n and l10n? du debian-handbook.info) qui consiste à prendre la première et dernière lettre encadrant le nombre de lettres sur deux digits. Ainsi Paris est normalisé p05s, Rouen r05n, Bourges b06s, Londres l07s, Singapour s09r, Shanghai s08i…
Pour donner en exemple le fichier site.cfg de Paris on y lit :
SITE_NAME=Paris
SITE_CODE=frp05s
Valorisation patronale
Enfin, le dernier fichier de configuration et non des moindres, est celui du patron, c’est-à-dire la définition des constantes qui serviront à vos applications. De même qu’on a séparé en 3 dans notre exemple, il est envisageable de séparer un socle de patron applicatif et un fichier de définition par application.
Dans notre cas pratique, on se limite à l’application keops, mais pour la forme je découpe en deux fichiers patron.cfg qui définira l’ensemble des constantes applicatives et app.cfg qui définira les constantes propres à chaque application dont ici l’application keops.
Pour donner en exemple le fichier app.cfg on y lit :
APP_NAME=keops
Pour donner en exemple le fichier patron.cfg on y lit :
PTN_APP=/apps/${ENV_3L}/${SITE_CODE}/${APP_NAME}
PTN_BIN=${PTN_APP}/bin
PTN_LIB=${PTN_APP}/lib
PTN_LOG=${PTN_APP}/log
PTN_DATA=/data/${ENV_3L}/${SITE_CODE}
PTN_RECV=${PTN_DATA}/recv
PTN_SEND=${PTN_DATA}/send
PTN_SERVER_FTP=${ENV_LETTER}_ftpagogo
PTN_SERVER_SMTP=${ENV_LETTER}_mailagogo
Le processus de valorisation
Une fois que tout est défini, la valorisation d’un tel découpage s’opère aisément par la valorisation environnementale, locale, et de l’application pour enfin valoriser le patron.
Pour certaines configurations particulières où les héritages de définitions au sein du patron sont trop nombreuses pour être gérer, il faut prendre la précaution de procéder à plusieurs passes de valorisations.
Imaginons que soient déclarées ces deux valorisations « inversées » :
PTN_RECV=${PTN_DATA}/recv
PTN_DATA=/data/${ENV_3L}/${SITE_CODE}
Après la première passe pour l’environnemnt de simulation de Paris, le résultat concret est :
PTN_RECV=/recv
PTN_DATA=/data/sim/frp05s
Lors de la seconde passe, PTN_DATA est pleinement valorisé et le même environnement le résultat concret est :
PTN_RECV=/data/sim/frp05s/recv
PTN_DATA=/data/sim/frp05s
Ce qui valorise complétement nos constantes pour l’environnement parisien de simulation.
Pour aller plus loin…
Comme il se doit, la B. Mouret prévoit d’avoir deux cycles de vie, et pour cela d’avoir deux environnements sur le même serveur. Comment procéder ?
Le plus simplement du monde, il suffit de « transformer » l’environnement de tests en deux environnements un de test, et un de maintenance, avec chacun un env.cfg qui contiendra par exemple :
ENV_LETTER=t, ENV_3L=tst
ENV_LETTER=m, ENV_3L=mtn
Tous les autres fichiers de configurations sont identiques.
Un nouveau site s’ouvre ? Il suffira de reprendre l’ensemble et de créer un site.cfg comme il se doit.
Encore plus fort : une nouvelle application ? Il suffit de lui déclarer son app.cfg. Vous souhaitez changer l’arborescence ? au lieu de /apps d’utiliser /applications ? Il suffit de mettre à jour la seule valeur de PTN_APP, et le tour est joué pour tous les environnements de tous les sites et pour toutes les applications. De l’utilité de :
La règle d’or est de n’avoir une valeur que dans une seule valorisation.
Conclusion
En conséquence, dans tous les environnements de tous les sites de toutes les applications, se trouveront les fichiers de configurations env.cfg, site.cfg, app.cfg et patron.cfg. La méthode de valorisation et l’usage des constantes seront identiques. Ainsi par un simple jeu de déclarations segmentées, on obtient une uniformisation des environnements.
La maintenance d’un tel système de déclaration est un jeu d’enfant, tout comme les interventions sur vos applications. Où trouver la log sur cette application inconnue ? Même endroit que toutes les autres !
Quant à l’automatisation, il parait évident qu’avec l’uniformisation induite, tout crible ou manipulation peut être aisément envisagé, ne serait-ce qu’en s’appuyant sur ces valorisations de constantes. Une telle mise en place est un pas de plus vers le Continuous Delivery.
Documentation :
http://www.iso.org/iso/fr/home/standards/country_codes.htm