Les principes du DevOps

Pour rappel, le mouvement DevOps est issu d’une succession de conférences, dont les DevOpsDays ↗, qui se sont déroulées à partir de 2008.

Le constat qu’ils tiraient est que le cloisonnement des équipes de développement (Dev) et des opérations (Ops) était contre-productif. De plus leurs méthodes de travail s’opposaient. L’un était agile et l’autre utilisait encore le cycle en V.

C’est en 2010 que les principes fondateurs du DevOps ont été posés par Damon Edwards et John Willis. Ils ont inventé l’acronyme CAMS, qui signifie Culture, Automation, Measures and Share (Partage). Jez Humble, dans son livre HandBook Devops ↗ publié en 2016, a amendé cet acronyme en ajoutant Lean, pour former l’acronyme CALMS. Revenons maintenant en détail ces cinq grands principes.

Culture

Si vous n’avez pas cette Culture, toutes les tentatives de l’adopter seront vaines. Je ne vous apprendrai rien en vous disant que sans appui des dirigeants tout projet est voué à l’échec. Le DevOps appelle à un renforcement de la collaboration entre deux équipes, que sont les Dev et les Ops. Cela ne peut se faire sans cet appui.

Automatisation

L’automatisation consiste à libérer les équipes des tâches répétitives et sans véritables valeurs ajoutées. Il s’agit aussi de donner aux gens les moyens de faire se concentrer sur celles qui ont réellement de la valeur.

Mesure

Si vous ne pouvez pas mesurer, vous ne pouvez pas vous améliorer. On ne se limite pas à mesurer le temps d’un déploiement logiciel. Il faut mettre en place d’autres indicateurs pour que le processus puisse être amélioré continuellement.

Sharing (Partage)

Le partage exprime la nécessité d’une communication permanente entre les équipes chargées des développements et ceux de l’exploitation. L’objectif est de créer une contribution partagée. Les gens sont prêts à travailler ensemble si leurs pensées et leurs opinions sont entendues. Ils partagent donc leurs idées, leurs analyses, leurs données et leurs résultats.

Lean

Le lean, qui signifie “sans gras”, est une méthode de gestion de la production qui se concentre sur la “chasse aux gaspillages”. Ce principe de rationalisation cherche à réduire des excès, en limitant au minimum le nombre et la durée des réunions, la taille des équipes et le nombre d’outils susceptibles de fournir les résultats attendus.

Que manque-t-il ?

Il ne faut pas se limiter à ces cinq grands principes. Il faut prendre aussi ceux du manifest Agile puisque le DevOps s’en inspire.

Le manifeste Agile

Les Principes qui sous-tendent le Manifeste Agile (source ↗) :

• Notre principale priorité est de satisfaire le client en livrant rapidement et régulièrement des solutions qui apportent de la valeur. Accueillez chaleureusement les changements de besoins, même tardifs dans le développement. Les processus agiles tirent parti du changement pour renforcer l’avantage concurrentiel du client.
• Livrez souvent des solutions opérationnelles, à une fréquence allant de quelques semaines à quelques mois, avec une préférence pour les échelles de temps les plus courtes.
• Les personnes en charge du métier ou des affaires et les personnes en charge de la réalisation doivent travailler ensemble chaque jour, tout au long du projet.
• Construisez les projets à partir de personnes motivées. Donnez-leur l’environnement et le soutien dont elles ont besoin et faites-leur confiance pour mener à bien le travail.
• La conversation en face à face est la méthode la plus efficace et la plus économique pour donner des informations à une équipe de réalisation et pour échanger des informations à l’intérieur de l’équipe.
• La disponibilité de solutions opérationnelles est la principale mesure d’avancement.
• Les processus agiles encouragent à respecter un rythme soutenable lors de la réalisation. Les commanditaires, les réalisateurs et les utilisateurs devraient pouvoir maintenir indéfiniment un rythme constant.
• Porter continuellement attention à l’excellence technique et à la qualité de la conception renforce l’agilité.
• La simplicité – l’art de maximiser la quantité de travail qu’on ne fait pas – est essentielle.
• Les meilleures architectures, les meilleures spécifications de besoins et les meilleures conceptions émergent d’équipes auto-organisées.
• À intervalles réguliers, l’équipe réfléchit aux façons de devenir plus efficace, puis modifie son comportement et l’ajuste en conséquence.

Attention

Sous couvert de la simplicité certains y justifient le moyen de ne pas respecter les bonnes pratiques de sécurité, de maintenabilité et de disponibilité. Ne tombez pas dans ce piège !