Le 03/02/2021

DevOps

Introduction

1

Qui suis-je ?

CommercialChef de projet

Infra, Réseau (~Ops)Fan de scripting,

CTF et autres challenges

Ingénieur Chimiste Développeur puis Expert technique

Java, .net, Js, …

Architecte SOA

Architecte Logiciel

Architecte Cloud & DevOps enthousiaste

SCHMITT SébastienArchitecte Cloud

2

Plan du document

• La Stratégie DevOps

• Organisation

• Architecture

• Outillage

• Gouvernance

• REX

3

La stratégie DevOps

4

Définition• DevOps est la concaténation du mot anglais « development » (développement) et « operations »

(exploitation).

• DevOps est issu de conférences professionnelles (devopsdays.org)

• « DevOps est un ensemble de pratiques (une philosophie) multi-disciplinaires consacrées à l’étude dela construction, de la maintenance évolutive et de l’exploitation de systèmes informatiques qui doiventpouvoir être modifiés rapidement. » - Jez HUMBLE.

• Objectif : diminuer la durée comprise entre la demande de modification d’un service IT et sa mise enligne tout en améliorant la qualité des applications et en diminuant le coût.

5

Constat: fonctionnement en SILO

Développer une culture collaborative et améliorer la communication

Développement Agile DevOps

6

Préconisations• Plus petit, plus vite et plus souvent

• Modifier l’organisation autour d’équipes autonomes, multi compétentes en charge de l’ensemble ducycle de vie (modèle « build & run »)

• Architecture agile (modulaire)

NETFLIX (chiffres plus très à jours mais l’idée demeure) :

• 100 déploiements / jour

• Equipe co-localisée par application

• La plateforme démarre et arrête des instances en fonction de la charge ou pour compenser des incidents

• Les développeurs sont responsables du fonctionnement et peuvent être appelés à toute heure

7

1. Culture et organisation

8

Initialisation de la transformationculturelle et organisationnelle.Mise en place de l’agilité surl’équipe étendue

1- Fluidification

Équipes virtuelles responsable dubuild et de la gestion des incidentsen production. Compétences infra.et dev. délocalisées

2- Hybridation

Equipe pluridisciplinaire etresponsable« you build it, you run it »

3- Unification

DevOps Evangelist

Change Manager

Release manager

Architecte Automatisation

Ingénieur Sécurité

Nouveaux rôles

Change Management

9

Exemple d’organisation

Spotify a su créer une culture ouverte et flexible, basée sur l’autonomie,

source de motivation et propice à l’innovation.

10

• Les squads sont des équipes de 5 à 7 ingénieurs et d’un Product Owner

totalement autonomes comme si ensemble ils créaient une startup. On fait

en sorte que cette Squad soit pluridisciplinaire.

• Chaque Squad est autonome et peut utiliser la méthodologie agile ou

apparentée agile de son choix voire celle qui est la plus adaptée au besoin :

Scrum, kanban, Lean startup…..

Organisation en Squad

La Pizza team

11

• Dans chaque Squad, nous avons des compétences

équivalentes.

Rassembler 1 personne de chaque squad pour

créer un chapitre permet de s’aligner sur une

même vision/pratique commune.

• 1h / semaine entre chaque chapitre suffit souvent

pour avoir une meilleure vision globale et de ne pas

voir chaque Squad partir chacune dans leur coin …

Synchroniser les pratiques

Les chapitres

12

• Les tribus représentent plusieurs Squads (de

5 à 8) qui travaillent ensemble sur un même

thème global.

• Il est conseillé de ne pas dépasser des tribus

de 80 personnes afin de garder un

dimensionnement raisonnable.

Transversalité

Les tribus

13

• Les guildes rassemblent des personnes dans

l’ensemble de l’entreprise pour qu’elles puissent

régulièrement partager sur des sujets similaires afin

de s’aligner sur une même vision.

• Le participation est libre et ouverte.

Communautés d’intérêt spécifiques

Les guildes

14

• Formation : former les équipes grâce à des formations classiques, des workshop de partage…

• Hack day ou hack week : sessions pour développer quelque chose de différent qui pourrait apporter

un jour à l’entreprise.

• Adds-on : 20% du temps de chacun est consacré à s’améliorer soit 1 journée chaque semaine.

