Lamarck Institute DevOps Foundation French V1.0 Compressed 1

DevOps Foundation@@
Body of Knowledge for the EXIN Scrum Foundation Certificate

DevOps Foundation
Sommaire
• Introduction
• DevOps les bases
• DevOps les principles
• DevOps les pratiques clef
• DevOps application pratique
DevOps Foundation
Objectifs et public
• EXIN DevOps Foundation est idéale pour les professionnels de l’informatique et

des métiers qui veulent comprendre DevOps et comment leur organisation
peut bénéficier de ses principes.
• Cela inclueceux qui participent à une équipe DevOps et toute personne

engagée dans la gestion de l’information et de la technologie.
DevOps Foundation
Littérature
DevOps A Businness Perspective Effective DevOps

A. Oleg Skrynnik Jennifer Davis, Ryn Daniels
DevOps – a Business Perspective Effective Devops: Building a Culture of
Van Haren Publishing, 2018 (first Collaboration, Affinity, and Tooling at
edition) Scale (Anglais) 2016
ISBN: 9789401803 ISBN : 9352133765
DevOps Foundation 4
1. DevOps, les bases
1.1 Origines de DevOps

1.2 Définition de DevOps
1.3 Motifs d'utilisation de DevOps
1.4 Idées fausses sur DevOps
DevOps Foundation 5
1980… 2008
ITSM
ITIL
COBIT DEVOPS
AGILE
SCRUM
DevOps Foundation
Une transition importante de la gestion informatique fut le passage dans les

années 2000 de la gestion systèmes informatiques à la gestion des services
informatiques.
Adoptées avec succès par les dirigeants, les pratiques de gestion

émergentes sont devenues des pratiques exemplaires et ont évolué vers des
bonnes pratiques généralement acceptées.
DevOps est apparu en raison de deux facteurs :

- large adopWon de méthodes de développement de logiciels agiles
- gesWon de l’infrastructure informaWque comme un programme
DevOps Foundation 7
1.1.1 De la cascade vers l’agilité
• Au cours du 20ème siècle, le modèle en cascade (Waterfall) a été la

méthodologie prédominante de développement de logiciels.
• Dans les années 1990, Internet a accéléré la nécessité de lancements rapides

d’années en mois.
DevOps Foundation
En 2001, le Manifeste Agile a été produit pour combler le fossé entre les
développeurs d’entreprises et de logiciels.
Continuous Delivery
• Harness Change
• Working software in weeks
• Business and IT working together
• Trusted and motivated individuals
• Sustainable development
• Agility
• Simplicity
• Self-organizing teams
• Continuous improvement
DevOps Foundation
Le développement agile utilise une approche

itérative pour réduire les risques et créer des
produits partiel fonctionnel tout au long du
développement
DevOps Foundation 10
Manifeste pour le développement Agile de logiciels

Ces expériences nous ont amenés à valoriser :
Personnes et interac.ons > Processus et outils
Logiciel qui fonctionne > Documentation
Collabora.on avec le client > Négociation à partir d'un contrat
S'adapter au changement > Suivre un plan
Nous reconnaissons la valeur des seconds éléments,

mais privilégions les premiers.
Nous découvrons comment mieux développer des logiciels par la pratique

et en aidant les autres à le faire.
es
ssourc
nes
humai
aux re
au pilo t
du pro
tage
je
la prod ité de
uction
al
à la qu
1.1.2 Gérer l’infrasctructure comme du code
L’émergence de la gestion de l’infrastructure informatique en tant que

code a été précédée par le développement de deux technologies : la
virtualisation et le cloud computing.
Les professionnels de l’informatique pourraient créer les parties de

l’infrastructure informatique dont ils avaient besoin (serveurs, systèmes de
stockage, composants réseau...) au moyen des commandes textuelles... Le
degré d’automatisation a considérablement augmenté, tout comme la
rapidité de la mise en œuvre du changement.
Aujourd’hui, on peut créer une infrastructure informatique en :
- exécutant un script et en attendant l’achèvement de son exécution

- payant la facture du fournisseur de cloud à la fin du mois.
DevOps Founda/on 13
1.1.2 Gérer l’infrasctructure comme du code
Gérer l’infrastructure comme du code :
1 Virtualization
• Utilisation efficace du matériel
• Niveau supplémentaire d’abstraction entre les applications métier et les logiciels
système
2 Cloud Computing
• VPN permet envoyer des paquets de données privées sur des canaux partagés
avec sécurité, confidentialité et qualité de service
• Les grands fournisseurs ont rendu les ressources virtuelles abordables et fiables
DevOps Founda/on
1.1.3 DevOps d’un point de vue historique
Un context qui a permis l’émergence de DevOps :
• de nouvelles façons d’interagir avec les métiers par l’application

adéquate de techniques de développement agiles
• de nouvelles technologies de gestion des infrastructures, il est devenu

possible d’organiser le travail informatique différemment
Tout cela a amené à penser de Nouvelles façons de gérer l’IT.
DevOps Founda/on
DevOps Founda/on
une évolution des appliquées à

idées de la chaîne de
a.
développement de valeur de
logiciels agiles et de bout en bout
lean manufacturing en IT
permet aux
entreprises d’en
en raison de faire plus grâce
changements aux technologies
culturels, de l’informaWon
organisationnels modernes
et techniques
DevOps Founda/on 17
1.2.1 DevOps comme un extension des pensées of Lean et Agile
• DevOps est une évolution des idées de développement de logiciels

agiles et de lean manufacturing, appliquée à la chaîne de valeur de
bout en bout dans l’informatique, ce qui permet aux entreprises de se
déévelopper grâce aux technologies de l’information modernes en
raison de changements culturels, organisationnels et techniques
• DevOps ne remplace pas les pratiques agile et lean mais les absorbe.
• L’essence même de DevOps est de penser non seulement au

développement de logiciels, mais plutôt à toute la chaîne de valeur.
• 3 éléments essentiels :
Culturel
Organisation
Technique
DevOps Founda/on
1.2.2 DevOps nécessite une réflexion sur la chaine de valeur
• Comprendre que la valeur est un indicateur clé a un gors impact sur les
processus.
• Une représentation visuelle du processus aide à se concentrer sur la valeur

créée, plutôt que sur les actions exécutées.
• Cela aide à identifier et à éliminer les goulots d’étranglement, tout en évitant

