Jenkins : pour partir en vacances sereinement

Jenkins, pour que les admin. sys. puissent partir en vacances sereinement

Imagem de capa

L’automatisation du système d’information est critique lorsqu’on est admin. sys. dans une TPE/PME. Mais ce n’est pas suffisant : il ne faut pas que l’admin. sys. soit dans le déclencheur de toutes les tâches automatisées, sinon il reste le SPOF : s’il n’est pas là, rien ne se réalise. Nous allons voir comment répondre à cet enjeux.

Contexte

Nous sommes dans une TPE ou dans une PME. Il y a une équipe technique (informatique), de taille restreinte et une équipe métier, qui utilise l’outil informatique mais qui n’en a pas fait son métier. L’équipe métier demande beaucoup de réalisations à l’équipe technique qui est débordée et ne peut répondre à tous les projets. Elle est limitée par le nombre de personnes mais ne peut augmenter ce nombre car “l’informatique n’est pas le métier principal de l’entreprise”.

Il faut donc automatiser les actions : il faut que toute action qui doit être effectuée souvent soit réalisée automatiquement par un outil. La première question que l’on entend souvent est “Quand automatiser ?”. La réponse est simple : dès que l’on parle d’une fois par mois et que cette action prend un temps significatif à un admin. sys., il est nécessaire d’automatiser.

Automatiser les actions n’est pas suffisant. En effet, si l’équipe est trop restreinte, elle l’est encore plus lors des congés annuels, lorsqu’un admin. sys. est malade, lorsqu’il est à l’extérieur pour rencontrer un client, un partenaire ou bloqué dans ce foutu RER D qui est encore en panne à cause des feuilles, de la pluie fine, de la chaleur, du froid, de la neige, du vent, des animaux sur les voies, des gens sur les voies, des bagages abandonnés, des pannes matérielles, des incendies de poste de signalisation, des … Oups, pardon ! Bref, faisons en sorte que les métiers puissent travailler pendant que l’admin. sys. n’est pas là.

Si l’admin. sys. n’est pas là, il faut pouvoir :

Un élément important à prendre en compte : ces deux points vont être réalisés par des utilisateurs de l’outil informatique, non pas par des techniciens de l’outil. Il faut donc que ce soit simple à faire et simple à comprendre.

Objectifs primaires

Les objectifs primaires sont donc clairs :

Ce sont les points sur lesquels il faut se concentrer.

Choix de l’outil

Au niveau de la mise en œuvre, nous avons choisi Jenkins. En fait, le choix de l’outil n’est pas le plus important. Le plus important est l’alignement de l’outil avec les objectifs primaires et secondaires. Nous avons choisi cet outil car :

Mise en œuvre

Une fois l’outil choisi, il faut l’installer, commencer le déploiement, avoir des retours, les analyser, améliorer la configuration puis avoir des retours, les analyser, améliorer la configuration puis on recommence encore et encore.

Les facteurs de succès chez nous :

Conclusion

L’outil réalise des tâches automatiquement, sans action des admins. sys. Il prévient les utilisateurs qui peuvent réaliser les vérifications de la livraison, en comparant ce que déclare les développeurs (bug fermé dans JIRA) et ce qui est réellement corrigé. Il rend des services alors qu’aucun admin. sys. n’est présent. Les utilisateurs demandent à avoir plus de détails dans les messages pour analyser un éventuel problème ou, au contraire, moins de notifications car ils en reçoivent trop ou d’ajouter une nouvelle tâche Jenkins pour faire Y, … Ils viennent vous voir en vous disant : “tu as vu, le build de X est planté. J’ai vu que c’était lié à une dépendance NPM qui plante, que le développeur a ajouté dans le JIRA PTA-2289” et vous entendent répondre “ha bon ? Je n’avais pas encore vu :-) “ .

Félicitations , l’outil est rentré dans les mœurs ! C’est un beau succès. Vous pouvez partir en vacances sereinement, vous ne serez pas sollicité inutilement.