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