L'organisation actuelle du code et de la configuration que vous décrivez est structurée par les solutions techniques impliquées. C'est une mauvaise conception qui ajoutera beaucoup de frais généraux dans nos activités de maintenance et ajoutera également beaucoup de pièges sur notre chemin. Au lieu de cela, cette organisation devrait être structurée autour des artefacts que nous déployons.
La raison en est que nous voulons considérer les artefacts ( par exemple une image docker ou un progiciel) comme les objets des verbes suivants:
- construire
- tester
- déployer
pour considérer un ensemble minimal de tâches automatisées que nous voulons effectuer. Si nous voulons changer quelque chose sur la façon dont le verbe de test est implémenté, il est facile de visiter le dossier correspondant à cet artefact dans le référentiel approprié, puis de découvrir les éléments d'automatisation spécifiques à jenkins qui doivent être mis à jour. Au lieu de cela, si les recettes d'automatisation sont structurées autour de solutions techniques, nous devons comprendre à l'improviste que jenkins est impliqué dans les procédures de test et y trouver les éléments d'automatisation liés à l'artefact. Dans des situations complexes, l'organisation autour des solutions techniques rend les mises à jour très difficiles, car nous devons connaître a priori toutes les solutions techniques impliquées dans certains services pour les mettre à jour en conséquence.
Par exemple, un référentiel contenant le code d'un site Web et un micro-service «a» pourrait avoir les sous-répertoires suivants dédiés aux opérations:
./ops/website
./ops/micro-service-a
chacun ayant trois scripts appelés build, testet deploy. Maintenant que l'organisation des éléments d'automatisation a été clarifiée, tournons notre attention vers la configuration.
Les principales conditions et exigences relatives à l'organisation de la configuration sont définies par le deployverbe lorsqu'il est appliqué sur un artefact de type service. Le deployverbe doit avoir les paramètres suivants:
- la version de l'artefact à déployer,
- la cible de déploiement de l'artefact, qui décrit l'environnement concret dans lequel l'artefact déployé s'exécutera ( par exemple, un cluster et des points de terminaison avec lesquels il devrait parler)
- les informations d'identification qu'il doit utiliser pour se connecter à d'autres points de terminaison ( par exemple, des bases de données)
- la configuration d'exécution de (comme la durée de vie des entrées de cache, etc.)
Du point de vue opérationnel, cette ventilation de la paramétrisation correspond aux degrés de liberté naturels du problème de déploiement - en dehors des informations d'identification qui pourraient être regroupées avec la configuration d'exécution, mais il est préférable de les séparer pour éviter de les diffuser négligemment.