Passer au contenu principal

La mouvance DevOps est à la mode. Alors oui c’est encore du blabla marketing pour quelque chose qui relève du bon sens, cela dit la taylorisation du développement n’a pas aidé non plus. Aussi nous évoquons ici les qualités que doit avoir un bon DevOps.

Nous avons déjà traité du sujet de la démarche DevOps dans une série d’articles, aussi nous n’allons pas reprendre le sujet. De même nous avons évoqué l’idée qu’un bon développeur se doit d’être curieux et rigoureux, aussi nous n’allons pas nous répéter là-dessus, mais parler des autres sujets.

Pour rappel aux entreprises : un DevOps ne pourra rien faire si le management ne l’accompagne pas. En effet les gens ont tendance à être résistants au changement et sans soutien de la hiérarchie il est impossible de faire avancer les choses.

Etre rigoureux

La démarche DevOps consiste en fait à mettre en place du continuous delivery. Cela nécessite notamment de mettre en place de la confiance dans ce qui est livré car il faut être prêt à relivrer souvent. Autrement dit un DevOps qui ne voudrait pas mettre en place de tests automatisés n’en est tout simplement pas un, c’est juste un blagueur. En effet les applications actuelles sont devenues très complexes et il humainement impossible de tout tester à chaque nouvelle release dans des temps raisonnables.

Un DevOps ne devra donc pas hésiter à faire du pair programming avec les développeurs pour les aider à mettre en place les tests et leur instiller de bonnes pratiques de code. Cela implique que le DevOps est lui-même un bon développeur. Dans un premier temps il assumera notamment le rôle de chien de garde sur le code et se doit donc de maîtriser les bonnes pratiques.

Savoir dialoguer avec tout le monde… y compris les testeurs

Pour pouvoir mettre en place du continuous delivery, un DevOps devra dialoguer avec les dévs et les gens de la production, mais également avec les testeurs. Ce sont eux qui donnent le coup de tampon pour livrer en production, aussi il faut qu’ils interviennent très rapidement dans le développement de l’application. En aucun cas les testeurs ne doivent tester que quand les développeurs estiment que c’est bon. En fait ils doivent intervenir dès le début pour écrire les scenarii de tests et les implémenter en pair-programming avec les développeurs.

Comme vu sur le schéma ci-dessous le DevOps se retrouve quelque part au centre du cycle de release de l’application :

Etre intéressé par les problématiques système

Les DevOps doivent aussi dialoguer avec les gens de la production, notamment pour savoir ce que ceux-ci attendent des développeurs mais aussi pour qu’ils ouvrent un peu les vannes notamment en terme de logs de l’application et de plateforme logicielle exacte installée. En effet les développeurs devraient travailler sur un environnement logiciel qui est le même que celui de la prod, même OS et mêmes versions des librairies.

De même un DevOps ne doit pas perdre de vue que le rôle de quelqu’un de la prod doit se résumer à appuyer sur un bouton pour déployer l’application et appuyer sur un autre pour la configurer. Cela implique notamment qu’il doit fortement s’intéresser au packaging des livrables afin d’avoir des processus d’installation répétables et traçables. A ce niveau la meilleure politique est d’utiliser le système d’installation natif à la plateforme cible, aussi un DevOps doit avoir la curiosité d’apprendre à packager une application pour une plateforme cible donnée. En effet les processus d’installation doivent être répétables, et un document au traitement de texte ne l’est clairement pas.

Les gens de la prod n’ont par ailleurs pas l’habitude de versionner leur configuration. Aussi il doit les former à l’utilisation d’outils permettant une mise en place rapide de la configuration comme Puppet, et former les dévs pour qu’ils créent des templates de fichiers de configuration préremplis là où c’est possible. Par ailleurs il doit faire prendre conscience aux gens de la production que ce qui compte est d’être capable de remonter rapidement une machine, pas de la sauvegarder intégralement, aussi il est important que les fichiers de configurations soient sauvés dans un gestionnaire de versions pour cette raison. Les seules données qui comptent sont en effet celles des utilisateurs.

Etre souple sur les outils

Un DevOps ne doit pas venir et imposer ses outils. Au contraire il cherchera à s’adapter aux outils de l’entreprise quand ceux-ci existent. Par exemple si un serveur d’intégration continue a été mis en place il essaiera dans la mesure du possible de le réutiliser. Après il y a quelques cas où les outils peuvent être imposés :

– Un des outils nécessaires pour la mise en place du continuous delivery n’est pas encore présent, ou alors il a des limites bloquantes.
– Un des outils est un développement in-house. Dans ce cas il sera souvent préférable de le remplacer par une solution du marché, même si ce n’est pas toujours possible politiquement.
– Le déploiement ne se fait pas en utilisant les outils de la plateforme cible : dans ce cas on cherchera à le faire.

En bref

Un bon DevOps doit à la fois avoir des connaissances en développement et au niveau système. Par ailleurs il devra savoir dialoguer avec les testeurs pour mettre en place la démarche.

Cela dit en tant qu’entrepreneur vous serez amené à remettre en cause pas mal de choses du fait de la mise en place du continuous delivery. Autrement dit il faut que l’initiative ait des appuis suffisamment puissants au niveau de la hiérarchie pour avoir une chance d’être mise en place, avec des chefs qui sachent s’imposer auprès des récalcitrants.

Un dernier point : un antipattern qu’on retrouve parfois est une « cellule DevOps » isolée, qui n’est ni en contact avec le devs, ni avec les ops, et encore moins avec les testeurs, mais qui est juste là pour faire du packaging. Dans ce cas il ne s’agit pas d’un poste de DevOps mais d’un poste d’intégrateur. Le boulot de DevOps implique d’être sur le terrain et physiquement à côté des équipes. Si on vous prend comme DevOps et que ce n’est pas le cas, je vous conseille vivement de prendre vos jambes à votre cou…

Cet article vous a plu ? Vous aimerez sûrement aussi :

Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.

Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.

Son Twitter Son LinkedIn

Laisser un commentaire