le piège d’optimisation local.
• Cela aide à réaliser un flux lisse et uniforme d’étape en étape qui permet
d’offrir des sorties en permanence, réguliers, sans retards inutiles et avec une
utilisation optimale des ressources.
DevOps Founda/on
1.2.3 DevOps, un meilleur rendement de l’IT
• Accélérer la livraison de produits nouveaux et modifiés sur le marché
• Réponse plus rapide aux besoins des clients
• Amélioration de la disponibilité et de la durabilité des systèmes informatiques
• Utilisation plus efficace des ressources limitées
DevOps Founda/on
1.3 Pourquoi utiliser DevOps ?
DevOps Founda/on
1.3.1 Diminution du temps de commercialization (Time to Market)
Traditional Companies - Years

Y1 Y2 Y3
Dynamic Companies - Years
W1 W2 W3 W4 W5 … W47 W48 W49 W50 W51 W52 W1 W2 W3 W4 W5 … W47 W48 W49 W50 W51 W52 W1 W2 W3 W4 W5 … W47 W48 W49 W50 W51 W52
DevOps - Day
DevOps Founda/on
Société traditionnelle (années) - Optimisé pour le coût
• Structuration et redaction d’un idée de business et justification

• évaluation et sélection d’une idée business pour la mise en œuvre
• la planification des mesures requises pour la mise en œuvre; obtenir des
fonds
• préparation du personnel et des processus d’affaires
• en même temps : formalisation des exigences, développement de
prototypes, essais initiaux, développement, tests, rejet et déploiement
approfondis
• en même temps : activités marketing, préparation du marché, préparation
des canaux de vente et outils
• lancement d’un nouveau produit ou service
DevOps Founda/on
Entreprises dynamiques (Semaines) - Op;misé pour la vitesse

• la création d’une hypothèse, développement des
méthodes de validation
• mise en œuvre pratique de l’hypothèse
• évaluation des résultats, test, comparaison avec les
cibles
• ajustement basé sur l’analyse, revenir à la première ou à
la deuxième étape.
DevOps Founda/on
DevOps tÉchniques (jour)

• réduction la taille du lot
• rédution du nombre de transferts (handoff)
• identification continue et élimination des pertes
• équipes autosuffisantes
• automatisation
DevOps Founda/on
Pour réduire le temps de commercialisation, DevOps propose une variété

de techniques, pour :
réduire la taille du lot
réduire le nombre de transferts
identification continue et élimination des pertes
...
Mais:
Il est naïf d’espérer que l’utilisation des techniques DevOps pour accélérer le
travail du département IT conduira simultanément à une réduction des coûts IT
.
Le coût IT augmentera, principalement, en raison de l’augmentation du nombre
de membres du personnel
.
L’organisation traditionnelle de l’IT suppose des unités fonctionnelles distinctes
DevOps Founda/on 26
1.3.2 Réduire la dette technique
• La dette se produit lorsqu’un membre de l’équipe choisit un moyen non

optimal de résoudre un problème afin de raccourcir le temps de
développement.
• Le problème est que les solutions non optimales accumulées conduisent à une
détérioration progressive de la qualité des services et des produits
• La refactorisation constante de DevOps du code de programme permet de

tenir compte de l’expérience acquise, et le travail sur l’élimination des goulots
d’étranglement déjà créés est planifié sur un pied d’égalité avec la création
de nouvelles fonctionnalités.
• DevOps recommande fortement d’utiliser la pratique de « faire face aux

problèmes aussi fréquent que possible » afin d’éviter la « stagnation » des
problèmes
DevOps Founda/on
1.3.3 Éliminer la fragilité – tolerance zéro
• Les systèmes les plus importants sont souvent les plus fragiles.
Réduire la fragilité de ces systèmes comporte des risques
élevés de perturbation des activités.
• Dans DevOps, le code et le système dans son ensemble sont

pleinement fonctionnels à tout moment. Si le prochain
changement perturbe leurs performances, il recule
immédiatement et le système continue de fonctionner.
• DevOps introduit délibérément du chaos et de l’instabilité

dans l’environnement de production pour voir di les sytèmes
cibles répondrent de manière indépendante et rapide pour
restaurer leur fonctionnement normal.
DevOps Founda/on
1.4 Idées fausses sur DevOps
DevOps Founda/on
1.4.1 DevOps ne fait pas partie d’Agile
• Mythe ou fait : « DevOps n’est rien de plus que la poursuite des idées Agiles
• Basé en grande partie sur Agile, DevOps étend néanmoins les idées du
développement Agile à la production informatique Agile en général,
l’ensemble de l’organisation, l’ensemble du processus, l’ensemble de la
chaîne de valeur.
• Mettre en palce DevOps nécessite des changements culturels plus importants

dans l’entreprise qu’il ne le faut habituellement pour Agile.
• Les objectifs fixés pour DevOps ne se limitent pas à accélérer la livraison : il est
également nécessaire de réduire la dette technique et d’éliminer la fragilité
DevOps Founda/on
1.4.1 DevOps ne fait pas partie d’Agile
L’application d’une approche agile du développement de logiciels

rencontre des difficultés dans de nombreux cas :
Les méthodes Agile ne couvrent qu’une partie de la chaîne de valeur,

ce qui conduit à un effet global modeste.
Les méthodes agiles ne tiennent pas compte des spécificités et de la

complexité du fonctionnement de l’IT, où l’approche itérative est moins
applicable.
Certaines entreprises signalent l’épuisement professionnel de leurs

employés après quelques dizaines d’itérations.
DevOps Founda/on
1.4.2 DevOps ce n’est pas que des outils et de l’automatisation
• Mythe ou fait : « Les outils vous fourniront les DevOps »
• Bien que les solutions logicielles individuelles soient largement adoptées, il

n’existe pas et ne peut pas être une liste universelle de logiciels obligatoires
DevOps.
• DevOps dépend de la disponibilité et de l’efficacité de certains outils

d’automatisation. Mais à proprement parler, l’ensemble minimum de ces outils
peut être réduit à:
Système de contrôle de version pour stocker tous les codes sources
Données de configuration de l’infrastructure informatique
Système d’automatisation des pipelines de livraison de logiciels
• Toute implémentation particulière de DevOps peut être indépendante sur le

logiciel.
DevOps Founda/on
1.4.2 DevOps ce n’est pas que des outils et de l’automatisation
DevOps Founda/on 33
1.4.3 DevOps n’est pas une nouvelle profession
Mythe ou fait : « DevOps est un soldat universel, capable de coder,

de créer des tests, de déployer des environnements et de gérer
l’infrastructure »
DevOps est un changement profond dans les fondamentaux du

département informatique, pas juste l’embauche d’ingénieurs ou
de gourous de DevOps.
La capacité de mettre en œuvre un pipeline de livraison de logiciels

