Dans ma page À propos de moi je mentionne que j’occupe un poste de DevOps. Mais kesako ?

Voilà ce qu’en dis Wikipedia :

“Le DevOps est un mouvement en ingénierie informatique et une pratique technique visant à l’unification du développement logiciel (dev) et de l’administration des infrastructures informatiques (ops), notamment l’administration système. […], le mouvement DevOps se caractérise principalement par la promotion de l’automation et du suivi (monitoring) de toutes les étapes de la création d’un logiciel, depuis le développement, l’intégration, les tests, la livraison jusqu’au déploiement, l’exploitation et la maintenance des infrastructures. Les principes DevOps soutiennent des cycles de développement plus courts, une augmentation de la fréquence des déploiements et des livraisons continues, pour une meilleure atteinte des objectifs économiques de l’entreprise”

D’accord, ce n’est pas très clair. Pour vulgariser, imaginez un monde coupé en deux. D’un côté les “Devs” (développeurs), qui ont plein d’idées et qui veulent que leurs productions soient distribuées le plus vite possible (pourquoi attendre pour mettre à jour si la nouvelle version est meilleure, avec moins de bug, plus de fonctionnalités …), et de l’autre côté, les “Ops” (opérateurs système, ou administrateur système) qui surveillent leurs ordinateurs, qui fonctionnent bien, et qui ne veulent pas que ça change. Pourquoi changer quoi que ce soit si ce qui est en place fonctionne ? Est-on certain que la nouvelle version ne va pas tout casser ?

Forcément, dans un tel monde, les deux groupes ont des objectifs opposés : L’un veut allez vite et changer de version souvent, l’autre ne veut rien changer dans l’espoir que ce qui est en place reste fonctionnel. Et bien ce monde existe, et il se trouve que nous vivons dedans.

C’est dans ce contexte que la méthodologie DevOps est née. L’idée est de changer ce paradigme, en proposant des outils qui automatiseront les différentes étapes entre le moment ou le dev écris un logiciel fonctionnel (ou une nouvelle version), et son déploiement pour qu’il soit accessible à tout le monde. Et parmi ces étapes, il est primordial d’effectuer des tests pour garantir que l’application ne contient pas de bug. Et comme ces tests sont automatisés, on peut bloquer un déploiement si l’on constate un problème, et donc, on garantit au “Ops” que ce que l’on déploie ne contient rien de problématique, ou en tout cas, que les tests n’ont rien trouvés !

Mais l’approche n’est pas que technique. En effet, il ne suffit pas de fournir des outils qui automatiserons les tâches récurrentes des devs, mais il faut aussi un aspect humain (on n’est pas des bêtes … non ?). Il faut que les équipes communiquent entre elles. Il faut encourager les “Devs” à prendre en compte les problématiques des “Ops” (Ton appli consomme trop de ressources matérielles, elle est complexe à mettre à jour, à maintenir en condition opérationnelles, …), et d’un autre côté, fournir aux “Ops” les moyens de comprendre les besoins spécifiques des “Devs” afin d’adapter la configuration des ordinateurs qu’ils gèrent afin que tout fonctionne bien (J’ai besoin de plus de disque parce que …, qu’elle est la meilleure méthode pour accéder à telle ressource, …).

Donc voilà mon quotidien : Je développe des outils pour les “Devs” et les “Ops”, administre des machines, surveille que les tâches automatisées dont j’ai la responsabilité fonctionnent bien, et joue les négociateurs à mes heures perdues !

Maintenant, vous savez …