On parle de plus en plus de la démarche DevOps, encore un terme marketing à la mode, comme Agile ou encore le lean management. Et pourtant derrière il y a une réponse à une réelle problématique rencontrée, hélas, de plus en plus souvent dans l’industrie.
Débloque les + belles offres tech en 10 mins
Beaucoup de ceux qui me liront le confirmeront : rester jusqu’à trois heures du matin, voire tout un week-end pour fixer une mise en prod’, ça ne fait pas franchement rêver, et ce même si votre employeur vous offre (parfois !) gracieusement les pizzas. Et les jours suivants ne sont guère mieux, avec tous les fixes réalisés à l’arrache avec un maximum de stress.
Dans de nombreux cas les développeurs pensent que leur travail s’arrête lorsqu’ils ont appuyé sur le bouton « commit » de leur gestionnaire de version. Erreur… en effet souvent leur bout de code s’intègre (ou pas) avec le travail d’autres développeurs, produisant ainsi de nombreux bugs sur lesquels ils n’auront un retour que plusieurs mois après, quand ils auront eu le temps d’oublier pour quelle raison ils ont fait tel ou tel changement. Et comme le code est rarement documenté, ça revient à faire de l’ingénierie à rebours sur son propre code, la classe !
Les gens de la production au contraire sont garants de la stabilité des systèmes. Dès lors leur mot d’ordre est de ne jamais changer un système qui marche. Là encore ce n’est pas forcément une bonne idée ne serait-ce que parce qu’il faut maintenir les systèmes d’exploitation à jour pour garantir leur sécurité, sinon gare au piratage. Mais cette philosophie vient aussi du fait que bien souvent, les applications à déployer n’ont jamais été vraiment testées avant leur mise en production.
Partant de ce constat, des informaticiens se sont penchés sur le problème et en ont écrit un livre dénommé le continuous delivery. Cet excellent ouvrage est en fait la base de la démarche DevOps. Il s’agit en fait d’une fluidification des processus de livraison qui garantissent une meilleure qualité des livrables et une approche plus zen des mises en production.
La philosophie derrière le continuous delivery est qu’en fait, à chaque commit, je produis un livrable susceptible de partir en production, à travers différentes méthodes :
L’intégration continue se fait avec ce qu’on appelle un serveur d’intégration continue. Le plus connu d’entre eux est Jenkins. Tous reposent sur le même principe : ils scrutent votre gestionnaire de sources et lorsque un commit est détecté, ils relancent automatiquement les processus de build. Si le build échoue, le développeur responsable du commit ayant cassé le build se doit de le corriger le plus vite possible. Et contrairement à ce qu’on pourrait penser ça implique de faire des commits très fréquents, au moins un par demi-journée. En effet, il n’y a rien de pire que d’avoir un commit impactant des centaines de fichiers et ne pas savoir ce qui a coincé.
L’utilisation d’un serveur d’intégration continue implique donc une plus grande rigueur dans les processus de développement, mais finalement c’est ceci qui permet d’être plus zen à l’approche de la deadline.
L’intégration continue a comme principal intérêt de permettre également l’exécution de tests automatisés. Ceux-ci permettent d’avoir davantage de contrôle sur ce qu’on a fait, pour vérifier en particulier que le code modifié n’implique pas de régression. En effet, hormis dans quelques langages tels que le Haskell, le fait qu’un code compile ne garantit en rien qu’il s’exécutera correctement. Une bonne technique pour mettre en place des tests unitaires est le test driven development (TDD), dont nous reparlerons dans d’autres articles. Ceci permet de couvrir les tests unitaires. Maintenant il faut aussi mettre en place des tests dits d’intégration qui sont plus poussés ainsi que, dans la mesure du possible, des tests fonctionnels automatisés.
Dans le cadre du continuous delivery les testeurs sont partie prenante. En effet les applications contiennent généralement des milliers de cas d’utilisation qu’il n’est pas possible humainement de tester à chaque livraison, et même si les gens y parviennent il reste plein d’autres choses à tester, par exemple tous les cas limites, la tenue en charge, la sécurité et ainsi de suite. Bref en automatisant une grosse partie des tests on allège le travail des testeurs, et ceux-ci peuvent davantage intervenir là où ils ont de la vraie valeur ajoutée, à savoir le test de tout ce qui est visuel et certains tests vraiment complexes.
Dès lors les testeurs doivent coopérer avec les dévs pour que la majorité des cas d’utilisation soient codés et non exécutés manuellement. De tels tests sont souvent rédigés de la sorte :
Comme dit ci-dessus les responsables de la production sont très réticents au changement, en raison du fait qu’ils sont responsables de la bonne marche des systèmes. Rien ne leur fera plus peur qu’un manuel d’une centaine de pages expliquant la marche à suivre, notamment parce que les typos dans ce type de document sont inévitables, et que le copier/coller n’est jamais terrible non plus. On peut imaginer un système ayant une variable d’environnement nommée BASE_DIR. Maintenant si dans le document il est écrit :
rm -rf $BASSE_DIR/
… pas la peine de faire un dessin.
C’est là qu’intervient le packaging. Bref les développeurs ont la possibilité de faire en sorte que l’installation soit automatisée au maximum. De la sorte le processus d’installation aura pu être validé de nombreuses fois avant d’arriver en production, et la seule chose qui restera est un paramétrage bien particulier de l’application.
Bien souvent les paramètres des machines de production sont sur les machines… et puis c’est tout. Et si la machine tombe en panne c’est le drame. Et pourtant il suffit d’utiliser le gestionnaire de version, le même que celui utilisé par les développeurs, pour sauvegarder les fichiers de configuration et pouvoir les restaurer en cas de besoin. Après il existe des outils de gestion de configuration qui permettent également d’adapter ces fichiers de configuration par machine, dans le cas où le parc à gérer est conséquent.
Cet article n’est qu’un rapide survol de la démarche DevOps, en espérant que ça ait pu vous mettre l’eau à la bouche. Nous approfondirons davantage chacun des points dans des articles ultérieurs.
Débloque les + belles offres tech en 10 mins
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.
Changer d’entreprise, c’est excitant. Nouveau challenge, nouveaux collègues, nouveau café. Mais, bien souvent, on oublie…
Ç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…