Pourquoi le DevOps et contexte d’apparition

1. Les apports du Lean

L’objectif ici est de comprendre la filiation du DevOps. Vous trouverez probablement beaucoup de références au Lean expliquant que ses principes sont issus du système de production de Toyota (TPS) et qu’ils ont été popularisés dans les années 1990 aux États-Unis, au MIT précisément. Il est communément admis que cette méthode permet à Toyota de réduire ou tout simplement d’éliminer toutes les tâches qui ne sont pas source de valeur pour le produit final. Cela permet d’obtenir des gains de productivité et donc de rentabilité qui assurent une grande résilience à l’entreprise Toyota.

Il convient en réalité de nuancer cette approche qui, par ailleurs, ne traduit pas très bien en quoi elle pourrait être liée ou utile à l’idée de l’agilité...

1. La spécialisation

Comme nous venons de le voir, l’introduction du Scrum dans les pratiques de développement a introduit un écart important dans les attendus entre les différents services. Pour mieux le comprendre, il faut remonter aux années 1970, moment de la généralisation du développement par phases au travers du modèle en cascade.

Pour faire simple, un projet suit classiquement un processus séquentiel à travers différentes phases :

À partir du moment où ces phases sont pleinement identifiées, et surtout où chacune correspond à un rôle et à une responsabilité unique dans l’ensemble du process, il devient facile de spécialiser des ressources humaines pour chacune de ces phases. L’idée derrière la spécialisation est évidemment d’industrialiser le processus pour le rendre plus efficace, tant en termes de productivité que de qualité.

Des ressources spécialisées et expertes sur un domaine ont l’avantage de la maîtrise technique, de l’amélioration de la compétence et de la pérennisation de la connaissance. Le thème de la spécialisation sera abordé plus longuement avec l’organisation DevOps.

Pour reprendre notre modèle par phase nous pouvons identifier des expertises bien connues :

1. La rencontre

À partir du milieu des années 2000, un certain nombre d’outils apparaissent afin de faciliter la gestion des déploiements des serveurs, physiques ou virtuels. C’est le cas notamment de Puppet qui propose dès 2005 une solution d’automatisation des déploiements pour le packaging et le provisioning automatique des ressources système ainsi que pour la configuration des applications (c’est un logiciel de gestion de configuration et d’automatisation des déploiements).

Cette avancée technologique va rapidement venir rencontrer les agilistes qui se confrontent depuis les débuts du Scrum au problème de la fréquence des déploiements et la désynchronisation entre les équipes de développement et les opérations.

Le problème est latent, mais il n’est pas encore vraiment défini, ni même nommé, quand deux ingénieurs, Patrick Debois et Andrew Shafer, l’un ingénieur système et l’autre développeur, viennent à se rencontrer lors de la conférence agile de Toronto de 2008 et posent l’idée que les équipes de développement et des opérations devraient travailler ensemble, et non dans des services séparés, en s’appuyant sur les outils d’automatisation d’infrastructure. Ceux-ci doivent permettre d’apporter la glue et la réactivité nécessaire à cette collaboration.

Ils lèvent alors un tabou du monde informatique : la mauvaise relation entre les développeurs et les opérations. Ils se donnent pour ambition de redéfinir cette relation et ce qu’elle devrait être. Ils nomment un nouveau cadre de pratiques ayant pour objectif clair et affirmé...

1. Le Continuous Integration (intégration continue)

Les développeurs sont les premiers à introduire des pratiques d’automatisation de conception. Les principes de l’agilité et l’adoption du Scrum amènent à automatiser de nombreuses pratiques inhérentes à la construction d’un logiciel. Cette automatisation n’est d’ailleurs pas uniquement liée à l’agilité, mais aussi à la recherche d’une plus grande productivité et une meilleure gestion de la qualité dans les projets. Automatiser les tests, c’est par exemple une façon efficace de limiter les effets de bords au fur et à mesure de l’introduction de nouvelles fonctionnalités. Les sociétés de services qui signent des engagements de réalisation au forfait vont rapidement chercher à inclure des budgets pour automatiser les tests et ainsi éviter d’avoir à payer des pénalités pour des anomalies trop nombreuses.

Des frameworks sont construits pour automatiser les principales activités, moyennant une charge supplémentaire d’intégration dans le code des applications. Apparaissent notamment des frameworks de tests, de gestion de base de données, de développement web, etc.

Une fois les principales activités outillées, d’autres outils ont ensuite la charge d’assurer la colle en exécutant le lancement automatique de chaque tâche de construction et de test, et de monitorer les différentes activités, tel un flux. Ce sera le rôle, par exemple, d’Ant, Maven et Jenkins, dans le monde JAVA.

Des outils de gestion du cycle de vie des applications permettent d’assurer la traçabilité des actions et des changements tout...