• Post-mortem : on se rassemble 1 journée complète pour partager sur un incident passé. Ce principe

se rapproche des 5 pourquoi qui permet d’aller chercher plus loin la source du problème.

Les pratiques recommandées

Amélioration continue

15

2. Design & Architecture modulaire

16

Web stg

Service

Browser app or embedded in native

JSONEvents & notifications

HTTP &Websockets

Service Service Business / Domain services

Service Service Service

SQL NoSQL Other

API

HTML & JS Engine

DOM Controllers

Client-side model

• L'architecture microservices est une approche de conception qui

consiste à diviser une application en un ensemble de petits services.

• Les microservices sont conçus autour de capacités métier, et dédiés à

une seule fonction.

• Vous pouvez utiliser différents frameworks ou langages de

programmation pour les écrire et les déployer indépendamment, en

tant que service unique ou en tant que groupe de services.

HTML & JS Engine

DOM Controllers

Client-side model Web stg

Service Layer

Channels Repositories RDBMS

Browser app or embedded in native

JSONEvents & notifications

HTTP &Websockets

CRUD

Architecture modulaire

17

Les architectures « cloud »Des services managés

permettent d’accélérer la mise

en place.

La containerisation garantit la

portabilité des solutions (cloud

privée, public, on-premise…)

Les approches « server-less »

prennent en charge de manière

performante des conteneurs.

CognitoUser Management

API GatewayRESTful API

CloudWatch LogsMicroservices Logging

Trust Advisorroles and policies

Database

Identity Token

1

2

3

4

56

docker containerMicroservices

BackOfficeFrontOffice

18

Stratégies de développement• Il existe de nombreux workflow de développement « Gitflow », « Simple Branching », …

• Il faut choisir celui qui correspond le mieux à votre équipe / votre besoin !

Gitflow le code de la branche master est le code qui est prêt pour passer en production.

Très intéressant quand on utilise toujours la dernière version du logiciel, mais qu’est-ce qui se passe quand on doit supporter plusieurs versions ?

19

• Simple branching est une pratique de développement dans laquelle tous

les développeurs « commit » leurs changements sur une seule branche

qui est « delivery-ready ».

• Cette pratique nécessite d’avoir une couverture complète de tests

unitaires automatisés et de les jouer à chaque commit. Dans cette

organisation, chaque version livrée en production est tagguée afin de

pouvoir au besoin la « patcher » sans avoir à intégrer les développements

de la branche principale.

• Le simple branching permet de limiter au maximum les « merge », et

oblige à utiliser la plupart des bonnes pratiques de développement, dont

le « feature flipping » en particulier.

« Simple Branching »

Stratégies de développement

20

Blue/green deployment- Permet à minima, d’effectuer des mises en

production de manière transparente

Stratégies de déploiement

Canary release- Tester de nouvelles fonctionnalités sur une petite

population cible avant ouverture complète

Feature toggle- Activation très rapide de nouvelles fonctionnalités

en Production

21

La notion de « test » s’invite

dès l’analyse du besoin et la

conception.

Le test ne sert plus

seulement à vérifier

l’absence d’anomalie mais

également à guider la

conception et les

développements de la

solution logicielle.

Stratégies de tests

22

Automatisation des tests

TU TU

Recette Recette

Cycle en V Mode DevOps

23

3. Outillage

24

La chaîne d’outils DevOps

25

Tableau périodique des outils DevOps

26

Intégration / Livraison / Déploiement continue

• Intégration continue : Build et TU automatisés pour détecter les erreurs au plus tôt

• Livraison continue : Déploiement pour recette, tests et validation manuels avant la prod

• Déploiement continue : Mise en production automatique

27

Monitoring

• Suivre les métriques et les logs permet de découvrir l'impact des performances de

l'application et de l'infrastructure sur l'expérience de l'utilisateur final.

• La supervision active et automatisée est de plus en plus importante, car les services doivent

aujourd'hui être disponibles 24h / 24 et la fréquence des mises à jour augmente sans cesse.

Watch

28

4. Gouvernance des équipes

29

Gouvernance• Choix stratégiques d’une entreprise

• Permet de coordonner l’ensemble des services pour être en accord avec la vision de l’entreprise.

Mesurer

Expérimenter PrioriserOn ne peut améliorer

