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.
Débloque les + belles offres tech en 10 mins
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.
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.
Comme vu sur le schéma ci-dessous le DevOps se retrouve quelque part au centre du cycle de release de l’application :
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.
– 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.
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…
Débloque les + belles offres tech en 10 mins
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.
Ça n’étonnera personne si nous affirmons que le monde du développement logiciel est en constante…
En Allemagne, le travail en tandem à temps partiel, aussi appelé « jobsharing » est…
On se retrouve comme d'habitude pour le début du classement qcm saison automne ! Mais…
La saison printemps des tests techniques WeLoveDevs s'est terminée le 31 mai, et c'est Axel…
Se former en tant que développeur autodidacte peut sembler intimidant, mais c'est tout à fait…
Dans le cadre de leurs développements, les entreprises se tournent de plus en plus vers…