Stéphane Goudeau

Il ne faut pas oublier de mieux tendre l'oreille aux feedbacks et d'industrialiser leur traitement car l'accélération du time to market n'a de sens que si les services proposés sont alignés sur les besoins, car autrement, vous accéléreriez à contre-temps ...

Le testeur DevOps doit appliquer la même démarche quel que soit l'environnement sur lequel s'exécute l'application. Il doit connaître et comprendre le fonctionnement du système en charge de l'utilisation réelle.
Il doit également se concentrer sur les données associées aux comportements des utilisateurs et apprendre à rechercher des modèles dans les données. Il doit être en situation de pouvoir distinguer les zones dans lesquelles l'expérience utilisateur est potentiellement insatisfaisante (dysfonctionnement, latence, navigation complexe ...) de celles dans lesquelles le service est rendu dans d'excellentes conditions (sans doute plus difficiles à identifier).
Il passe donc d'un monde où la qualité était validée de façon binaire (le test a réussi ou échoué) à un monde probabiliste dans lequel il doit faire usage de calculs statistiques pour comprendre ce que font les utilisateurs et pourquoi ils le font, en établissant des correspondances entre les données capturées et la qualité du produit.

DevOps part du principe que la solution finira par rencontrer un dysfonctionnement. Il ne s'agit donc pas de s'affranchir de tout risque d'erreur, car cela reste impossible. Il s'agit de mettre en place des mécanismes permettant d'assurer la remise en fonction du système dans les plus brefs délais.
Pour l'administrateur système DevOps,
la première étape consiste donc à mettre en place une solution de monitoring, permettant non seulement de déclencher les alertes en cas d'indisponibilité des services, mais également d'anticiper les dysfonctionnements en détectant les franchissements de seuil ...

S'il est simple de reconnaître un produit ou un service de bonne qualité, il est plus difficile d'en donner une définition absolue. (...)
En premier lieu, le concept de qualité sous-tend un certain nombre d'idées liées à l'optimisation d'un produit ou d'un service et les moyens que l'on se donne pour faire en sorte qu'il apporte le maximum de valeur à nos clients. (...) c'est un point de vue qui reste subjectif, celui du consommateur, qui va permettre de juger ou non de cette qualité. Naturellement, il s'agit de s'assurer que le produit ou le service est fiable et que son comportement est bien celui souhaité par l'utilisateur. D'un point de vue organisationnel, la qualité c'est surtout la capacité à respecter les délais et à s'aligner sur un time to market conforme à la stratégie business de l'entreprise. Enfin, la qualité est également liée à la façon dont le produit ou le service sera produit. La qualité sera alors considérée à l'aune de critères qui permettent de mesurer l'efficacité de la chaîne de production logicielle. Enfin, ne perdons pas de vue la sécurité, une composante majeure de la qualité, qui elle aussi est à reconsidérer avec DevOps.

Optimisation et fiabilité du service, alignement sur le time to market, efficacité de la chaîne de production logicielle et sécurité, autant d'éléments qui font de la qualité un impératif de la transformation DevOps.

Les stratégies de gestion de code source

Feature Branch Workflow
Le modèle de développement Feature Branch consiste à créer une branche chaque fois qu'un développeur commence à travailler sur une nouvelle fonction. Le développement a alors lieu sur une branche dédiée plutôt que sur la branche master, ce qui facilite les évolutions sans altérer la base principale de code. Il s'agit d'une technique éprouvée et fréquemment mise en œuvre sur les projets de développement de taille significative.

Le pipeline de déploiement

L'objectif d'un processus de release management est d'éliminer les versions inaptes à partir en production et de pouvoir remonter au plus tôt les raisons de cet échec. Une approche DevOps doit permettre à chaque instant d'être en mesure d'évaluer la viabilité en production de la version du livrable en cours.
Pour ce faire, il faut être en mesure de définir et maintenir un modèle de gestion des versions d'application offrant la création de chemins d'accès de configuration et la configuration d'orchestration de déploiement.

L'ensemble de ces étapes constitue le pipeline de déploiement (terminologie issue de l'ouvrage "Continuous Delivery" de Jez Humble et David Farley). Il s'agit de l'un des éléments clés du processus de continuous delivery. (...)

Il ne suffit pas d'automatiser le workflow lui-même, mais aussi la création des environnements, leur mise en service, et la maintenance de l'infrastructure.
L'automatisation du processus de déploiement le rend plus rapide, reproductible et fiable, ce qui permet de l'activer beaucoup plus fréquemment. Cela permet également de faire des retours sur une version précédente beaucoup plus rapidement. Enfin, ce processus devrait être automatiquement déclenché par l'occurrence d'un nouveau build.

La conception

La conception d'un logiciel vu sous l'angle DevOps doit prendre en considération le contexte de mise à disposition de ce logiciel. Comme nous l'avons vu, cela implique la capacité à faire évoluer rapidement ce logiciel en fonction des attentes du marché ou du renouvellement des technologies.
Cela se traduit par de multiples conséquences pour la conception.
La première d'entre elles est l'absolue nécessité d'une conception dite évolutive. (...)

Simplicité (...)

La complexité de l'implémentation d'un système le rend moins compréhensible et par conséquent, freine son évolutivité.
La fameuse maxime d'Antoine de Saint-Exupéry "La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer" pourrait donc fort bien s'appliquer à la conception logicielle ...

Toutefois, il reste important de garder à l'esprit que l'architecture d'un composant sera amenée à changer, et de faire en sorte que ces évolutions soient les plus simples possibles (design for change).

L'implémentation

D'un point de vue DevOps, l'implémentation d'une application se caractérise par une approche itérative privilégiant l'expérimentation, le partage de la connaissance, le refactoring et la mise en œuvre de patterns éprouvés.
Enfin, elle suppose la mise en œuvre d'outils permettant d'observer les interactions avec le système.

DevOps respecte de manière tout à fait évidente les valeurs fondamentales de l'Agilité, et s'inscrit dans la filiation des méthodes Agiles traditionnelles.

Lorsque les méthodes Agiles traditionnelles sont correctement mises en œuvre, elles génèrent souvent une forme d'enthousiasme auprès des utilisateurs et des populations métiers.

Malheureusement, l'enthousiasme initial de l'utilisateur se transforme vite en frustration quand la coopération des services de développement et de gestion des opérations n'est pas Agile et que les différents services informatiques ne collaborent pas ensemble dans la direction attendue par les métiers.

L'idée de DevOps est de pousser les démarches Agiles jusqu'aux équipes de production en passant par une collaboration Agile basée sur la confiance.
DevOps hérite pleinement de la culture Agile des méthodologies projets pratiquées depuis des années.

DevOps est Agile

Pour entendre que DevOps est Agile, il faut comprendre ce qui se cache derrière le mot Agile. Aujourd'hui, il a été utilisé dans tellement de contextes différents que sa véritable signification s'est diluée (...)

La dilution et l'incompréhension de l'Agilité ont pour conséquence d'affecter son image au sein de l'entreprise et de complexifier son adoption. (...) Il est vrai que le mot Agile peut avoir plusieurs sens selon le contexte où il est utilisé. (...)

Le processus de gestion des projets et des hommes autant que le run peuvent être Agiles. C'est dans ce cadre que l'on exploite pleinement les méthodes de projet Agiles ou la démarche DevOps, en s'appuyant sur un processus Agile DE BOUT EN BOUT, autrement dit DU BESOIN CLIENT A LA LIVRAISON CLIENT.