Dans ma page À propos de moi je mentionne que j’occupe un poste de DevOps. Mais kesako ?
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 …