Ami des choses simples, bon matin !

Un jour naquit le DevOps, puis le lendemain le DevSecOps, puis demain arrivera le DevSecTrucOps... plein de jolis buzz words !

On dirait parfois une escalade ! à savoir qui rajoutera le mot le plus branché. C'est ridicule et cela va a l'encontre des principes même de l'agilité. Mais reprenons le problème à la source.

Le DevOps pour répondre à quel enjeu ?

Dans un temps pas si lointain, les équipes travaillaient en silo. Les équipes de dev developpaient, alors que les équipes d'opération opéraient avec de la communication uniquement au moment du transfert du produit.

Bien entendu ce mode de fonctionnement entraînait de très nombreux problèmes. Les plus importants étant :

• Manque de responsabilisation des équipes dev qui, une fois la livraison effectuée, n'étaient plus responsable ;
  • Moins d'effort dans la qualité du code
  • Peu ou pas de feedback sur ce qu'elles avaient livré, donc moins de possibilité de s'améliorer
• Étape pénible d'opérationalisation pour assurer le transfert d'une équipe à l'autre
• Le délai entre les diverses versions du produit (parfois plusieurs années lorsque le produit est très complexe)

Puis un jour, tel le Messi (Lionel) vint le devops, résolvant magiquement tous les problèmes du monde !

 

Il est né le divin DevOps, chantons tous son avènement !

Ouais je sais, j'en fait peut-être légèrement trop ! mais que celui qui n'a jamais beurré épais me jette la première pierre !

D'abord, qu'est-ce que ce n'est pas !

Il traîne beaucoup de fables et de bêtises sur ce qu'est le DevOps, donc commençons par régler l'histoire de ce que cela n'est pas.

"Le DevOps c'est lorsque les gars d'Ops peuvent faire du Dev et les gars de Dev de l'Ops" : Là, vous n'avez absolument rien compris ! Vous pouvez très bien faire du dev au ops et de l'ops au dev, vous ne serez pas plus DevOps !

"J'ai mis dans une même équipe les gars de dev et d'ops, nous sommes donc rendu DevOps" : Hmmm par où commencer... disons que j'ai déjà mis du fromage et des oeufs dans un saladier et ça ne va pas faire tout seul un souflet au fromage.

"Mes gars vont apprendre à faire de l'ops et mes gars d'ops vont devenir dev" : Ben là... si c'est ton objectif, tu te plantes solide, certains dev ne seront jamais bons pour de l'ops et le contraire aussi.

Ok alors, maintenant c'est quoi dans la réalité? Tu vas finir par le dire ?

Le DevOps est une méthode qui permet de faire travailler ensemble les équipes de dev et d'ops. Les faire travailler ensemble veut dire ici que chacun des deux groupes va pouvoir bénéficier des connaissances de l'autre groupe. Certains dev vont apprendre à faire un peu d'ops, d'autres pas. Certains ops vont aussi apprendre à faire du dev, d'autres pas.

L'idée de faire travailler ensemble les deux groupes est que chacun puisse prendre conscience de la réalité de l'autre groupe pour améliorer sa façon de travailler. 

MAIS, hormis les histoires de dev et d'ops, le plus important dans le DevOps c'est le changement dans les processus qui permet une accélération de cycle de livraison des nouvelles versions et la prise de conscience qu'un produit n'est jamais fini, il y a toujours de petites améliorations.

De plus, dans le processus, deux nouvelles étapes qui n'existaient pas précédemment deviennent maintenant des requis :

• Les tests (verify)
• Le monitor (aussi appelé Observability)

Oh ! attends, tu me dis qu'un produit n'est jamais fini ! Ca va coûter cher à mon boss

Pas plus qu'avant ! Avant, lorsqu'une version était publiée, ton boss payait pour que des gars l'opèrent en même temps qu'il payait des gars pour préparer la prochaine version. Maintenant, ton boss paye pour que l'équipe DevOps l'opère et travaille sur des améliorations continues. Leur but étant que le produit doit être mieux demain qu'il ne l'est aujourd'hui, même si on parle d'une amélioration infime, ça reste une amélioration.

Là, j'ai compris ! mais alors le DevSecOps, c'est la même chose avec de la sécurité ?

Le DevSecOps... C'est du marketing et de la connerie (excusez-moi l'expression), car la securité devrait toujours faire partie du DevOps. Jamais un produit ne devrait sortir sans que la sécurité la plus forte possible ne soit appliquée !

La securité devrait toujours être présente à toutes les étapes du Dev et de l'Ops.

 

Alors, c'est quoi les étapes

Le cycle d'origine incluait 7 étapes :

• Plan
• Build
• Test
• Package
• Deploy (release)
• Operate (configure)
• Monitor

Plan

Le plan, c'est simplement de faire le plan pour les prochaines étapes, dans le cycle complet on va utiliser les fruits du monitor pour générer un plan et prioriser.

Build

Le build c'est coder ! Facile à comprendre celle-là !

Test

Si au commencement du DevOps l'étape test avait une grande valeur ajoutée, depuis l'apparition de techniques tel que le TDD (Test Driven Developpement), cette étape ne devrait plus être distincte de l'étape du build. La seule chose que l'on pourrait peut-être considérer, c'est le gating final qui repose sur des tests (dans un pipeline on va forcer le succès des tests avant d'autoriser le code à passer au "next step").

Package

Le package est très dépendant des langages utilisés. Ainsi, dans le cas de Java on va parler de compilation, mais dans le cas de code Terraform par exemple, le package est simplement le fait de pousser son code sur un repo Git. Bref, cette étape aussi ne devrait, selon moi, pas être séparée de l'étape du build/test.

Deploy

Une fois le package fait, il faut rendre le code disponible pour le client. C'est donc la publication du produit.

Operate

On désigne ici les opérations courantes de maintenance et de configuration du produit.

Monitor

Le monitor est le mal nommé et le mal compris !

La majorité des néophytes vont comprendre ici l'alertage (faire sonner les pagettes quand un système tombe en panne), alors que l'étape monitor designe quelque chose qui est complètement différent et qui peut se décomposer en deux parties :

• La prise de feedback auprès du client et utilisateur
  • Où le client perd du temps ?
  • Quelle fonctionnalité le client aurait besoin ?
  • Quel ajout pourrait simplifier la vie des opérateurs ?
• L'utilisation d'outils qui permet d'analyser les performances de notre produit
  • Sur un site Web :
    • avec Google analytics, analyser les performances de chaque page et le parcours des visteurs pour s'assurer qu'ils se rendent bien au bon endroit pour voir le bon message
    • le prix moyen du panier pour un site d'e-commerce
    • le taux de rebond...
  • Dans le cadre d'un produit Infrastructure As Code
    • La durée des workflows
    • Le taux d'échec de chaque workflow
    • ...

Bref, le monitor est l'une des étapes les plus importantes, c'est elle qui permet de passer au Plan avec des bonnes données !

En version simple, ça donne quoi ?

Pour faire simple, et en tenant compte des façons modernes de développer et livrer un produit, le DevOps moderne pourrait ainsi se résumer en 5 grandes étapes :

Donc ami du DevOps, mais surtout ami des choses simples et claires, je vous souhaite bien le bonsoir !