Processus Unifiés et Méthodologies Agile

Cours 4 - Devops

Hamdi Bouslah
[Link]@[Link]
[Link]
1
 Introduction
Toute entreprise doit être capable de détecter et répondre à un besoin, de changer rapidement et en toute confiance.
Elle doit être capable d’optimiser sa vitesse de livraison d’un produit ou service.
Toutes les étapes de l’identification d’une opportunité à la réalisation des premiers bénéfices doivent être optimisées.
Toute entreprise doit réduire le temps de mise à disposition (lead time) de ses produits ou services.

Décision de Conception et
financement mise en œuvre Déploiement

Identification de Validation de la Réalisation des

Planification et
l’opportunité solution bénéfices
Analyse

2
[Link]
 Introduction
Attention au Time to Market

Les entreprises doivent être capable de moderniser leurs processus de gestion de projet

3
[Link]
 DEVOPS A qui ?
DevOps est une démarche de collaboration agile entre :

➢ Les études & développement

➢ La production, l’exploitation et l’infrastructure
➢ Les métiers, le business.

DevOps permet à une entreprise d’optimiser la rapidité de livraison d’un produit ou d’un service, en toute
sérénité et en toute confiance qu’en à sa qualité.
DevOps est donc l’extension des principes agiles à toute la chaine de valeur produit.

I want I want
Change ! Stability

Développement Opérations

4
[Link]
 DEVOPS Principes ?

➢ Réduire le délai de mise en production, de mise en ligne, de mise sur le marché du produit
➢ Mieux gérer les mises en production et la stabilité du SI
➢ Améliorer la qualité de service pour les utilisateurs finaux.

5
[Link]
 Historique
Raconté par Damon Edwards
Source texte : The Incredible True Story of How DevOps Got Its Name – Fredric Paul dans Newsrelic
Source illustration : What Is DevOps ? – Damon Edwards dans [Link]

2007 : Lors d’une migration de données pour le gouvernement Belge, Patrick Debois – administrateur
système et consultant – subit et se frustre des relations entre les développeurs et les administrateurs
systèmes et réseaux. Il s’interroge sur les solutions.

Août 2008 : Lors de la conférence Agile de Toronto, le développeur Andrew Shafer propose une
conférence « Agile Infrastructure » : Patrick Debois sera le seul présent dans la salle. Andrew Shafer ne se
rendra finalement pas à sa propre conférence, et Patrick Debois décide d’avoir malgré tout une
conversation entre 2 portes sur le sujet avec lui. Suite à leur entretien, ils forment « Agile Systems
Administration Group ».

Juin 2009 : Lors du velocity O’Reilly, John Allspaw et Paul Hammond donneront une conférence : 10+
Deploys a Day: Dev and Ops Cooperation at Flickr. Une conférence – devenue célèbre- sous forme de
retour d’expérience, à travers le projet FlickR, vantant les bénéfices productifs de la collaboration entre les
Dev et les Ops. Patrick Debois n’ayant pas pu assister à la conférence s’en lamente sur Twitter . Paul Nasrat
lui retweet : « Why not organize your own Velocity event in Belgium? »
6
[Link]
 Historique
Octobre 2009 : L’idée est lancée, l’événement s’organise. Mais tout d’abord il lui faut un nom : Patrick
Debois décide de prendre les 3 premières lettres du développement et des opérations (operationnals =
admin’ sys’), et rajoute le mot « jours » : la conférence « DevOpsDays » est née. Cette conférence du 30
octobre prend une dimension impressionnante : malgré la fin de l’événement la conversation se
poursuit sur Twitter autour du hastag #DevOps. Le mouvement DevOps est officiellement lancé.
Lors d’une interview Patrick Debois avoue qu’il n’avait pas planifié que le mouvement s’appellerait
DevOps mais qu’il avait choisi ce terme car « Agile Administration System » était trop long. “There never
was a grand plan for DevOps as a word.”

Aujourd’hui : Le mouvement DevOps a pris de l’ampleur, et ne cesse de croitre. Cette nouvelle façon
d’envisager le travail commence à s’étendre aux organisations de la rigueur … Et plus d’une trentaine de
conférence #DevOpsDays ont déjà été organisées dans le monde, et cela n’est pas prêt de s’arrêter.

7
[Link]
 Donc ? Finalement c’est quoi Devops
Les contraintes business ont évolué d’une telle manière que les utilisateurs veulent les nouvelles
fonctionnalités très rapidement. Avec l’intégration et la livraison continue les développeurs font de
nouvelles releases chaque jour. Il n’y a plus de jour « J » pour délivrer le produit comme auparavant.
Les Ops ne peuvent plus prendre des jours pour déployer des fonctionnalités une fois qu’elles ont été
testées, néanmoins ils doivent maintenir la stabilité.