ne garantit pas le succès. Il est peu probable d’économiser des
coûts simplement en appliquant les pratiques DevOps.
DevOps Founda/on
Foundation – Lean Production
• Dans le Lean, concept de déchets est central

• Les déchets sont divisés en Muri, Mura and Muda.
– Muri peut être défini comme un travail d’une valeur douteuse,
que la direction assigne aux employés en raison de processus
non optimaux; l’utilisation avec surcharge constante ou
d’intensité extra-élevée.
– Mura signifie inégalité ou incohérence; il s’agit de niveaux de
demande inégaux; diffusion, fluctuations.
– Muda se réfère aux déchets qui se produisent pendant les
travaux; leurs origines et leurs propriétés sont si peu évidentes
qu’elles nécessitent une classification supplémentaire.
DevOps Founda/on
Foundation – Lean Production
Le Lean peut être décrite par la séquence suivante d’étapes :

1. Utiliser des outils spécialisés pour identifier les déchets
2. Appliquer d’autres outils spécialisés pour éliminer ou réduire les déchets;
3. Répéter l’étape 1
4. BÉNÉFICE!!!
DevOps emprunte de nombreux concepts de Lean comme :

- the value stream and value stream mapping
- quick problem removal (Andon)
- steady and even flow
- one task per unit of time
- identifying and eliminating bottlenecks and constraints
- continual improvement
- pull system
- work visualization and others.
DevOps Founda/on
2. Principes DevOps
2.1 Chaine de valeur

2.2 Pipeline de déploiement
2.3 Contrôle de version
2.4 Gestion de configuration
2.5 Définition de fait
DevOps Founda/on
2.1 Chaine de valeur
DevOps Founda/on
2.1.1 Concept de chaine de valeur
Il est utile d’examiner le travail d’une organisation en termes de création de

valeur en réponse à la demande d’un consommateur.
Les actions effectuées pour répondre à la requête sont alignées dans une
séquence appelée chaine de valeur.
Une organisation traditionnelle travaille sur plusieurs produits ou services. Ainsi, il

existe de nombreuses chaines de valeur dans l’entreprise.
DevOps Founda/on
2.1.1 Concept de chaine de valeur
DevOps Founda/on
2.1.2 Concept de cartographie de chaîne de valeur
Les travaux sur la visualisation du flux sont connus sous le nom de

cartographie de chaîne de valeur
La cartographie se fait en 2 étapes

- d’abord, l’image “as-is” est créée (Etat présent)
- puis l’image “to-be” est créée (Etat désiré)
Les informations les plus précieuses sont les 3 mesures pour chaque
étape du flux, à savoir :
Lead Time (LT) : délai de mise en œuvre
Process Time (PT)
Percent Complete and Accurate (%C/A )
DevOps Foundation
2.1.2 Concept de cartographie de chaîne de valeur
DevOps Founda/on
2.1.3 Cartographie de chaîne de valeur process businesss
Commence par la sélection d’un produit
Parfois, celui qui a les plus grandes possibilités d’optimisation ou celui

qui promet les améliorations significatives les plus rapides.
L’étude de la carte à être est importante pour 2 raisons :

- Tout d’abord, il permet d’éviter l’optimisation locale
- Deuxièmement, la compréhension de l’état cible permet de
lancer un mécanisme d’amélioration réaliste, avec une orientation
claire d’amélioration
DevOps Founda/on
2.1.3 Cartographie de chaîne de valeur process businesss
Identification des étapes clés du traitement de la demande

Documentation du travail effectué à chacun d’eux
Organisation des étapes dans une séquence de création du
résultat souhaité.
Accord sur les étapes exactes, comment et par qui elles sont
effectuées.
Il est important de se rappeler que pour cartographier le flux

«as-is», il est nécessaire d’étudier la pratique réelle, plutôt que
sa version “fantasmée”.
DevOps Founda/on
2.1.4 La pensée de chaine de valeur est le noyau de DevOps
• Key Metrics (LT, PT, %C/A)

Understand • Scale of the disaster
• Visual representation
Focus • Created Value rather than actions (Why vs What)
• Bottlenecks
Identify • Avoid local optimization trap (Theory of constrains)
• Key ideas of DevOps

• Smooth and uniform flow from step to step with continuous
Realize delivery, rhythmically, without unnecessary delays and with
optimal resource utilization
DevOps Founda/on
Continuous Deployment
Continous Delivry
Continous Integration
Code / Test Unitaire / Test d’assemblage / Test d’Intégration / Recette
DevOps Founda/on
2.2.1 Concept de pipeline de déploiement
Économise des ressources en ne commençant pas

les prochaines étapes avant que les précédentes
ne soient terminées.
Les changements de produit qui ne fonctionnent

pas n’atteignent pas la production et le système
est toujours en état de fonctionnement.
Accélère la livraison des changements à

l’environnement de production en maximisant
l’automatisation de chaque étape.
Laisse constamment des enregistrements.
Permet de surveiller toutes les modifications

apportées et donne mesures précises pour
l’optimisation.
DevOps Foundation
2.2.2 Défis lors de la mise en œuvre d’un pipeline de déploiement
Un enthousiasme excessif pour l’automatisation au détriment de

l’idéologie (processus, personnes et culture) conduit à la création
de pipelines remarquablement automatisés que personne n’utilize
Au départ, il n’y a pas assez de tests pour assurer un fonctionnement

régulier du pipeline.
Dans l’état cible, il y a tellement de tests que le passage d’un

changement par le pipeline prend trop de temps et nécessite des
ressources informatiques importantes.
DevOps Foundation
2.3 Contrôle de version
DevOps Foundation
2.3.1 Concept de controle de version
Il s’agit de stocker non seulement le code source, mais

