Je pratique et conseille DevOps en tant que consultant auprès de différents clients depuis près de cinq ans maintenant, avant mon poste actuel, j'ai occupé des postes dans le développement de logiciels, les opérations Web et l'administration de systèmes. D'après mon expérience personnelle , DevOps se décline en plusieurs versions.
Modèles d'organisation
DevOps Antipatterns:
NoOps et NoDevs - pas strictement DevOps au sens le plus strict, cependant, ces équipes construisent et exploitent des logiciels sans séparation entre le développement et les opérations. Les défis avec ces équipes sont à maturité, les équipes de développement peuvent être des développeurs de logiciels experts mais des opérateurs novices et vice versa.
Le pont DevOps - c'est là un ou plusieurs équipes chargée de reprendre le travail des équipes de développement et « Productionizing » pour le rendre utilisable. Le défi se résume à présent à deux transferts, à savoir Développement → DevOps et DevOps → Opérations.
L'équipe DevOps - cela peut sans doute fonctionner si l'équipe a la responsabilité de créer des outils qui prennent en charge le modèle d'exploitation compatible DevOps, cependant, cela devrait probablement être appelé une "équipe d'outils" ou une "équipe de plate-forme".
Modèles DevOps:
DevOps intégrés - plus communément appelé Platform Engineering, selon lequel un membre de l'équipe est responsable mais non responsable de la fourniture de l'automatisation, des outils et de l'infrastructure pour l'approvisionnement et le déploiement de la solution, y compris parfois l'exploitation du logiciel - dans mon esprit , c'est ce dernier qui est en fait représentatif de DevOps.
DevOps institutionnalisés - où une équipe de projet est conjointement responsable à la fois du développement et de l'exploitation d'un progiciel de création de propriété partagée et de boucles de rétroaction positive.
Les pratiques
La pratique actuelle de DevOps s'appuie sur plusieurs autres pratiques, à savoir:
Chacune des pratiques ci-dessus s'appuie sur l'autre, il est possible de ne pas suivre une pratique, cependant, cela signifie qu'un cycle de rétroaction important est manquant, ce qui peut indiquer une "opportunité manquée". Le principal facteur de différenciation entre le suivi de l'une des autres pratiques et DevOps est le fonctionnement du logiciel en production .
Les trois voies
Dans The Phoenix Project, Gene Kim et ses co-auteurs décrivent les trois méthodes de DevOps :
Pensée systémique
La première façon met l'accent sur la performance de l'ensemble du système, par opposition à la performance d'un silo spécifique de travail ou de service - cela peut être aussi important qu'une division (par exemple, développement ou opérations informatiques) ou aussi petit qu'un contributeur individuel (par exemple , développeur, administrateur système).
D'après mon expérience, commencer à amener les développeurs à prendre en compte les préoccupations opérationnelles et les exigences non fonctionnelles atteint cet objectif. Cela fait partie intégrante des aspects culturels de DevOps.
Amplification des boucles de rétroaction
La deuxième façon consiste à créer des boucles de rétroaction de droite à gauche. Le but de presque toutes les initiatives d'amélioration des processus est de raccourcir et d'amplifier les boucles de rétroaction afin que les corrections nécessaires puissent être apportées en permanence.
J'y parviens généralement grâce à l'intégration / la livraison / le déploiement continus et à la surveillance et aux alertes partagées, ce qui correspond parfaitement au composant outils de DevOps.
Culture d'expérimentation continue et d'apprentissage
La troisième voie consiste à créer une culture qui favorise deux choses: l'expérimentation continue, la prise de risques et l'apprentissage de l'échec; et comprendre que la répétition et la pratique sont la condition préalable à la maîtrise.
Cela s'intègre très bien dans l' espace culturel , même si cela dépend fortement des outils et des processus permettant à la culture de se développer.
