Devops

1. LE DEVOPS DU
DIRECT @

2. SOMMAIRE
• Mais… c’est quoi un DevOps ?
• Différence entre un Dev et un Ops
• Principes du devops ( ou comment être un bon devops)
• Les outils pratiques du devops
• Processus du devops
• Conclusion

3. MAIS… C’EST QUOI
UN DEVOPS?

4. • Le DevOps est une philosophie qui viens intégrer des principes
organisationnels et fonctionnels au sein de la chaîne de production.
• DevOps est un mot anglais bien souvent utilisé à tort dans le milieu
professionnel souvent par les équipes marketing, un peu éloigné de
la réalité.
• DevOps est la contraction des mots «development » et « operations
».
• Le DevOps représente une philosophie de travail et de méthodologie,
un « DevOps » est donc une personne capable d’avoir un visuel sur
les diverses étapes de la chaîne de production, coté développement
et opérationnel. Il a des affinités générales lui permettant de gérer
seul des problématiques nécessitant les deux parties.
• Il est né d’un souci d’interopérabilité, et de globalisation des
méthodologie agiles à l’échelle d’une équipe ou d’un Système

6. DIFFÉRENCE ENTRE
UN DEV ET UN OPS

7. •Le dev : Il est en charge
des améliorations,
nouvelles
fonctionnalités et
changements
applicatifs.
•L’ops : en charge de
l’exploitation des
applications et des
infrastructures

8. •Le DevOps a émergé de deux tendances
antérieures : le mouvement du
développement agile et les principes du
lean manufacturing.
•Le premier met l’accent sur des cycles de
travail courts et des itérations rapides
pour créer une organisation de
développement IT plus réactive, et le
second minimise le gaspillage et

9. LES PRINCIPES DU
DEVOPS

10. • L’acronyme CAMS regroupe les principes essentiels du DevOps :
• Culture : le DevOps est avant tout une culture et une philosophie qui
consiste à mettre en place un terrain de collaboration entre les équipes du
développement logiciel et ceux des opérations d’infrastructure.
• Automating (automatisation) : l’automatisation est un aspect majeur du
DevOps. Qu’elle soit dans le développement, le déploiement ou la
configuration, elle apporte une grande facilité si elle es utilisée de façon
efficace et au bon endroit.
• Measurement (mesure) : pour avoir les meilleures performances il faut déjà
savoir mesurer l’existant. Avoir les bonnes métriques est primordiale pour
toute évolution.
• Sharing (partage) : un point très important est celui de capturer le savoir et
de le partager. C’est un principe tout autant crucial que les trois précédents.
Il permet de développer l’intelligence collective et d’ajouter de la
transparence. Ainsi l’entreprise ne dépendra de personne en particulier. Il se
concrétise par le partage des feedbacks, des techniques et des bonnes
pratiques.

11. LES PRATIQUES DEVOPS

12. CONTRÔLE DU CODE SOURCE (SCM – SOURCE
CODE MANAGEMENT OU VSC – VERSION
CONTROL SYSTEMS)
• Le contrôle du code source est un moyen pour garder trace et
historiser les changements apportés à un code source et de
collaborer sur ce dernier.
• C’est un élément essentiel pour le développement en général et
indispensable pour le DevOps en particulier. Le contrôle du
code source permet d’avancer rapidement et intelligemment. Il
protège notamment le code source des dommages soudains,
des erreurs humaines et des différents conflits.

13. GIT
Git est un contrôleur de code source gratuit et
open source. Il est nettement plus rapide que
beaucoup d’autres logiciels de contrôle du code
source. Il assure parfaitement les
fonctionnalités nécessaires à un VSC qui sont :
Un historique complet des modifications à long
terme de chaque fichier : chaque changement
(création, modification ou suppression) dans
chaque fichier est historisé et stocké avec les
auteurs de ces changements.
Branching et merging : sont très efficaces pour
la collaboration et l’introduction de nouvelles
fonctionnalités.
La traçabilité : pouvoir retracer chaque
modification apportée au code. Mais aussi avoir
la possibilité de le connecter à un logiciel de
gestion de projets et de suivi des bugs.