DevOps et ses pratiques visent à mettre fin à cette bataille entre Dév et Ops – pour parvenir à l’équilibre
entre l’innovation et la stabilité. Dev et Ops doivent comprendre les bénéfices des paradigmes DevOps.
Ils ont besoin de changer juste assez pour commencer à travailler ensemble et à trouver le bon
alignement entre Dev et Ops dont leur organisation a besoin, et de s’améliorer à partir de là.

8
[Link]
CD, CI , CP & Devops

9
[Link]
 Intégration Continue
• L’Intégration continue est une pratique consistant à intégrer de façon continuelle les changements apportés
à un projet, et à les tester au moins une fois par jour voire plus. En règle générale, chacun des membres
d’une équipe intègre son travail au moins une fois par jour. Ainsi, chaque jour, de nombreuses intégrations
sont effectuées.
• Chaque intégration est vérifiée et testée par un build automatisé, afin de détecter les erreurs d’intégration
le plus rapidement possible. Cette approche permet généralement de réduire le nombre de problèmes
d’intégration, et permet à une équipe de développer son logiciel plus rapidement.

• En effet, l’automatisation des processus de build, de test et de déploiement simplifie fortement le

développement. Le fait d’intégrer les changements plus fréquemment permet aussi de détecter les erreurs
plus rapidement, afin d’éviter les mauvaises surprises qui peuvent survenir à cause d’une erreur commise
plusieurs mois auparavant.

10
[Link]
Intégration Continue

[Link]
11 11
 Déploiement Continue
• Le déploiement continu (Continuous Deployment) et la livraison continue (Continuous Delivery)
sont des pratiques directement liées à l’intégration continue. La livraison continue à
automatiser le processus de ” relaxe ” des changements apportés au logiciel auprès des
utilisateurs. Il est possible de choisir de livrer les changements de façon quotidienne,
hebdomadaire, ou autre fréquence en fonction des besoins propres à l’entreprise et à sa
clientèle.
• Le déploiement continu va encore plus loin, et consiste à livrer chaque changement apporté au
logiciel à la clientèle. Dans ce cas de figure, il n’y a pas d’intervention humaine. Les seuls
changements qui ne sont pas déployés sont ceux qui échouent à un test

12
[Link]
[Link]
13 13
 Outils à mettre en place
L’intégration continue nécessite la mise en place d’un certain nombre d’outils :

• Logiciels de gestion de version du code source (Subversion, Git, CVS...) Ces outils
permettent de partager le code source entre développeurs.
• Outils d’automatisation de la compilation et génération du projet (Maven, Ant..)
• Serveur d’intégration continue (Bambo, Jenkins, Tinderbox...)
• Outils de tests de la qualité du code (SonarQube)
• Mise en place de tests unitaires et fonctionnels (JUnit, etc )
• Repository Manager (Nexus)

14
[Link]
 Jenkins (1)
Jenkins est un serveur d’intégration continue très populaire (surtout pour les projets
développés en java à l’aide du moteur de construction Maven, bien qu’il fasse l’affaire
pour de très nombreux autres langages...). Il s’appelait autrefois Hudson
enkins possède deux rôles principaux :

Lancer des compilations et tests de projets logiciels, et ce de manière continue

Gérer des exécutions d’autres tâches externes (par exemple, pour nous, SonarQube !)

[Link]
15 15
 Jenkins (2)
Actions

Nodes

Jobs

16
[Link]
 Jenkins (3)

• Monitoring
• Continuous Integration Server
• Integrates building, unit tests, code coverage,analysis
• Provides the ability to hook in almost any output.
• Gives instant knowledge of status of builds.
• Provides dashboard like integration for multiple projects
• Build status
• Jenkins ne propose pas moins de 600 plugins pour étendre
ses capacités et les adapter aux besoins de chacun. Comme
pour SonarQube, il convient de choisir ceux qui
correspondent le plus aux besoins du projet

17
[Link]
 Maven : qu’est-ce que c’est ?

• Apache Maven 2 est un outil dont la version officielle a été lancée fin 2005.
• Maven a été créé dans le but de rendre fonctionner les différents outils
Apache avec le même principe. (unifier les méthodes de build, de
déploiement..)
• En fait, Maven est une combinaison d'idées, normes et de scripts.
• Il peut être vu comme:

• Un framework d'administration et de compréhension de projet

• Un outil de build
• Un outil de gestion de dépendances
• Gestion des tests

18
[Link]
 SonarQube & SonarLint

Sonar utilise un certain nombre de plugins Maven (Checkstyle, PMD, FindBugs, Cobertura ou Clover, et d’autres) pour
analyser des projets Maven et générer un ensemble complet de rapports sur la qualité du code.

Ses rapports présentent la couverture du code, le respect des règles, et la documentation, mais aussi sur des mesures
de plus haut niveau comme la complexité, la maintenabilité et même la dette technique