que ce qu’on mesure !

30

REx

31

Retour d’expérienceTransformation DevOps d’une grand fabriquant de pneus Français

• 2012 : Première expérience Agile/DevOps Arrêt en 2013 car les managers n’étaient pas impliqués/moteurs

• Lancement en 2013 d’un plan de transformation sur 5 ans

• Découpage en 4 chantiers :

• Expérimentation sur une équipe avec un périmètre complet.

• Définition d’un catalogue standard et gestion en auto-provisionnement

• Reprise à leur charge de toute l’infra existante en 2 ans

• Refonte des équipes internes en Delivery Squads

Réussite de la transformation en 2018/2019

32

Expérimentation

From a continuous integration toolset to a continuous delivery platform with: release automation, infra provisioning,…

• One Integrated Team (People + process + tools)

• NFR = A function of the application

• Std catalog & Self provisonning

• Adaptive project life cycle

• Validation Based on risk Mngmt

• Release Train to go-live

33

Refonte des équipes

MODÈLE D’ORGANISATION DU TRAVAIL

SCRUM WATERFALL KANBAN

Attributs

STABLE DANS LE TEMPS AUTO-ORGANISÉE PLURIDISCIPLINAIRE MEMBRE DE L’ÉQUIPE DÉDIÉ CO-LOCALISÉ (AUTANT QUE

POSSIBLE)

34

Quizz DevOpsVoyons si vous avez suivi

Source : https://www.rudder.io/fr/blog/2015/08/25/quiz-expert-devops/

https://app.klaxoon.com/join/ZC8M6XZ

35

DevOps, c’est quoi ?

1. Une philosophie de travail pour les équipes IT.

2. Des outils pour les équipes dev et ops.

3. Une personne qui fait le lien entre les devs et les sysadmins.

36

Comment se former sur le sujet ?

1. Embaucher des consultants expert DevOps.

2. Appliquer des conseils d’internet au pied de la lettre sans se polluer l'esprit avec le contexte existant, les experts de la toile ont forcément raison !

3. Aller dans des conférences, partager son expérience, l’apprentissage et la communication c’est la base.

37

Pour faire passer les équipes au DevOps il faut

1. Enlever les barrières entre les équipes, faciliter la discussion et le partage de compétence transverses.

2. Solliciter un architecte DevOps permettant de mieux faire coopérer les équipes.

3. Constituer une équipe DevOps séparée des équipes actuelles, afin que chacun puisse faire son travail sans gêner les autres.

38

A quoi ça sert ?

1. Réduire les effectifs, les devs peuvent remplacer les ops et inversement, et donc réduire les coûts.

2. Suivre les tendances hype c'est important pour rester à la page, et dans un an on change.

3. Favoriser le partage de points de vue et de compétences entre les équipes permet de réduire les tensions, et de fournir des livrables plus proche des besoins, plus tôt.

39

Des serveurs sauvages apparaissent !

1. Pas de soucis, on a une image d'une ancienne machine, on la clone et on fait les modifs restantes avec le script à Didier.

2. Ils sont intégrés dans les process d’automatisation (provisioning, gestion de configuration, etc.) et... c'est tout c'est fini !

3. Il faut tout configurer à la main afin de mieux maîtriser les paramètres.

40

Il faut mettre en prod, comment ça se passe ?

1. Thierry push son commit, ça marche sur son poste, même si c’est pas à lui de s’occuper de la mise en prod, en plus on est Vendredi.

2. Thierry push son commit, les membres de l'équipe collaborent afin de valider correctement cette version avant qu'elle soit effectivement mise en prod.

3. Thierry push son commit dans Git, il y a tout un pipeline d’outils ContinuousDelivery, le Jenkins générera une nouvelle image Docker à publier direct dans le cloud...

41

Les principes DevOps sont "C.A.M.S.", ce qui signifie :

1. Create, Anticipate, Migrate, Simplify

2. Cloud, Ambition, Manual, Servers

3. Culture, Automation, Measurement, Sharing

42

DevOps : Key points

• C’est une culture d’entreprise

• Les managers doivent être moteurs

• Mais tout le monde est impliqué

• Il faut revoir la façon de concevoir/développer

• Les outils peuvent vous aider

• Tester le TDD, la conteneurisation (docker), le Cloud

43

Merci