14. TESTS CONTINU
• À chaque nouvelle version de code, on exécute une série de
tests pour avoir des feedbacks le plus rapidement possible.
Cela permet de vérifier la validité et la qualité du code. Le but
est d’éviter toutes sortes de bugs ou problèmes dans
l’environnement de production qui peut être très couteux.
• Trois catégories de tests se distinguent :

15. • Fonctionnels : ils permettent de tester l’aspect fonctionnel de
l’application et regroupent essentiellement :
• Les tests unitaires pour tester le fonctionnement des modules d’une
application de façon isolée, sans interdépendance avec d’autres modules
• Les tests d’intégration pour tester le fonctionnement des modules en
tant qu’ensemble
• Les tests d’acceptation par l’utilisateur, durant lesquels l’utilisateur final
ou le client consulte les changements apportés par l’équipe. Suite à cela,
il vérifie et accepte ces changements avant de les mettre dans
l’environnement de production.
• Les tests non fonctionnels : ils visent à déterminer les
performances et l’endurance du système, sa fiabilité et sa
stabilité dans des conditions de charge de travail variables.
• Les tests de maintenance.

16. EXEMPLE D’OUTILS DE TEST LES PLUS
UTILISÉ

17. INTÉGRATION CONTINUE (CONTINUOUS
INTEGRATION)
• La meilleure façon de comprendre ce concept est de décortiquer son
nom. La CI est avant tout continue. Cela signifie qu’il ne peut s’agir
d’un processus manuel. L’intégration signifie l’intégration du code et
l’intégration des fonctionnalités. Il s’agit du processus consistant à
combiner les mises à jour dans une base de code existant. Plus
important encore, tester ces changements afin de ne pas introduire
de nouveaux bugs. Donc pour résumer la CI est une philosophie qui
consiste à travailler avec les sources de contrôle où les changements
sont souvent. Et pour chaque changement introduit une série de tests
s’exécute pour le valider.

18. SOLUTIONS LES PLUS POPULAIRES

19. LIVRAISON CONTINUE (CONTINUOUS
DELIVERY)
• Se base sur l’intégration continue, ou chaque changement
devient candidat d’être en production. Un pipeline d’intégration
évalue le code, pour qu’ensuite on pourra potentiellement le
déployer chez les clients.

20. DÉPLOIEMENT CONTINUE (CONTINUOUS
DEPLOYMENT)
• Ce n’est que la livraison
continue avec plus
d’automatisation. Les
utilisateurs finaux en
production reçoivent
directement les
changements apportés au
code. Il n’y a aucune
intervention humaine. Seuls
les tests ratés peuvent
empêcher une nouvelle
modification d’être mise en
production.

21. MONITORING CONTINUE (CONTINUS
MONITORING)
• Un processus automatisé par lequel le personnel DevOps peut
observer et détecter les problèmes de conformité et les
menaces pour la sécurité au cours de chaque phase du pipeline
DevOps. Il aide les équipes ou les organisations à surveiller,
détecter et étudier les principales mesures pertinentes, et à
trouver des moyens de résoudre les problèmes en temps réel.

22. Le continus monitoring se faite à trois niveaux différents :
• Monitoring de l’infrastructure : surveille et gère l’infrastructure informatique
nécessaire à la fourniture de produits et de services. Cela comprend les data
centers, les réseaux, le matériel, les logiciels, les serveurs, le stockage, etc.
La surveillance de l’infrastructure rassemble et examine les données de
l’écosystème informatique afin d’améliorer autant que possible les
performances des produits.
• Monitoring des applications : surveille les performances du logiciel publié en
se basant sur des mesures telles que le temps de fonctionnement, le temps
et le volume des transactions, les réponses du système, les réponses de
l’API et la stabilité générale du backend et du frontend.
• Monitoring du réseau : Surveille et suit l’activité du réseau, notamment l’état
et le fonctionnement des pare-feu, des routeurs, des commutateurs, des
serveurs, des machines virtuelles, etc. La surveillance du réseau détecte les
problèmes éventuels et actuels et alerte le personnel concerné. Son objectif
principal est de prévenir les temps d’arrêt et les pannes du réseau.