SonarLint est un plugin permettant de réaliser les analyse de code SonarQube au fil des développements, directement
dans l’IDE. Un bon coup de pouce pour identifier au plus tôt, c’est-à-dire avant même le commit, les points à corriger. De
ce fait, le coût de la qualité du code est extrêmement réduit, voire invisible, à l’inverse des lourdes campagnes
correctives qui interviennent sur du code déjà mergé depuis longtemps.

19
[Link]
 Qu’est ce que Checkstyle ?

• Checkstyle est un outil de contrôle de code, utilisé en

développement de logiciel. Il permet de vérifier le style
d'un code source écrit en langage Java.
• Les vérifications de Checkstyle portent essentiellement sur la
forme et ne permettent en rien de dire qu'un programme est
correct ou complet.
• En pratique, il est très fastidieux de respecter l'ensemble de
toutes les contraintes de style que l'on peut imposer au travers
de checkstyle. Ces contraintes peuvent par ailleurs nuire à la
dynamique des étapes de programmation. Il s'agit donc de
déterminer, selon le type du développement et la qualité que l'on
attend, quel doit être le niveau de vérification.

• Checkstyle définit un ensemble de modules contenant

des règles que l'on peut configurer de façon plus ou
moins stricte.
• Chaque règle peut se traduire, selon le cas, par une
notification, un avertissement ou par une erreur.
20
[Link]
 Modules de Checkstyle

• Checkstyle permet, par exemple, de vérifier :

• la présence de commentaires Javadoc pour les classes, les attributs et les méthodes
• les conventions de nommage des attributs et des méthodes
• une limitation du nombre de paramètres de méthodes, la longueur des lignes, etc.
• la présence d'en-têtes obligatoires
• l'utilisation des importations de paquets, de classes, des modificateurs de portée et des blocs d'instructions
• l'espacement entre certains caractères
• les bonnes pratiques d'écriture de classe
• les sections de code dupliqué
• diverses mesures de complexité, notamment des expressions

21
[Link]
 Checkstyle avec Eclipse

Eclipse > help > marketplace

Eclipse > window > preferences

22
[Link]
 PMD static analysis tool

PMD est un Framework qui permet d'analyser le code source Java. Il contient un certain nombre de
règles qui assurent la qualité de code : le code inutile, les imbrications trop complexes… Il permet
d'obtenir le résultat par le biais d'un rapport.
Son utilisation peut être automatisée au travers du moteur de
production comme Ant, Maven et Gradle1. PMD s'intègre également dans différents IDE Java
comme Eclipse, IntelliJ et NetBeans.
PMD apporte une série d'outils complémentaires :

• un détecteur de code dupliqué par copier-coller appelé CPD (qui supporte d'autre langages que Java
tel PHP, Ruby, ou encore le Fortran) ;
• un analyseur de flux de données
• un détecteur de code mort.

23
[Link]
 Findbugs

FindBugs a été créé par William Pugh à l'université du Maryland

FindBugs prend en entrée les fichiers .class à analyser et leur applique l'un après l'autre les
détecteurs provenant des plugins. Chaque détecteur parcourt le bytecode Java et émet un
avertissement lorsqu'il rencontre un ensemble d'instructions qui pourrait correspondre à un bug.

Les avertissements sont collectés par FindBugs pour être présentés à l'utilisateur lorsque tous les
détecteurs auront été exécutés. L'utilisateur pourra ensuite examiner le rapport de bug pour
vérifier manuellement s'il y a bien un bug et le corriger si besoin.

24
[Link]
 Five Principles of Continuous Integration

• Environments based on stability

• Maintain a code repository
• Commit frequently and build every commit
• Make the build self-testing
• Store every build

25
[Link]
 Embrace Continuous Integration

• Integration server monitors source repository

• Rebuilds with every change
• Runs all unit and acceptance tests
• Publishes build results
• Notifies developers if build breaks
• Labels successful builds in source repository

26
[Link]
 Practices of Continuous Integration

• Maintain a single source repository.

• Automate the build (nightly builds)
• Make your build self-testing
• Everyone commits every day (at least!)
• Every commit should build the mainline on an integration machine
• Keep the build fast
• Test in a clone of the production environment
• Make it easy for anyone to get the latest executable
• Everyone can see what's happening
• Automate deployment (in UOC it could allow carry out the execution of the whole workflow of an
installation in PRO)

27
[Link]
 Quand est ce qu’on parle d’un “Successful Build”?

• Quand il compile
• Quand Tous les tests unitaires sont exécutés
• Quand il est déployé

• Chaque échec de build est un succès → détection en avance d’un problème potentiel

28
[Link]
 Technique Devops

➢ Amélioration continue ;
➢ Planification des versions ;
➢ Intégration continue ;
➢ Livraison continue ;
➢ Test continus ;
➢ Surveillance et retours continus.

[Link]
29 29