The Doppler Quarterly (FRANÇAIS) Hiver 2016 | Page 13

NIVEAU DE
MATURITE
Niveau 1
Ad Hoc
Niveau 2
Reproductible
Niveau 3
Défini
Niveau 4
Mesuré
Niveau 5
Optimisé
PERSONNES
PROCESSUS
TECHNOLOGIE
• Cloisonnement
• Rejet des fautes
• Dépendance vis-à-vis des experts
• Manque de prise de responsabilité • Processus manuels
• Les connaissances tribales sont la norme
• Imprévisibles, réactifs
• Développements et déploiements manuels
• Tests manuels
• Manque d'homogénéité de l'environnement
• Communications gérées
• Partage des connaissances limité • Processus établis au sein du cloisonnement • Développements automatisés
• Pas de normes
• Tests automatisés écrits au sein d'un
• Peuvent répéter les éléments connus,
développement
ne peuvent réagir à l'inconnu
• Sorties de logiciels difficiles mais
reproductibles
• Collaboration existante
• Prise de décisions en commun
• Responsabilité partagée • Processus automatisés autour du SDLC • Cycles automatisés de développement &
• Normes dans toute l'entreprise
de tests pour chaque validation
• Déploiements par pression d'une touche
• Tests automatisés des utilisateurs et
de l'acceptation
• Collaboration appuyée sur des
mesures communes avec un accent
mis sur la suppression des goulets
d'étranglement • Surveillance proactive
• Mesures collectées et analysées par
rapport aux objectifs d'entreprise
• Visibilité & prévisibilité • Mesures de développement visibles et
déclenchant des actions
• Déploiements orchestrés avec
restaurations automatiques
• Exigences non fonctionnelles définies et mesurée
• Une culture d'amélioration
constante se diffuse dans toute
l'entreprise • Automatisation en autonomie
• Optimisation des risques & des coûts
• Haut niveau d'expérimentation • Déploiements sans aucune interruption
• Infrastructure immuable
• Mise en place active de la résilience en
déclenchant des défaillances
Figure 1 : Le modèle de maturité DevOps s’appuie sur le degré de
capacité d’une entreprise à tirer une valeur ajoutée des processus et de la technologie DevOps.
Certaines entreprises de développement tentent de
séparer le développement et les opérations, mais cette
voie entraîne vite des dysfonctionnements. La création
d’un nouveau rôle est une meilleure approche : celui de
gestionnaire DevOps. A mesure que vos besoins en
développement augmentent, vous pouvez créer de
nouveaux postes de gestionnaires DevOps. Ainsi, l’or-
ganisation reste compacte, agile, et concentrée sur ses
objectifs spécifiques au sein des systèmes qu’elle con-
struit et met en œuvre.
Etape 4 : Définir un processus DevOps
De nombreuses ressources expliquent comment
définir un processus DevOps : une agilité automatisée.
Cependant, il existe autant de types de processus
DevOps que d’entreprises, et il convient donc d’adopter
celui qui correspond le mieux à vos besoins.
La Figure 2 montre un processus DevOps complet,
dont vous pouvez vous inspirer. Il est possible que
certaines étapes vous soient inutiles, tandis que d’au-
tres manquent à ce modèle. En revanche, il faut tou-
jours conserver la prise en charge du développement,
de l’intégration, des tests, du déploiement continus et
des opérations. Les outils et les étapes que vous
emploierez dépendront de votre entreprise et de vos
besoins technologiques.
Le DevOps dans le cloud
Ce processus s’applique généralement aux plateformes
traditionnelles, comme Linux, Apache, MySQL, et la
pile PHP/Python/Perl (LAMP), vers les clouds public et
privé, plus récents. La Figure 2 indique une ligne de
démarcation classique. Cependant, le processus peut
s’appliquer à toutes les plateformes cloud et aux outils
DevOps cloud, ou à toutes les plateformes tradition-
nelles et aux outils DevOps sur site.
Etape 5 : Définir votre plateforme cloud cible
Il est important de définir votre plateforme cible pour
l’hébergement des applications pour deux raisons.
D’abord, cette plateforme dépend énormément des
outils DevOps que vous choisissez, et en particulier des
HIVER 2016 | THE DOPPLER | 11