absolument tout ce qui touche au système informatique:`
Tests
scripts pour créer et modifier des bases de données,
scripts de création d’environnement
scripts de déploiement,
Artefacts
bibliothèques, documentation, fichiers de configuration,
même des outils de développement, tels que compilateurs, etc.
DevOps Foundation
2.3.1 Concept de controle de version
DevOps Foundation
2.3.2 Pourquoi le contrôle de la version est important
Ce principe permet un niveau de contrôle sur toutes les parties

constitutives du système en fonctionnement.
L’application de ce principe nécessite un changement dans la culture

de travailler avec l’information et les configurations.
Conséquences:
Capacité de déterminer ce qui a été changé, quand et par qui.
Capacité de restaurer le système comme à n’importe quel moment
dans le passé avec un minimum d’efforts.
Tous les membre de l’équipe peuvent supprimer librement les éléments
inutiles sans risque de perte accidentelle d’informations ou de produits
importants
DevOps Foundation
2.4 Gestion de configuration
DevOps Foundation
2.4.1 Gestion de configuration
DevOps restructure complètement la gestion de l’environnement de

production.
Toute modification apportée à n’importe quel environnement ne peut

être apportée que par des scripts stockés dans le système de contrôle
de version.
La création d’environnements se fait automatiquement lorsque le

pipeline de déploiement est en marche.
DevOps Founda/on
2.4.2 La gestion de configuration est importante pour DevOps
Les changements sont contrôlés, le système peut être rapidement

restauré à l’état stable, si les membres clés quittent, les connaissances
ne sont pas perdues, et ainsi de suite.
Les principaux bénéficiaires sont les personnes travaillant dans les

opérations.
DevOps Foundation
2.5.1 Definition of Done et l’état d’esprit de DevOps
Ce n’est pas quand quelqu’un a fait sa part du travail que c’est fait,
mais quand le client a reçu ou a commencé à recevoir la valeur qu’il
attendait.
Cela signifie que l’ensemble du flux de valeur a été suivi complètement

jusqu’à l’environnement de production, ce n’est qu’à ce moment-là
que le travail sera considéré comme fait.
DevOps Foundation
3. DevOps Pratiques clés
3.1 Différence avec la pratique traditionnelle

3.2 Pratiques DevOps
DevOps Foundation
3.1.1 Des releases plus fréquentes
Pratiques traditionnelles Pratiques DevOps
• Grande taille
• Petite taille
• Plusieurs
• Communiqués
jours/semaines
hebdomadaires/quoti
• Beaucoup de
diens
ressources
• Utilisation efficace
• Effort élevé
des ressources
• Sauvegardes
• Effort régulier
• Documentation
• Automatisation
• Manuelle
• Continue
• Prévue
DevOps Foundation
3.1.2 DevOps se concentre sur l’ajout de valeur à l’entreprise
Classic IT Management DevOps
• Release • Deployment
• A release is a group of changes • Making a new functionality fully or
jointly deployed to the production partially available to users
environment • Deployed as soon as passed tests
• Release Schedule • Business Decision
• IT Decision
DevOps Foundation
3.1.3 DevOps nécessite une automatisation plus que les pratiques
traditionnelles
Les environnements requis pour le pipeline de déploiement sont créés

automatiquement par des scripts.
Ces environnements sont automatiquement déclassés après utilisation,

libérant ainsi des ressources.
Le fonctionnement rapide du pipeline nécessite une automatisation maximale

des tests.
Le déploiement et la distribution, les dernières étapes du pipeline, se font

également automatiquement, avec l’ajustement nécessaire aux systèmes et à
la surveillance des applications.
DevOps Foundation
3.1.4 Résoudre des incidents et des défauts avec DevOps
Dans le cas où l’incident est retracé à un déploiement récent, le

système de contrôle du pipeline saura automatiquement revenir à
l’état stable connu precedent
L’intervention humaine est toujours nécessaire pour analyser le

changement et le corriger, mais il est beaucoup plus facile et plus
rapide, parce que le changement a été fait assez récemment.
Tous les maillons de la chaîne sont connus : le problème à

résoudre, le client, le développeur, le testeur.
DevOps Foundation
3.1.5 DevOps et amélioration continue
Toutes les lacunes identifiées en matière de processus devraient être

éliminées immédiatement.
Si un script qui exécute le pipeline de déploiement ne fonctionne pas

correctement, il doit être corrigé immédiatement.
Contrairement à la pratique traditionnelle où les problèmes peuvent

être reportés, DevOps recommande que les étapes problématiques
soient répétées le plus souvent possible.
Cela permettra de mieux comprendre comment ils devraient être

améliorés, et d’ajuster le travail en conséquence.
DevOps Foundation
3.2 Pratiques DevOps
DevOps Foundation
4.1.1 La Release est une routine
Dans DevOps, une version est une routine. Les sorties se font chaque semaine, et
même tous les jours. Il faut :
- Une réduction drastique de la taille des changements introduits
- Une révision de la pratique de la préparation et de la distribution des rejets...
Le pipeline et les pratiques d’intégration continue et de livraison continue permettent de :

- documenter tous les changements dans le système de contrôle de version
- d’effectuer la plupart des opérations avec des outils automatisés
- d’enregistrer tous les changements
- de mettre en place la surveillance des composants nouveaux et modifiés
immédiatement après le déploiement.
En cas de problème avec le déploiement, le pipeline l’arrêtera automatiquement,

annulera les modifications déjà apportées et avisera l’équipe d’agir.
DevOps Foundation
4.1.2 La Release est une décision business
Une release in ITSM et une release in DevOps ont des définitions différentes :
- Pour la gestion informatique classique, une release est un groupe de changements

déployés conjointement dans l’environnement de production.
- Dans DevOps, il s’agit de rendre une nouvelle fonctionnalité entièrement ou

partiellement accessible aux utilisateurs.
Lors du déploiement continu dans DevOps, la nouvelle fonctionnalité est déployée dans
l’environnement de production dès qu’elle est développée et testée. Les utilisateurs ne le
remarquent pas tant qu’il n’est pas activé.
L’activation est effectuée lorsqu’elle est nécessaire pour l’unité d’affaires. Cela permet de
transférer la gestion des rejets entre les mains du client.
DevOps Foundation
4.1.3 Tout est automatisé
Le célèbre proverbe "La paresse est la mère de l’invention" peut être

transformé en "Un administrateur paresseux finira par écrire un script pour
travailler moins".
Dans le département informatique traditionnel, on peut passer beaucoup de

temps à attendre que les scripts soient écrits.
L’augmentation du niveau de contrôle est cruciale pour DevOps. Tout doit être
stocké dans un système de contrôle de version. Il nécessite une
automatisation totale de toutes les opérations manuelles.
Les environnements requis pour le pipeline de déploiement sont créés

automatiquement par des scripts, sous le contrôle du système de contrôle du
pipeline.
DevOps Foundation
4.1.5 Les défauts sont corrigés immédiatement
Conformément au principe selon lequel le système doit toujours être en état de

marche et pour contrôler la dette technique, la plupart des erreurs détectées
obtiennent la priorité d’être fixé immédiatement - par exemple, dans le même
ou le sprint suivant, si l’équipe utilise Scrum.
La fixation immédiate des défauts exige une transformation significative de la

planification, de la priorisation et des opérations, ainsi que de graves
changements dans les principes de travail de base.
Les erreurs et les histoires d’utilisateurs tombent dans une seule file d’attente
et sont traitées sur un pied d’égalité. Les clients s’impliquent dans la gestion de
la dette technique, ce qui change considérablement à la fois l’importance de ce
travail et la responsabilité de ses résultats.
DevOps Foundation
4.1.6 Les processus sont améliorés en permanence
La façon dont un service informatique conventionnel modifie ses processus :

- Description d’un modèle qui reflète le mode d’exploitation souhaité.
- Mesure de l’écart entre la pratique souhaitée et sa description documentée.
- L’automatisation des processus se fait tardivement
DevOps utilise une approche différente :

- Toutes les lacunes identifiées en matière de processus devraient être
éliminées immédiatement.
- Les étapes problématiques soient répétées le plus souvent possible. Cela
permettra de mieux comprendre comment ils devraient être améliorés, et
d’ajuster le travail en conséquence.
DevOps Foundation
4.1.7 Agir comme une startup
Certaines équipes de DevOps ont vu le jour dans les startups, avec leur culture
spécifique, si inhabituelle pour les employés de l’entreprise. Les entreprises qui tentent
de mettre en œuvre DevOps, tentent d’adopter l’esprit d’entreprise et d’innovation.
Mais qu’est-ce que cela signifie?
DevOps Foundation
3.2.1 Importance d’une équipe diversifiée
DevOps Foundation
Equipe atypique
Une équipe DevOps est une unité de combat incroyable.

Il est responsable d’une petite partie, mais clairement définie d’un système informatique
ou d’une infrastructure informatique. Ayant cette orientation, les membres de l’équipe
deviennent progressivement et inévitablement des experts dans le domaine, tout en
restant pleinement responsables.
Une équipe DevOps n’est pas une équipe de projet temporaire; au contraire, il est formé
pour le long terme.
L’équipe travaille dans son domaine de responsabilité tant que la zone reste pertinente. Si
la trajectoire est modifiée, l’équipe « tourne » avec le domaine de responsabilité ; et si
cette zone est abandonnée, l’équipe passe à une autre.
Les membres de l’équipe travaillent dans l’équipe pour 100% de leur temps de travail, plus
de partage des ressources, combinant des tâches ici et là, couvrant un employé malade
d’un autre département et autres.
L’engagement total de chaque membre de l’équipe simplifie la coordination du travail,
élimine les dépendances sur les facteurs externes et exclut la possibilité de trouver des
excuses dans une autre charge de travail.
Equipe atypique
Les équipes de DevOps sont interfonctionnelles :

Une équipe doit être en mesure d’effectuer pleinement tout le travail dans le flux de valeur
de son domaine de responsabilité. Cela permet une compréhension commune et précise
de la définition d’achevé
La taille de l’équipe est importante :

- Pas trop petite car une petite équipe ne peut pas devenir interfonctionnelle
- Pas trop grosse car les équipes de vingt personnes ou plus sont difficiles à coordonner et
auront besoin soit de management, ou auront tendance à s’effondrer en sous-équipes.
- Les grandes équipes entraînent des coûts supplémentaires de communication et la perte
inévitable d’information entre les membres.
Equipe atypique
Il n’y a pas de chef officiel parmi un petit nombre de membres de l’équipe DevOps.
L’équipe est en mesure de résoudre de façon indépendante tous les problèmes de gestion
et de demande l’appui d’experts ou de mentors dans les cas difficiles.
Tous les membres de l’équipe soient physiquement ensemble (collocated). Un contact

constant en face-à-face est nécessaire les communications électroniques ne suffisent pas.
- les communications « écrites » cachent la composante émotionnelle
- beaucoup de professionnels de l’informatique sont des introvertis
Une équipe DevOps est responsable des outils qu’elle utilise. L’équipe devrait être en
mesure d’évaluer les conséquences de tout changement apporté.
3.2.2 Visualiser le travail
Un outil de visualisation peut soutenir le flux et aider à trouver des réponses aux
questions :
- Combien de tâches sont actuellement acceptées pour travailler sur ces tâches?
- Quelle étape accumule le travail et forme un goulot d’étranglement qui ne permet
pas au reste de la chaîne de fonctionner efficacement?
- Quelles zones ont une capacité potentiellement insuffisante et vont bientôt ralentir
les autres?
- Où les ressources sont déjà ou presque épuisées?
- Quelles tâches sont bloquées et ne seront pas accomplies dans cette itération?
- Que reste-t-il à faire pour la tâche qui n’a pas été accomplie?
- Si nous n’avons pas le temps de faire tout le travail qui a été accepté dans cette
itération, quelle partie de celui-ci vaut la peine pour obtenir le maximum de résultat
utile possible?
DevOps Foundation
A Kanban board allows

to create a pull system
• improves the workflow

• reduces downtime
• reduces the need for
coordination
DevOps Foundation
Mettre la tâche dans le backlog signifie : «C’est une bonne idée, il peut être
mis en œuvre quand et si la décision est prise. »
- Les tâches ne sont priorisées qu’une seule fois, lorsqu’elles sont

transférées de la backlog à la première étape.
- L’annulation d’une tâche en faveur de l’ajout d’une autre tâche est
inacceptable, car les travaux en cours sont l’un des types de déchets
auxquels il faut s’opposer.
- Tous les participants de la chaîne, à l’exception de la première, n’ont pas
besoin de passer le temps à prioriser les tâches entrantes, parce que les
priorités ont déjà été définies et ne devraient pas être modifiées.
- La sortie de l’étape précédente est l’entrée de la prochaine. Après avoir
terminé la tâche actuelle, le membre responsable de l’équipe prend le
prochain de la file d’attente et se lance dans le travail. Cela permet un
flux plus fluide, une utilisation plus efficace des ressources et élimine le
besoin de coordination, réduisant ainsi considérablement le rôle des
superviseurs et des autres gestionnaires opérationnels.
Résumons les avantages de la visualisaWon :
permet de construire un système de tracWon

améliore le flux de travail
réduit les temps d’arrêt
réduit le besoin de coordinaWon
améliore la visibilité des tâches en cours
améliore la compréhension de la quanWté
restante de travail et de l’état actuel
améliore la priorisaWon
réduit le nombre de transferts
aide à idenWfier les inefficacités.
3.2.3 WIP
La longue liste de tâches conduit au chaos. Ce chaos est lié à l’examen fréquent
des priorités par le spécialiste, le passage fréquent entre les tâches, les
changements fréquents dans les priorités en raison de facteurs externes.
Dans certaines entreprises, la pratique courante de priorisation est réduite à
HiPPO: Le plus payé Opinion de personne. La cause de ces problèmes est
multitâche.
Pour s’opposer à cette pratique il faut limiter le nombre de tâches en cours.
A chaque étape du flux de valeur, des restrictions artificielles sont établies en ce

qui concerne le nombre de tâches exécutées simultanément ou sur le nombre
total de tâches acceptées (limite WIP, limite de travail en cours/processus).
Principe de traction : Le prochain dans la chaîne complète sa tâche actuelle, puis
passe à la suivante - exactement au moment où ils deviennent disponibles pour
un nouvel emploi.
3.2.3 WIP
Cette pratique peut conduire à des situations où il n’y a pas de travail sur les
différentes étapes du flux qui attendent l’achèvement des étapes précédentes.
Faire un travail qui n’a pas de client, est un gaspillage. Faire une tâche pendant le
temps d’inactivité juste pour le laisser inachevé plus tard, est un gaspillage.
Il est préférable de prendre le temps d’arrêt comme un indicateur de surcharge

et prendre des mesures. Ces mesures peuvent être à la fois opérationnelles
(assistance au collègue surchargé) et plus systémiques (élimination d’un goulot
d’étranglement dans le cours d’eau).
L’objectif principal est d’assurer le débit, quand tout est bon et régulier, la vitesse
de l’écoulement est également stable. Si dans une situation habituelle, la rivière
devient peu profonde, alors quelque part en amont, il y a un obstacle; il doit être
trouvé et enlevé afin de restaurer le flux normal, régulier et prévisible.
3.2.3 WIP
WIP les restrictions qui sont définies Prévisibilité de la production.

correctement et régulièrement ajustées
sont un bon outil pour équilibrer Malgré tous les efforts pour évaluer la
l’intensité et la productivité du travail. complexité des tâches, il peut être
difficile d’estimer le temps
Il existe une corrélation entre le WIP et
le délai moyen : Deux outils sont pratiques :
- la vitesse de l’équipe
- la gestion de WIP
En resserrant la contrainte, il est possible

d’atteindre des délais plus courts au
détriment de l’utilisation du personnel,
et vice versa.
3.2.3 WIP
DevOps Foundation
3.2.3 WIP et taille des batch devraient être limité
L’option avec des lots plus petits montre de meilleurs résultats, pour les
raisons suivantes :
- Les lots de grande taille sont rarement de taille identiques, contrairement
aux petits.
- De petits lots de la même taille améliorent le rythme de travail, il devient
plus stable et prévisible dans tous les domaines.
- Le temps de la première livraison et le temps de plomb total sont réduits au
minimum en diminuant le temps d’attente dans le flux de valeur.
- De petits lots réduisent le volume total des tâches en cours.
- Le nombre de défauts est réduit, l’ensemble du lot devra être refait en cas
d’erreur. Plus le lot est petit, plus les déchets de la refonte sont petits.
Tout cela influence positivement les aspects clés de DevOps : le temps de

plomb, la charge de travail et la qualité des produits.
3.2.3 WIP et taille des batch devraient être limité
DevOps Foundation
3.2.4 Exigences opérationnelles pour que DevOps fonctionne
DevOps élargit le rôle de propriétaire de produit, en tant qu’il est

concerné par un système informatique entièrement opérationnel (y
compris les exigences fonctionnelles).
Cela modifie radicalement l’importance de NFR et déplace l’attention

de l’équipe vers un produit de travail, où le travail ne se limite pas à la
fonctionnalité convenue.
DevOps suggère d’abandonner le terme “exigences non

fonctionnelles” pour “exigences opérationnelles”.
L’accent est mis sur la résilience ou anti-fragilité. Le système doit

détecter et corriger les défaillances et rétablir les opérations normales
sans perte significative de performances et sans affecter les utilisateurs.
DevOps Foundation
3.2.5 Soutenir l’innovation
La dette technique doit être réduite, le travail doit être amélioré et les nouvelles
technologies maîtrisées. Le service informatique moderne ne peut pas se permettre de
s’engager dans ces tâches importantes en arrière-plan.
Certaines entreprises commencent par l’attribution d’une certaine proportion du

temps de travail pour l’amélioration (taxe de 20 %)
Kaizen Blitz: Le temps d’amélioration peut ne pas être planifié à l’avance, mais est
alloué au besoin, les participants externes impliqués
Hackathons : un calendrier spécialement alloué à l’exploration des nouvelles

technologies et à la création de nouveaux produits et outils
Sélectionnez des idées intéressantes, investir des ressources limitées
DevOps Foundation
3.2.6 Faire face aux goulots d’étranglement
L’état d’un flux uniforme sans retards n’est pas atteint du jour au
lendemain et nécessite des efforts.
- en utilisant des outils de visualisation ainsi que des limites WIP, on peut
identifier les goulots d’étranglement de ce flux de valeur.
- parmi tous les goulots d’étranglement connus, il y en a un qui cause le
plus de retard — c’est sur celui qui se concentre.
Séquence :
- Comprendre comment changer les règles du travail à court terme,
afin d’utiliser (exploiter) le goulot d’étranglement identifié au maximum.
- Trouver un moyen d’éliminer le goulot d’étranglement
- Annuler les règles à court terme établies précédemment et
commencer à chercher le prochain goulot d’étranglement le plus
important
DevOps Foundation
Priorité des tâches
Un domaine qui cause souvent des difficultés est la priorisation des tâches
dans la file d’attente à l’entrée du flux de valeur.
Avantages de la métrique du coût du retard :

- facile à utiliser pour celui qui est au tout début du flux de valeur
- une prise de décision économiquement saine, qui est transparente pour
tous les participants.
- l’aide à maîtriser activement la pratique de limiter le WIP.
Si vous exécutez plusieurs tâches simultanément, la mesure donnera le pire

coût du retard. Le coût du retard est conçu pour exclure tous les autres
paramètres, en simplifiant la prise de décision et en réduisant les déchets au
tout début du flux de valeur.
Identification continue, exploitation et élévation des contraintes
La chaine de valeur aura toujours des contraintes qui doivent toujours être
prises en compte.
Grace aux outils de visualisation on peut identifier les goulots

d’étranglement des flux de valeur.
Travailler avec un goulot d’étranglement se compose de deux étapes :

- Comprendre comment changer les règles du travail à court terme, afin
d’utiliser (exploiter) le goulot d’étranglement identifié au maximum.
- Trouver un moyen d’éliminer le goulot d’étranglement, de nous en
débarrasser.
4. Application pratique de DevOps
4.1 Applicabilité
4.2 Limitations
4.3 Utilisation d’un logiciel commercial hors de l’étagère
4.4 Évolution de l’architecture et des modèles organisationnels
4.5 Progression itérative
DevOps Foundation
4.1 Applicabilité
DevOps n’est pas un remède magique de toutes les «maladies».
Toutes les organisations ne devraient pas penser en principe à

DevOps.
Ne commencez pas les pratiques DevOps si...

- l’entreprise ne participe qu’à une partie limitée du flux de valeur.
- l’entreprise ne voit pas la technologie de l’information comme un
moteur d’entreprise essentiel.
- l’entreprise veut réduire la dette technique ou éliminer la fragilité
de l’IT
DevOps Foundation
4.1 Applicabilité
L’entreprise devrait s’intéresser à DevOps lorsque :
- Son cœur de métier dépend fortement des technologies de l’information.

- Les technologies de l’information ont un taux élevé de changement.
- L’activité principale nécessite des changements rapides pour tester de
nouvelles idées ou hypothèses d’affaires.
- Les risques liés à l’informatique sont jugés inacceptables.
- Toutes les autres méthodes éprouvées d’augmentation de l’efficacité ne
donnent plus de résultats significatifs.
DevOps Foundation
4.2 Limites
DevOps n’est pas très approprié pour :
- Les entreprises qui n’ont pas de développement de logiciels

propre.
- Les organisations qui utilisent leur propre logiciel, où les
développeurs ne sont pas membres du personnel.
- Les entreprises qui ont une longue façon de travailler et qui ne
sont pas prêtes à subir une restructuration majeure.
- Les organisations à architecture informatique monolithique et
rigidement liée.
DevOps Foundation
4.2 Limites
L’introduction de petites équipes nécessite la possibilité

d’attribuer un domaine de responsabilité distinct à chacune
d’entre elles.
Dans une situation où le système informatique en question est

encore en cours de développement et maintenu par des
dizaines ou des centaines d’employés en tant qu’entité
unique, il être difficile de séparer les pièces pour les équipes
indépendantes et qui travaillent de façon asynchrone.
DevOps Foundation
4.3 Using Commercial Off-the-shelve Software
DevOps Foundation
4.3.1 COTS dans les secteurs stratégiques
Dans une situation où la concurrence se déplace vers les

technologies de l’information, il est nécessaire d’avoir une flexibilité
et un contrôle maximal, généralement inaccessibles au COTS.
Premier conseil que tout expert sérieux donnera : Vous devez vous
débarrasser de la COTS travaillant dans les domaines les plus
importants de votre entreprise.
Passez au développement de logiciels interne.
DevOps Foundation
4.3.2 Comment travailler avec COTS ?
Étudier le processus d’installation en détail, comprendre ce que fait

l’installateur.
Créez votre propre script, en reproduisant le travail de l’installateur d’origine.
Outils de configuration standard pour COTS, les paramètres d’application

sont exportés dans un format adapté au système de contrôle de version
Le meilleur scénario pour COTS est une re-création complète automatisée

régulière de l’application dans l’environnement de production à partir de
zéro, basée sur les données du système de gestion de configuration, sans
temps d’arrêt du système et inaperçue par les utilisateurs.
DevOps Foundation
4.4 Évolution de l’architecture et des modèles organisationnels
DevOps Foundation
4.4.1 Difficultés qu’un service informatique pourrait faire peser
sur la mise en œuvre de DevOps
De petits changements dans une partie du système peuvent avoir des effets négatifs
dans d’autres parties.
Très peu d’employés comprennent le système informatique de façon holistique, ils

deviennent très précieux, irremplaçables et surcharges
Toute documentation sur le système informatique devient rapidement obsolète
Le développement et le fonctionnement du système informatique sont séparés de

manière
Il est difficile d’identifier les domaines de responsabilité des petites équipes

autosuffisantes, de sorte que les principaux avantages du développement agile sont
réduits à aucun et ne répondent pas aux attentes
L’architecture existante ne répond pas entièrement aux exigences actuelles, elle

devient obsolète peu de temps après sa création
DevOps Foundation
4.4.2 Besoin d’un état d’esprit flexible pour changer et innover
La culture DevOps est très différente de la culture régulière, qui, bien sûr, est un obstacle pour un
changement direct et rapide dans le style de travail dans les entreprises traditionnelles
DevOps Foundation
4.5 Progression itérative
DevOps Foundation
4.5.1 DevOps peut commencer petit et peut être construit à partir de là
Identifier les systèmes qui sont vaguement connectés avec d’autres

Utilisez ces systèmes comme pilote pour appliquer des éléments
DevOps de base :
flux de valeur
pipeline de déploiement
système de contrôle de version
gestion automatisée de configuration
Appliquer cette expérience à d’autres systèmes
En commençant par des cas plus simples, vous pouvez passer à
autre chose avec plus de confiance.
DevOps Foundation
4.5.2 DevOps est une façon de penser, qui peut commencer n’importe
où dans l’entreprise
Vous ne pouvez pas implémenter DevOps
DevOps peut être utilisé, pour résoudre des problèmes spécifiques de l’organisation
DevOps n’est pas un produit logiciel qui peut être installé et lancé
DevOps n’est pas un ingénieur qui peut être embauché pour apporter la nouvelle
commande à l’informatique
DevOps exige à bien des égards des changements culturels et organisationnels, et ces
changements ne se limitent pas au service informatique
DevOps implique que non seulement la frontière entre le développement et

l’exploitation disparaîtrait, mais aussi entre l’informatique et les
DevOps signifie jouer un long jeu, à partir d’aujourd’hui jusqu’à pour toujours
DevOps Foundation
“Always take on new challenges—even if you are not sure you are completely
ready.”
Sheryl Sandberg, COO of Facebook
DevOps Foundation
Test
We regularly measure the Lead Time, Process Time and the Percentage of
work done without errors (% C/A):
a. for all changes — 5 points

b. from time to time — 3 points
c. this is not measured, but we measure a lot of other things — 1 point
d. all measurements are evil and provocation — 0 points
Our Lead time on average is:
a. several hours — 5 points

b. several days — 3 points
c. several weeks — 1 point
d. several months — 0 points

Test
The frequency of releases to the production environment is:
a. several times a day — 5 points

b. several times a week — 3 points
c. several times a month — 1 point
d. we schedule releases on quarterly (or longer) basis — 0 points
We release:
a. we do not release, our business does — 5 points

b. as often as the business requires — 3 points
c. usually rarely, but urgent releases are possible — 1 point
d. in accordance with the release policy, when changes accumulate — 0
points

Test
When we introduce changes to the production environment, the downtime

is:
a. there is no downtime — 5 points

b. several minutes — 3 points
c. several hours — 1 point
d. we have a time agreed with the business to shut down the systems for
change implementation — 0 points
We bring destruction to the production environment:
a. we don’t; it is done constantly by specially designed scripts and systems

— 5 points
b. when testing and deploying — 3 points
c. almost every day, when we do the usual work — 1 point
d. no destruction is possible, everything is stable — 0 points
Test
We allocate time for improvements and innovations:
a. up to 20% of working time — 5 points

b. not regularly, but we are trying — 3 points
c. we are getting better while doing the usual work — 1 point
d. we are being improved by special people — 0 points
Our business experiments on living breathing users:
a. every day — 5 points

b. from time to time — 3 points
c. when the IT department allows — 1 point
d. we do not need to experiment, because our analysts know everything
about the users perfectly well anyway — 0 points

Test
Our deployment pipeline:
a. works completely automatically — 5 points

b. has several manual steps — 3 points
c. we do not have a pipeline — 1 point
d. it is impossible to have a pipeline in our conditions — 0 points
We prioritize tasks in the value stream:
a. based on the cost of delay — 5 points

b. quickly calculating the benefits, resources and urgency — 3 points
c. we play poker — 1 point
d. we do not prioritize, this is done for us — 0 points

Test
We deliver a minimum viable product (MVP) in order to:
a. obtain the most complete information for decision making using

minimum resources — 5 points
b. understand whether it is worth moving on — 3 points
c. show our beta version to the parties concerned — 1 point
d. we do not deliver MVP — 0 points
We present system uptime information:
a. on dedicated freely available web pages — 5 points

b. in reports to individual customers — 3 points
c. in the monitoring system — 1 point
d. we do not present it — 0 points

Test
We fix incidents in the production environment :
a. by quickly re-creating part of the infrastructure — 5 points b. by rolling

back unsuccessful changes — 3 points
c. through the incident management process — 1 point
d. by rebooting — 0 points
Our value stream:
a. is visualized in a state of ‘as is’ and designed to ‘to be’ — 5 points

b. is in our memory — 3 points
c. is drawn on the wall in the manager’s office — 1 point
d. we (the IT department) are the value — 0 points

Test
We update our IT infrastructure:
a. only by means of the scripts stored in the version control system — 5 points
b. by means of the scripts developed by the administrators for themselves —
3 points
c. manually by the administrators — 1 point
d. manually by the DevOps engineers — 0 points

Anglais Français Anglais Français
affinity (in DevOps) change management
Agile infrastructure cloud computing

automated testing collaboration (in DevOps)
automation commercial off-the-shelf
software (COTS)
blamelessness commit code
build (management) communication
business value styles compact
Definition of Done configuration

management

Thank you – EXIN DevOps Foundation
QUESTIONS?
114
DevOps Foundation

Lamarck Institute DevOps Foundation French V1.0 Compressed 1

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Lamarck Institute DevOps Foundation French V1.0 Compressed 1

Transféré par

Droits d'auteur :

Formats disponibles

DevOps Foundation@@

Body of Knowledge for the EXIN Scrum Foundation Certificate

• EXIN DevOps Foundation est idéale pour les professionnels de l’informatique et

• Cela inclueceux qui participent à une équipe DevOps et toute personne

DevOps A Businness Perspective Effective DevOps

1.1 Origines de DevOps

Une transition importante de la gestion informatique fut le passage dans les

Adoptées avec succès par les dirigeants, les pratiques de gestion

DevOps est apparu en raison de deux facteurs :

• Au cours du 20ème siècle, le modèle en cascade (Waterfall) a été la

• Dans les années 1990, Internet a accéléré la nécessité de lancements rapides

Le développement agile utilise une approche

Manifeste pour le développement Agile de logiciels

Personnes et interac.ons > Processus et outils

Logiciel qui fonctionne > Documentation

Collabora.on avec le client > Négociation à partir d'un contrat

S'adapter au changement > Suivre un plan

Nous reconnaissons la valeur des seconds éléments,

Nous découvrons comment mieux développer des logiciels par la pratique

L’émergence de la gestion de l’infrastructure informatique en tant que

Les professionnels de l’informatique pourraient créer les parties de

Aujourd’hui, on peut créer une infrastructure informatique en :

- exécutant un script et en attendant l’achèvement de son exécution

Gérer l’infrastructure comme du code :

Un context qui a permis l’émergence de DevOps :

• de nouvelles façons d’interagir avec les métiers par l’application

• de nouvelles technologies de gestion des infrastructures, il est devenu

Tout cela a amené à penser de Nouvelles façons de gérer l’IT.

une évolution des appliquées à

• DevOps est une évolution des idées de développement de logiciels

• L’essence même de DevOps est de penser non seulement au

• Une représentation visuelle du processus aide à se concentrer sur la valeur

• Cela aide à identifier et à éliminer les goulots d’étranglement, tout en évitant

• Accélérer la livraison de produits nouveaux et modifiés sur le marché

• Réponse plus rapide aux besoins des clients

• Amélioration de la disponibilité et de la durabilité des systèmes informatiques

• Utilisation plus efficace des ressources limitées

Traditional Companies - Years

Société traditionnelle (années) - Optimisé pour le coût

• Structuration et redaction d’un idée de business et justification

Entreprises dynamiques (Semaines) - Op;misé pour la vitesse

DevOps tÉchniques (jour)

Pour réduire le temps de commercialisation, DevOps propose une variété

• La dette se produit lorsqu’un membre de l’équipe choisit un moyen non

• La refactorisation constante de DevOps du code de programme permet de

• DevOps recommande fortement d’utiliser la pratique de « faire face aux

• Dans DevOps, le code et le système dans son ensemble sont

• DevOps introduit délibérément du chaos et de l’instabilité

• Mettre en palce DevOps nécessite des changements culturels plus importants

L’application d’une approche agile du développement de logiciels

Les méthodes Agile ne couvrent qu’une partie de la chaîne de valeur,

Les méthodes agiles ne tiennent pas compte des spécificités et de la

Certaines entreprises signalent l’épuisement professionnel de leurs

• Mythe ou fait : « Les outils vous fourniront les DevOps »

• Bien que les solutions logicielles individuelles soient largement adoptées, il

• DevOps dépend de la disponibilité et de l’efficacité de certains outils

• Toute implémentation particulière de DevOps peut être indépendante sur le

Mythe ou fait : « DevOps est un soldat universel, capable de coder,

DevOps est un changement profond dans les fondamentaux du

La capacité de mettre en œuvre un pipeline de livraison de logiciels

• Dans le Lean, concept de déchets est central

Le Lean peut être décrite par la séquence suivante d’étapes :

DevOps emprunte de nombreux concepts de Lean comme :

2.1 Chaine de valeur