Prérequis à l'automatisation : les conventions

By Denis Fabien
2022-04-29

Ami du jour, bonjour !

Lorsqu'on me demande d'intervenir sur un dossier d'automatisation, une des premières questions qu'on me demande est souvent : Je commence par quoi ?

Voici un petit check-list non-exhaustif des prérequis en grande entreprise.

Ces prérequis vont souvent se régler en deux minutes dans une petite compagnie, mais plus elle est grande, plus ça va être long... et pénible. Mon conseil, faites-vous accompagner par une équipe en gestion du changement.

Les conventions

Quelque soit votre projet, vous allez devoir mettre en place ou modifier des conventions. Plus tôt vous le faites, mieux ce sera !

Convention de typographie

La première, et la plus importante. Si vous êtes comme moi et que des trucs comme : MoN_PROjet.Com vous font pousser des boutons sur la face, on se comprend.

Globalement, il y a deux choix possibles :

- CamelCase : d'origine écossaise selon Wikipedia, la première lettre du mot s'écrit en majuscule, le reste en minuscule, aucun espace : ConnorMacLeod

- snake_case : tout en minuscule, les espaces sont remplacés par des underscore : je_suis_une_chaine_snake_case

Quelque soit votre choix, il va être très important de l'imposer et d'interdire les exceptions, dans les automatismes les exceptions ca devient des bugs !

J'ai eu le cas de noms qui sont des initiales comme SCCM (System Center Configuration Manager). Même si certains vous diront que ce n'est pas joli, cela doit devenir : Sccm ou sccm (en fonction de la convention choisie).

Convention de nommage des organisations

Peu importe l'outil que vous allez utiliser, vous allez avoir la notion d'organisation. Certains outils vont appeler cela des organisations, des projets ou des groupes... Le résultat est le même : ça désigne un sous-groupe dans votre compagnie.

À terme, ce sous-groupe devrait être une équipe agile qui va être responsable d'un outil (produit).

Convention de nommage des serveurs

Ici, on touche au plus sensible. Dans les grandes compagnies, souvent l'auteur de la précédente convention est encore en place et va prendre toute suggestion de changement comme un affront personnel. Ne perdez pas en tête qu'il est mportant de vous assurer que la convention va bien supporter l'automatisation.

Vous allez avoir le débat du : On veut le plus d'info possible dans le nom vs pour des principes de sécurité on en veut le moins possible.

Si avant bâtir 200 serveurs par année était un exploit, une fois l'automatisation mise en place, ce sera peut-être 200 serveurs de test qui pourraient être bâtis par jour. Une séquence de trois ou quatre chiffres ne fonctionne plus.

Il est recommandé d'avoir une convention qui contient au minimum :

  • une info sur l'outil de montage (la source du nom), ex : a=vRealize Sandbox, b=CloudForms production, c=vRealize dev...
  • le type de "hardware" (Cloud privé, Aws, google...), ex : p=private cloud, a=aws, z=azure...
  • une séquence de chiffres d'au moins 8 chiffres (incrémentale et jamais le même chiffre utilisé plusieurs fois)

Ainsi, un exemple pourrait être :

([a-z])([a-z])([0-9][0-9][0-9][0-9]0-9][0-9][0-9][0-9])

ou

  • ap00000001 => Serveur monté par vRealize Sandbox sur un private Cloud
  • ca00000002 => Serveur monté par vRealize Dev sur aws

Convention de nommage des repo git

Qui dit automatisation, dit repo git ! Vous allez sûrement avoir beaucoup de repo, donc ici aussi, je vous recommanderai, dès le départ, de convenir d'une convention pratique à comprendre.

Pour ma part, j'aime bien cette convention :

<3 lettres qui désignent l'outil/techno principal>-<3 lettres qui désignent la cible>-<1 a 12 lettres qui decrivent le contenu>

Quelques exemples :

  • pyt-vra-cloudtemplate : on fait référence à une librairie Python pour parler à vRealize Automation et populer les cloud templates
  • tfe-vra-cloudtemplate : un repo Terraform qui contient des Cloud Template vRealize Automation
  • ans-win-sccm : un script Ansible pour windows qui installe SCCM
  • ans-lin-httpd : un script Ansible pour linux qui installe httpd

Autres conventions ?

Essayez toujours de partir la "track" des conventions le plus tôt possible dans votre cheminement vers le devops et l'automatisation. Vous allez découvrir que certaines seront de vraies guerres de tranchées qui prendront du temps et probablement l'intervention des patrons pour accorder tout le monde.

Suivant votre contexte d'affaires, vous aurez aussi d'autres conventions à mettre en place, tel que le nommage des pipelines par exemple.

Ces convention sont "peu intéréssantes" a faire, mais elles vous permettront plus tard de vous y retrouver beaucoup plus facilement. Si vous ne le faites pas dès le debut, vous paierez le fort prix plus tard.

Sur ce, Ami du devops, je vous souhaite plein de jolies conventions !