23. CONTENEURISATION
• Se définit comme une forme de virtualisation du système
d’exploitation, par laquelle l’application s’execute dans un espace
utilisateur isolé du système hôte (OS) appelé conteneur. Un conteneur
est essentiellement un environnement informatique entièrement
packagé et portable. Tout ce dont une application a besoin pour
fonctionner (ses binaires, bibliothèques, fichiers de configuration et
dépendances … etc.) est encapsulé et isolé dans son conteneur.
• La plupart du temps chaque micro-service est dans un container. Ce
qui donne une indépendance totale vis-à-vis de la machine sur
laquelle ils tournent.

24. OUTILS LES PLUS UTILISÉS
Il est le plus connu

25. ORCHESTRATION DE CONTAINER
• L’orchestration des conteneurs automatise le déploiement, la
gestion, la mise à l’échelle, l’équilibrage de charge entre les
micro-services, le monitoring et la configuration réseau des
conteneurs.
• L’orchestration de conteneurs peut être utilisée dans tout
environnement où vous utilisez des conteneurs. Elle peut vous
aider à déployer la même application dans différents
environnements sans avoir à la reconcevoir.

26. OUTILS UTILISÉS
Le plus connu

27. PROCESSUS
DEVOPS

28. Le processus DevOps résume l’utilisation des pratiques et outils DevOps par les étapes suivantes :
• Planifier : au début d’un projet, d’un sprint/itération ou d’une journée on fait la planification la
hiérarchisation. Cela permet de s’assurer que tous les membres de l’équipe comprennent les objectifs
actuels et de définir le travail attendu.
• Coder : les développeurs créent et soumettent des modifications ou des ajouts au code qui répondent
aux tâches définies pour l’itération en cours. Cette étape comprend également la révision du code et
les clarifications ou ajustements nécessaires.
• Build : compilation, test et mise en package du code soumis au VSC.
• Tester : les builds réussis sont soumis à une série de tests pour garantir la fonctionnalité, la qualité et
souvent la sécurité. Idéalement, les tests les plus rapides ou les plus critiques sont effectués en
premier. De cette façon, si un test échoue, la modification du code à l’origine de l’échec peut être
renvoyée aux développeurs instantanément, et moins d’efforts seront gaspillés. Si tous les tests
réussissent, le build est transmis à la livraison et les modifications sont fusionnées dans la branche de
code principale. Cela garantit que tous les développeurs continuent à travailler à partir de la même
base.
• Livrer : on conserve la dernière version réussie est conservée et mise à disposition pour le
déploiement.
• Déployer : un build peut être déployé dans un environnement de test pour des tests supplémentaires
(ex : tests d’acceptation par l’utilisateur). Il peut également être livré à des environnements de
production ou de mise à disposition pour le déploiement.
• Opérer/configurer l’infrastructure : Les Ops construisent ou maintiennent une infrastructure évolutive,
en utilisant l’IaC et vérifient les problèmes de sécurité en plus de la gestion des journaux.

30. CONCLUSION

31. •DevOps est avant tout une question d’individus
et de culture. Si on ne travaille pas sur cet
aspect de la manière appropriée, on ne peut
rien accomplir de spécial. L’objectif principal
est de permettre aux personnes et aux équipes
de ressentir le confort de pouvoir ajouter de la
valeur à l’organisation d’une manière innovante
sans se soucier d’avoir tort ou de faire des
erreurs. Il s’agit d’une culture
d’expérimentation et d’apprentissage continu.

32. MERCI DE M’AVOIR
ÉCOUTÉ