Vous êtes sur la page 1sur 203

Notre vocation,

votre réussite

FORMATIONS ORSYS

V OT R E S U P P O RT D E C O U R S

Séminaires
Cours de synthèse
Stages pratiques
Certifications
Cycles certifiants
e-Learning

www.orsys.com - info@orsys.fr
tél : +33 (0)1 49 07 73 73
La Grande Arche, Paroi Nord, 92044 Paris La Défense
Ce support pédagogique vous est remis dans le cadre d’une formation organisée
par ORSYS. Il est la propriété exclusive de son créateur et des personnes bénéfi-
ciant d’un droit d’usage. Sans autorisation explicite du propriétaire, il est interdit
de diffuser ce support pédagogique, de le modifier, de l’utiliser dans un contexte
professionnel ou à des fins commerciales. Il est strictement réservé à votre
usage privé.
Open Source : outils DevOps

V18-10

1
Contenu
A FAIRE EN COURS FAIT

Automatisation Culture/Partage
Accompagner l’évolution : les
Les choix d’architecture approches possibles
La gestion des exigences produit Adapter la gouvernance : passer
et les outils associés d’une structure mécanique à une
La gestion des environnements et structure innovante
les outils associés Constituer des équipes
La gestion de version et les outils pluridisciplinaires et mettre en
associés place l’apprentissage continu

L’intégration continue et les outils Les différents stades de maturité


associés d’une équipe

Le déploiement continu et les L’engagement de tous : le vrai


outils associés défi pour les managers

L’automatisation des tests et les Faire évoluer les postures


outils associés
Ateliers pratiques
Synthèse
Orchestration de Release

Ateliers de mise en pratique

Mesure
Les fondamentaux
Le passage à l’échelle 2 11/2/2018

2
3. Automatisation – Introduction

Pourquoi l’automatisation ? (1/2)

 « How long would it take your organization to deploy a change that


involves just one single line of code? Do you deploy changes at this
pace on a repeatable , reliable basis? »
- Mary et Tom Poppendieck

 « In the new world, it’s not the BIG that is eating the SMALL …it’s
the FAST that is eating the SLOW »
- Jason Jennings – Laurence Haugthon

Objectif :
Automatiser toutes les tâches répétitives (à faible valeur
ajoutée) sur l’ensemble de la chaîne de production
logicielle
3

3
3. Automatisation – Introduction

Pourquoi l’automatisation ? (2/2)


Market Value Pain
Agile/DevOps

Traditional

Time between
actions

Product Code Gros changement peu fréquent


in production TTR élévé (Time to Repair)

Value

Petits changements fréquents


Feedbacks Faible TTR (Time to Repair)

Time

4
3. Automatisation – Introduction

Automatiser sur tout le cycle de vie du produit…

 Gestion du projet/produit  Upgrade de version


 Fabrication et Déploiement  change et roll - back …et sur l’ensemble de la
initial
 Activation/Désactivation
stack applicative
 Opérations courantes de fonctionnalités
 Supervision ,  Feature Toggle (Flipping) Application & Data
investigations/diagnostiques,
correctifs,  Dé commissionnement Platform
 Upgrades capacitaires, migration
(fin de vie) (OS, Middleware)
technique…
Infrastructure
 Backup&Restore, DRP… (Compute HW)

•network (LAN, LB, FW)


•compute (x86) and storage (block, file)
•OS (e.g. RHEL / Ubuntu)
•Middleware (JVM, PHP, Python)
•Application binaries (Java, PHP, …)
•State/Data (RDBMS, NoSQL)
•Managed Services subcriptions
•messaging, file transfert, identity
•APIs
•CDN, Object storage
•Analytics
•DNS, PKI
•….
3. Automatisation – Vue d’ensemble

Chaîne de production logicielle


Besoins Gestion de version Gestion de version Gestion de version Gestion de

Développement agile

Tests automatiques

Supervision/Exploitation
Déploiement continu
Product Backlog
Business/Métiers – (code source + (scripts de tests + (scripts de configuration
« Exigences conf. applicative) jdds) déploiement, conf. Changement
fonctionnelles » Tests d’assemblage système )
(FR, User stories) Monitoring
Intégration Tests fonctionnels Tests d’exploitation
Incident/Problème
continue Tests de Tests vitaux
« Exigences non performance
fonctionnelles » A/B Testing
(NFR, Technical Tests unitaires Tests de robustesse Canary Release
stories) Tests d’endurance Toggle Feature
Feedbacks
Analyse de code utilisateurs
Evolutions statique Release On continus
techniques Demand

Bug fixing Gestion des infrastructures/environnements


Orchestration de Release
Sécurité
Gestion de projet/produit bout en bout

Feedbacks continus MESURE MESURE MESURE


6

6
Contenu
A FAIRE EN COURS FAIT

Automatisation

Les choix d’architectures

La gestion des exigences produit


et les outils associés
La gestion des environnements et
les outils associés
La gestion de version et les outils
associés
L’intégration continue et les outils
associés

Le déploiement continu et les


outils associés

L’automatisation des tests et les


outils associés

Synthèse
Orchestration de Release

Ateliers de mise en pratique


Culture/Partage
Mesure
Les fondamentaux
Le passage à l’échelle 7 11/2/2018

7
3. Automatisation – Choix d’architecture

Les choix d’architectures


Architecture logicielle Architecture technique Infrastructure

Application Serveurs physiques Datacenters


Monolithique

Serveurs virtuels Hébergeurs


Application
3-tiers (SOA)

Containers Cloud
Application (On or Off Premise)
Micro - services

8
3. Automatisation – Choix d’architecture

Du monolithe aux micro – services (1/2)

PC or Mobile Mobile App


PC or Mobile Mobile App
Browswer - WebApp
Browswer - WebApp
Support Support
http (REST/JSON)

Présentation

API Gateway

Service

cv [.(j,e,w)ar] [.(j,e,w)ar] [.(j,e,w)ar]

Données

1 bloc [.(j,e,w)ar] unique à déployer


Inventory/Discovery/Routing
Monitoring [.(j,e,w)ar]
Orchestration/Configuration
9

Build applications as a set of small services that communicates with other services
through APIs

9
3. Automatisation – Choix d’architecture

Du monolithe aux micro – services (2/2)

10

10
3. Automatisation – Choix d’architecture

de la virtualisation aux containers (1/2)

App App App


A A A A
p p p p
Bin/lib Bin/Lib Bin/lib p p p p Espace
disponible
Guest Guest Guest
Bin/ Bin Bin Bin
OS OS OS lib /lib /lib /lib
VM VM VM
App
Container Engine

OS Hyperviseur OS

Architecture physique Architecture virtualisée Architecture containérisée


11

11
3. Automatisation – Choix d’architecture

de la virtualisation aux containers (2/2)


* slogan de docker.com

Packager une application et ses dépendances


Build dans un container

Ship Déplacer ce container d’une machine à une autre

Run Lancer le container, c.-à-d. l’application qu’il


contient

Any App Tout ce qui peut tourner sous linux  Transformer une application en un ou
plusieurs conteners est simple.
 Mettre en œuvre l’écosystème permettant de
que ce soit sur une VM locale, du baremetal ou
gérer une application multi containers est
Anywhere une instance de cloud plus difficile :
 Orchestration, Clustering, Management,
Monitoring…
 Kubernetes (google), Mesos, Marathon…
 Docker Suite : Machine, Compose, Swarm, …UCP
12

12
IaaS, PaaS et SaaS

https://www.youtube.com/watch?v=VdeaxRR-
Mtc
https://www.youtube.com/watch?v=_sEvGnO8
Pr8

13

13
3. Automatisation – Choix d’architecture

Du datacenter au cloud (1/3)

https://www.itsmonkie.co.uk/choose-saas-paas-iaas-premise/

14

14
3. Automatisation – Choix d’architecture

Du datacenter au cloud (2/3)

Source : http://akioz.com/saas-architecture-ppt/

 Cloud : Public, Privé, Hybride 15

15
3. Automatisation – Choix d’architecture

Du datacenter au cloud (3/3)


 Pour aller dans le Cloud, 12 facteurs pour que votre application soit « Cloud Ready »

 I. Base de code  VII. Associations de ports


 Une base de code suivie avec un système de  Exportez les services via des associations de ports
contrôle de version, plusieurs déploiements  VIII. Concurrence
 II. Dépendances  Evoluer à l’aide du modèle de processus
 Déclarez explicitement et isolez les dépendances  IX. Jetable
 III. Configuration  Maximisez la robustesse avec des démarrages rapides
 Stockez la configuration dans l’environnement et des arrêts en douceur

 IV. Services externes  X. Parité dev/prod


 Traitez les services externes comme des ressources  Gardez le développement, la validation et la
liées production aussi proches que possible

 V. Build, release, run  XI. Logs


 Séparez strictement les étapes d’assemblage et  Traitez les logs comme des flux d’évènements
d’exécution  XII. Processus d’administration
 VI. Processus  Lancez les tâches d’administration et de maintenance
 Exécutez l’application comme un ou plusieurs comme des processus à part entière
processus sans état

https://12factor.net/fr/
16

16
3. Automatisation – Choix d’architecture

Les choix d’architecture


 Savoir d’où l’on part et où l’on souhaite aller
 Faire ces choix en tenant compte des besoins et contraintes de chacun
 Communiquer pour partager

CAS #1 Architecture logicielle Architecture technique Infrastructure


Monolithe 3 tiers – Micro – Serveurs VMs Containers DC Hébergeur Cloud
Modulaire services physiques en propre (Serveurs, (IaaS, PaaS,
VM) SaaS)
ACTUEL x x x

CIBLE x x x

CAS #2 Architecture logicielle Architecture technique Infrastructure


Monolithe 3 tiers – Micro – Serveurs VMs Containers DC Hébergeur Cloud
Modulaire services physiques en propre (Serveurs, (IaaS, PaaS,
VMs) SaaS)
ACTUEL x x x

CIBLE x x x (IaaS)
17

17
Contenu
A FAIRE EN COURS FAIT

Automatisation

Les choix d’architectures

La gestion des exigences produit


et les outils associés
La gestion des environnements et
les outils associés
La gestion de version et les outils
associés
L’intégration continue et les outils
associés

Le déploiement continu et les


outils associés

L’automatisation des tests et les


outils associés

Synthèse
Orchestration de Release

Ateliers de mise en pratique


Culture/Partage
Mesure
Les fondamentaux
Le passage à l’échelle 18 11/2/2018

18
3. Automatisation – Vue d’ensemble

Chaîne de production logicielle (rappel)


Besoins Gestion de version Gestion de version Gestion de version Gestion de

Développement agile

Tests automatiques

Supervision/Exploitation
Déploiement continu
Product Backlog
Business/Métiers – (code source + (scripts de tests + (scripts de configuration
« Exigences conf. applicative) jdds) déploiement, conf. Changement
fonctionnelles » Tests d’assemblage système )
(FR, User stories) Monitoring
Intégration Tests fonctionnels Tests d’exploitation
Incident/Problème
continue Tests de Tests vitaux
« Exigences non performance
fonctionnelles » A/B Testing
(NFR, Technical Tests unitaires Tests de robustesse Canary Release
stories) Tests d’endurance Toggle Feature
Feedbacks
Analyse de code utilisateurs
Evolutions statique Release On continus
techniques Demand

Bug fixing Gestion des infrastructures/environnements


Orchestration de Release
Sécurité
Gestion de projet/produit bout en bout

Feedbacks continus MESURE MESURE MESURE


19

19
3. Automatisation - Gestion des exigences

La gestion des exigences produit : Backlog Produit


Backlog  Backlog Produit :
du produit  Liste des besoins/fonctionnalités à
réaliser, collectés et gérés par le Product
Owner
Backlog
 affiné et actualisé au fil de l’eau (Backlog
de Release Refinement)
 Chaque besoin est décrit par une Story
Backlog ou traduit dans la Definition of Done
(DoD).
de Sprint
 Ces besoins sont :
 prioriséss par la valeur qu’elle apporte
I ndépendante (MoSCoW : Must Should Could Won’t,
Cost of Delay),
N égociable  sélectionnées à chaque itération pour
constituer le Backlog de Sprint lors du
V aleur ajoutée
Sprint Planning.
stimable  Le Product Owner gère les aspects
E fonctionnels et non fonctionnels; il
S uffisamment petite exprime des besoins.
 L’équipe pluri – disciplinaire de
T estable
réalisation gère sur les aspects
techniques et les tâches associées; elle
apporte des solutions.
20

20
3. Automatisation - Gestion des exigences

La gestion des exigences produit : Stories (1/2)


 Stories
 User Story ➔ Fonctionnalités pour les différents utilisateurs du produit
 Technical/Enabler Story ➔ Evolutions techniques
 Story Bug ➔ anomalies / incidents
 Spyke ➔ étude/analyse
 La User Story exprime un besoin et non une solution
 en tant que <rôle>, je veux <action> afin que <but/ objectif/ valeur>
 Chaque User Story :
 est découpée pour pouvoir être développée en un sprint
 a une valeur business (10, 20, 30, …)
 est estimée lors du « Pocker planning»
 en points de complexité relative « Story Points » (Fibonacci : 1,2,3,5,8,13,21…)
 ou en « ideal days » (1 « ideal day » = ~ 6h)
 contient les critères d’acceptation (cas de succès/échec)
 si <pre – condition>, lorsque <évènement : acteur+action> alors <résultats obtenu/attendu>
 a un état
 specified, to rework, in progress, to test, done (Definition of Done)

21

21
3. Automatisation - Gestion des exigences

La gestion des exigences produit : DoD (2/2)

 DoD : peut servir à exprimer les Exigences Non Fonctionnelles (ENF ou NFR :
Non Functional Requirements )
 Réglementaire
 Accessibilité, Ergonomie
 Exploitation
 Installation / désinstallation , Compatibilité ascendante, Sauvegarde et Restauration, Portabilité,
Maintenabilité
 Mesurabilité, Performances
 Disponibilité, Scalabilité, Fiabilité, Robustesse
 Supervision
 Sécurité
▫ Traçabilité,
▫ Identification/Authentification utilisateurs et administrateurs,
▫ Imputabilité, Non répudiation,
▫ Intégrité des données, Confidentialité des données,
▫ …

22

22
3. Automatisation - Gestion des exigences

La gestion des exigences produit : les outils associés


(1/2)

23

23
3. Automatisation - Gestion des exigences

La gestion des exigences

 Trello

24

24
Trello

https://www.youtube.com/watch?v=DqmXYPN
rHcw

25

25
3. Automatisation - Gestion des exigences

La gestion des exigences produit : les outils associés


(2/2)

26

26
Liens utiles

- Flowdock : https://www.youtube.com/watch?v=0zrX0cgNTAc
- Taiga : https://www.youtube.com/watch?v=495RFM7U0Yg
- Wekan : https://www.youtube.com/watch?v=N3iMLwCNOro

27

27
3. Automatisation - Gestion des exigences

La gestion des communications : Slack

28

28
3. Automatisation - Gestion des exigences

La gestion des communications

- Slack : https://www.youtube.com/watch?v=QRLR1crxZo0
- Hipchat : https://www.youtube.com/watch?v=W0P_wPXWy6I
- Rocket chat : https://www.youtube.com/watch?v=T2v29gK8fP4

29

29
3. Automatisation – Vue d’ensemble

Chaîne de production logicielle (rappel)


Besoins Gestion de version Gestion de version Gestion de version Gestion de

Développement agile

Tests automatiques

Supervision/Exploitation
Déploiement continu
Product Backlog
Business/Métiers – (code source + (scripts de tests + (scripts de configuration
« Exigences conf. applicative) jdds) déploiement, conf. Changement
fonctionnelles » Tests d’assemblage système )
(FR, User stories) Monitoring
Intégration Tests fonctionnels Tests d’exploitation
Incident/Problème
continue Tests de Tests vitaux
« Exigences non performance
fonctionnelles » A/B Testing
(NFR, Technical Tests unitaires Tests de robustesse Canary Release
stories) Tests d’endurance Toggle Feature -
Release On Feedbacks
Analyse de code utilisateurs
statique Demand
Evolutions continus
techniques

Bug fixing Gestion des infrastructures/environnements


Orchestration de Release
Sécurité
Gestion de projet/produit bout en bout

Feedbacks continus MESURE MESURE MESURE


30

30
Contenu
A FAIRE EN COURS FAIT

Automatisation

Les choix d’architectures

La gestion des exigences produit


et les outils associés
La gestion des environnements et
les outils associés
La gestion de version et les outils
associés
L’intégration continue et les outils
associés

Le déploiement continu et les


outils associés

L’automatisation des tests et les


outils associés

Synthèse
Orchestration de Release

Ateliers de mise en pratique


Culture/Partage
Mesure
Les fondamentaux
Le passage à l’échelle 31 11/2/2018

31
3. Automatisation - Gestion des environnements

Infrastructure As Code (IaC)

 Créer et maintenir des environnements homogènes et iso Prod


 « Scripter » la création d’env. (mise à disposition d’API, natif dans le
cloud), Scale up/down
 Compute, Storage, Network

 Les configurer et les administrer en utilisant des pratiques issues du


développement (gestion de version pour le suivi des modifications, intégration
continue, tests automatiques, déploiement continu)
 Configuration de l’OS (inc. sécurité, …)

 Configuration des Produits logiciels d’Infrastructure (MW, AS, WS, logs, agents :
déploiement/ordonnancement, monitoring, …, sécurité, …)

 Standardiser et Industrialiser
 Passer d’infra mutables à des infra immutables : Pets vs Cattle.
 avec comme pré – requis la séparation du code et des données

32

32
3. Automatisation - Gestion des environnements

Configuration as Code (CaC)


Binaires

Configuration

Web Server

OS

 Gérer toutes les configurations dans Application Server

le gestionnaire de version commun


OS

aux Dev et aux Ops


Database

OS

 les modifications d'Infra se font Hors Prod (SIT/QA)


uniquement via des scripts versionnés
 la modification d’un fichier de Load Balancer

configuration applicative entraine la Web Server Web Server

révision de sa version OS OS

Load Balancer

Application Server Application Server

OS OS

Database Failover

OS OS

Production
33

33
3. Automatisation - Gestion des environnements

Iac et CaC : les outils associés


 1 outil par tiers (Infra, OS, WAS, BDD, Application,…) ?
 le plus souvent : recouvrement ➔ choix à réaliser suivant le contexte
 préférez ceux
 dont le code pourra être testé
 qui couvrent les besoins des dev et des ops,
 facilement utilisables par les deux

Bladelogic

Packer Rudder
Terraform

Consul
34

34
Contenu
A FAIRE EN COURS FAIT

Automatisation

Les choix d’architectures

La gestion des exigences produit


et les outils associés
La gestion des environnements et
les outils associés

La gestion de version et les outils


associés
L’intégration continue et les outils
associés

Le déploiement continu et les


outils associés

L’automatisation des tests et les


outils associés

Synthèse
Orchestration de Release

Ateliers de mise en pratique


Culture/Partage
Mesure
Les fondamentaux
Le passage à l’échelle 35 11/2/2018

35
3. Automatisation – Vue d’ensemble

Chaîne de production logicielle (rappel)


Besoins Gestion de version Gestion de version Gestion de version Gestion de

Développement agile

Tests automatiques

Supervision/Exploitation
Déploiement continu
Product Backlog
Business/Métiers – (code source + (scripts de tests + (scripts de configuration
« Exigences conf. applicative) jdds) déploiement, conf. Changement
fonctionnelles » système )
(FR, User stories) Monitoring
Intégration Tests d’assemblage Tests d’exploitation
Incident/Problème
continue Tests fonctionnels Tests vitaux
« Exigences non
fonctionnelles » Tests de A/B Testing
(NFR, Technical Tests unitaires performance Canary Release
stories) Tests de robustesse Toggle Feature -
Release On Feedbacks
Analyse de code Tests d’endurance utilisateurs
statique Demand
Evolutions continus
techniques

Bug fixing Gestion des infrastructures/environnements


Orchestration de Release
Sécurité
Gestion de projet/produit bout en bout

Feedbacks continus MESURE MESURE MESURE


36

36
3. Automatisation - Gestion des versions

Au commencement …

 Comment :
 synchroniser nos sources?
 gérer les conflits entre
Gestion du
fichiers?
Code
source  faciliter et automatiser les
backups?
Gestion de  restaurer facilement une
conf. version précédente d’un ou
plusieurs fichiers?

37

37
3. Automatisation - Gestion des versions

La gestion de configuration : qu’est ce que c’est ?


 Ensemble de pratiques :
 Pour identifier, stocker et tracer les différentes versions ou révisions des éléments
constitutifs d’un système durant tout son cycle de vie (de la conception à la
maintenance) ➔ activité d’inventaire (CMDB : Configuration Management
DataBase).
 les matériels
 les logiciels et applications
 les documentations associées
 Vérifier que chaque état est cohérent et complet
 Archiver chacun des états successifs (audit et reporting)
 Pour déployer des configurations à travers un parc informatique sous formes de
fichiers et données.
 3 types de releases
 baseline ➔ releases majeures, tout changement sur cette baseline se traduit par un « change
request »
 intermédiaire ➔ corriger des problèmes immédiats, apporter des modifications immédiates sans
attendre la prochaine release
 révisions ➔ changements mineurs

38

On estime que l’on passe 5 à 10 % du temps de développement à utiliser un outil de


gestion de configuration, et que l’on gagne alors 20 à 50 % du temps en phase de
maintenance

38
3. Automatisation - Gestion des versions

La gestion de configuration : comment faire ?


 Réalisé, en développement, à l'aide de logiciels de gestion de version (Version Control
System – VCS , Source Code Management - SCM, Revision Control System - RCS),
propriétaires ou « open source »
 Utilisée dans le suivi de versions de logiciels, en particulier gérer les codes sources
 Utilisée dans le suivi de versions de documents,
 tracer toutes les modifications qui sont intervenues sur les informations contenues dans les
documents.
 On estime que l’on passe 5 à 10 % du temps de développement à utiliser un outil de gestion de
configuration, et que l’on gagne alors 20 à 50 % du temps en phase de maintenance

39

On estime que l’on passe 5 à 10 % du temps de développement à utiliser un outil de


gestion de configuration, et que l’on gagne alors 20 à 50 % du temps en phase de
maintenance

39
3. Automatisation - Gestion des versions

La gestion de configuration : les étapes clés


 Définir un plan de gestion de configuration de la conception à la maintenance
 définir les éléments à gérer
 définir les conventions de nommage
 définir qui est responsable de la gestion de configuration
 définir les procédures associées (en lien avec la gestion des changements)
 choisir pour la phase de conception, un outil de gestion des versions
 gérer les modifications simultanées au sein de l’équipe de développement, les tracer, les
partager
 stratégie de gestion des branches (création, fusion, …)
 tracer les contributions et garder un historique
 permettre le backup and restore …
 assurer la cohérence avec le système de gestion de configuration en maintenance
 Configurer les postes des membres de l’équipe.

Gartner : “Implementation of a configuration management strategy will reduce


downtime by as much as 35%”
40

(IEEE 828-1990, IEEE STD 1987, IEEE 1042)


plug’in egit

40
3. Automatisation - Gestion des versions

Focus sur la gestion de versions : les outils de forge


 Centralisés

 Distribués

 Git : Conçu en 2005 pour supporter le


développement du noyau Linux
(plusieurs milliers de contributeurs)
 nativement lié au monde Unix/Linux.
 bénéficie de la meilleure couverture
médiatique, avec une très large
adoption dans le milieu open-source,
en particulier via le succès de la
plateforme GitHub.
 support sous windows (perfectible)
41

GIT :
• TortoiseGit3 apporte une appréciable intégration graphique de Git dans
l’explorateur Windows. Autre avantage, il limite la complexité et la richesse des
commandes Git et facilite donc la prise en main du néophyte.
• Perforce Visual Merge (P4Merge), une alternative à TortoiseMerge : Perforce
propose gratuitement un outil de comparaison et fusion particulièrement efficace
et ergonomique.

41
3. Automatisation - Gestion des versions

Focus sur la gestion de versions :


un rapide comparatif

https://www.slideshare.net/zahirazahira/git-70116832
https://medium.com/flow-ci/github-vs-bitbucket-vs-gitlab-vs-coding-7cf2b43888a1
42

42
3. Automatisation - Gestion des versions

Focus sur la gestion de versions : Git Flow


la gestion des branches
http://nvie.com/posts/a-successful-git-branching-model/

 Conseil#0 : à formaliser avant de démarrer


les développements
 Conseil#1 : séparer la branche-maître
(réservée aux releases) des branches de
développement et de maintenance corrective
 Conseil#2 : utiliser des feature branches
pour isoler la réalisation des items
fonctionnels.
 Une branche de ce type ne va typiquement
exister que sur les dépôts des développeurs.
 Conseil#3 : utiliser des release-branches
pour préparer une livraison.
 Conseil#4 : utiliser des branches de
correction « hotfix ».
 Une branche de ce type permet de faire face à
un problème en production et à isoler la
correction du problème détecté, sans
prendre le risque d’embarquer des
développements en cours. Une fois la version
corrective livrée, la branche corrective est
fusionnée avec les développements en cours.
43

Bien définir le workflow de gestion de conf (quelles branches pour quoi faire ?)
1 repo GIT par composant
1 story = 1 branche (locale)
1 tache de la story terminée = 1 commit

1 Feature = 1branche locale

Le repository distant a au moins 3 branches :


develop : développement en cours
release : release en cours de qualification
master : production

Des branches supplémentaires sont utilisées :


feature : développement d’une fonctionnalité
hot-fix : patch sur une version en production

43
3. Automatisation - Gestion des versions

Focus sur la gestion de versions : Git Flow


la gestion des branches

 Bien définir le workflow de gestion de conf (quelles


branches pour quoi faire ?)
 1 repo GIT par composant
 1 story = 1 branche (locale)
 1 tache de la story terminée = 1 commit

 1 Feature = 1 branche locale

 Le repository distant a au moins 3 branches :


 develop : développement en cours
 release : release en cours de qualification
 master : production

 Des branches supplémentaires sont utilisées :


 feature : développement d’une fonctionnalité
 hot-fix : patch sur une version en production
44

Bien définir le workflow de gestion de conf (quelles branches pour quoi faire ?)
1 repo GIT par composant
1 story = 1 branche (locale)
1 tache de la story terminée = 1 commit

1 Feature = 1branche locale

Le repository distant a au moins 3 branches :


develop : développement en cours
release : release en cours de qualification
master : production

Des branches supplémentaires sont utilisées :


feature : développement d’une fonctionnalité
hot-fix : patch sur une version en production

44
3. Automatisation - Gestion des versions

Et après, comment assembler les morceaux ?


 Comment :
 intégrer toutes les
modifications du code source?
 améliorer la robustesse du
code source?
 exécuter plusieurs centaines
Gestion Intégration de tests unitaires? éviter de
du Code continue tester manuellement? éviter
Source d’oublier de les exécuter?
Gestion  évaluer la quantité de code
de conf. testé?
 évaluer la qualité du code
(redondance, règles,...)?
 détecter rapidement et
répertorier les bugs (test
échoué,...)?
 assurer le suivi de la qualité?

45

45
Liens utiles

Github :
https://www.youtube.com/watch?v=XkB9EM18
W2A
Gitlab :
https://www.youtube.com/watch?v=URcMBXjI
r24
Bitbucket :
https://www.youtube.com/watch?v=7vOgKcG5
mw8
46

46
Liens utiles

GLPI :
https://www.youtube.com/watch?v=oaa-
OIDGQBM
Fusion inventory :
https://www.youtube.com/watch?v=Y4OjkthJS
sY
Spacewalk :
https://www.youtube.com/watch?v=T-
h4WbnOg_Y

47

47
Autre outil : GLPI

48

48
Contenu
A FAIRE EN COURS FAIT

Automatisation

Les choix d’architectures

La gestion des exigences produit


et les outils associés
La gestion des environnements et
les outils associés
La gestion de version et les outils
associés
L’intégration continue et les outils
associés

Le déploiement continu et les


outils associés

L’automatisation des tests et les


outils associés

Synthèse
Orchestration de Release

Ateliers de mise en pratique


Culture/Partage
Mesure
Les fondamentaux
Le passage à l’échelle 49 11/2/2018

49
3. Automatisation – Vue d’ensemble

Chaîne de production logicielle (rappel)


Besoins Gestion de version Gestion de version Gestion de version Gestion de

Développement agile

Tests automatiques

Supervision/Exploitation
Déploiement continu
Product Backlog
Business/Métiers – (code source + (scripts de tests + (scripts de configuration
« Exigences conf. applicative) jdds) déploiement, conf. Changement
fonctionnelles » système )
(FR, User stories) Monitoring
Intégration Tests d’assemblage Tests d’exploitation
Incident/Problème
continue Tests fonctionnels Tests vitaux
« Exigences non
fonctionnelles » Tests de A/B Testing
(NFR, Technical Tests unitaires performance Canary Release
stories) Tests de robustesse Toggle Feature -
Release On Feedbacks
Analyse de code Tests d’endurance utilisateurs
statique Demand
Evolutions continus
techniques

Bug fixing Gestion des infrastructures/environnements


Orchestration de Release
Sécurité
Gestion de projet/produit bout en bout

Feedbacks continus MESURE MESURE MESURE


50

50
3. Automatisation - Intégration continue

L’intégration continue : Définition


 Vérifier, à chaque modification du code
source, que le résultat des modifications
n’introduit pas de régression de
l’application en cours de développement
 pratique issue de l’eXtreme Programming
 nécessite une administration de la
plateforme d’intégration continue

Sans

Avec

http://igm.univ-mlv.fr/~dr/XPOSE2011/IntegrationContinue/pourquoi.html 51

 Avantages
 Pour le développeur : Avoir un feedback rapide sur les erreurs
et régressions causés par le commit de ses modifications.
 Pour l’équipe de réalisation : Connaître l’état de l’application à
tout moment.
 Pour la production : Savoir exactement ce qui est nécessaire
pour exécuter l’application. Le packaging et les tests ne sont
plus réalisés sur le poste du développeur mais sur
l’environnement d’intégration
 Pour le Product Owner : Disposer de nouvelles versions plus
fréquemment. Constater beaucoup moins de régressions.

Tout ce que ça demande, c’est une certaine dose de discipline. Cela prend beaucoup
d’énergie pour l’introduire dans un projet, surtout si celui-ci est bien avancé. Mais
une fois installé, l’effort de maintenance est minime.

51
3. Automatisation - Intégration continue

L’intégration continue : Avantages


 Avantages
 Pour le développeur : Avoir un feedback rapide sur les erreurs et régressions causés par le commit
de ses modifications.

 Pour l’équipe de réalisation : Connaître l’état de l’application à tout moment.

 Pour la production : Savoir exactement ce qui est nécessaire pour exécuter l’application. Le
packaging et les tests ne sont plus réalisés sur le poste du développeur mais sur l’environnement
d’intégration

 Pour le Product Owner : Disposer de nouvelles versions plus fréquemment. Constater beaucoup
moins de régressions.

 Tout ce que ça demande, c’est une certaine dose de discipline. Cela prend beaucoup d’énergie pour l’introduire dans un
projet, surtout si celui-ci est bien avancé. Mais une fois installé, l’effort de maintenance est minime.

http://igm.univ-mlv.fr/~dr/XPOSE2011/IntegrationContinue/pourquoi.html 52

52
3. Automatisation - Intégration continue

L’intégration continue : les fonctions clés


 Automatiser le workflow :
 fiabiliser, fluidifier et accélérer les processus

 de compilation,

 d’analyse de code, de tests,

 de packaging, de déploiement, de déclenchement de tests d’acceptance ...

 générer un exécutable ou une archive ➔ « versions journalières » - Nightly build


 Centraliser les informations (dév, test, ops, …) et communiquer les status.
 Historiser : conserver les productions précédentes et voir l’évolution des productions actuelles.

53

53
3. Automatisation - Intégration continue

L’intégration continue : mise en pratique


 Les pratiques sont les suivantes:

 •maintenir un dépôt unique de code source versionné;

 •automatiser les compilations;

 •rendre les compilations auto-testantes;

 •tout le monde committetous les jours;

 •tout commitdoit compiler le tronc sur une machine d'intégration;

 •maintenir une compilation courte;

 •tester dans un environnement de production cloné;

 •rendre disponible facilement le dernier exécutable;

 •tout le monde doit voir ce qui se passe;

 •automatiser le déploiement.

54

54
3. Automatisation - Intégration continue

L’intégration continue : mise en pratique


 Visibilité : L’intégration continue règle certains problèmes. Augmente le niveau de confiance de
l’équipe. Les problèmes se manifestent généralement le même jour qu’ils ont été introduits. Les
changements qui ont pu introduire le problème étant plus limités, le problème peut plus facilement
être corrigé. Un build fiable est toujours disponible

 Résultat-Productivité accrue en réduisant le temps à chercher les causes de problème

 •Les principaux avantages d'une telle technique de développement sont:

 •les problèmes d'intégration sont détectés et réparés de façon continue, évitant les problèmes de
dernière minute;

 •prévient rapidement en cas de code incompatible ou manquant;

 •test immédiat des unités modifiées;

 •une version est toujours disponible pour test, démonstration ou distribution.

 •On peut aussi implanter un déploiement automatique

55

55
3. Automatisation - Intégration continue

L’intégration continue : les outils

Compilation
Build

Autres
outils Tests
(API, unitaires
Plug’ins)
Intégration
continue

Inspection
Packaging
continue
Gestion des
Analyse de
dépôts
code

56

Chargement de la dernière version du projet depuis le gestionnaire de version


Compilation
Exécution des tests unitaires
Inspection du code (en vue de générer les métriques de qualité)
Génération de la documentation, des rapports, des notes de release (par exemple la
Javadoc, rapport Checkstyle)
Construction de la release
Déploiement de l’application sur l'environnement d’intégration
Exécution des tests d'intégration

• Build local / privé J’exécute un build sur ma machine Compilation


• Tests unitaires
• Build d’intégration : Le serveur d’intégration exécute un build
• Idem build local
• Build de nuit : Le serveur exécute un build complet
+ Tests d’intégration
• + Documentation, rapports, métriques
• + Release / Déploiement

Maven : Gestionnaire de dépendances, building

56
QUnit is a JavaScript unit testing framework. While heavily used
by the jQuery Project for testing jQuery, jQuery UI and jQuery
Mobile, it is a generic framework to test any JavaScript code. It
supports server-side (e.g. node.js) and client-side environments.

JUnit is a unit testing framework for the Java programming


language. JUnit has been important in the development of test-
driven development, and is one of a family of unit testing
frameworks which is collectively known as xUnit that originated
with SUnit.

56
Intégration continue

 Chargement de la dernière version du projet depuis le gestionnaire de


version
 Compilation
 Exécution des tests unitaires
 Inspection du code (en vue de générer les métriques de qualité)
 Génération de la documentation, des rapports, des notes de release (par
exemple la Javadoc, rapport Checkstyle)
 Construction de la release
 Déploiement de l’application sur l'environnement d’intégration
 Exécution des tests d'intégration

57

57
Intégration continue

• Build local / privé J’exécute un build sur ma machine Compilation


• Tests unitaires
• Build d’intégration : Le serveur d’intégration exécute un build
• Idem build local
• Build de nuit : Le serveur exécute un build complet
+ Tests d’intégration
• + Documentation, rapports, métriques
• + Release / Déploiement

58

58
Intégration continue

Maven : Gestionnaire de dépendances, building

 QUnit is a JavaScript unit testing framework. While heavily used by the


jQuery Project for testing jQuery, jQuery UI and jQuery Mobile, it is a
generic framework to test any JavaScript code. It supports server-side (e.g.
node.js) and client-side environments.

 JUnit is a unit testing framework for the Java programming language.


JUnit has been important in the development of test-driven development,
and is one of a family of unit testing frameworks which is collectively known
as xUnit that originated with SUnit.

59

59
3. Automatisation - Intégration continue

L’intégration continue : Un exemple, Jenkins


 Outil d’ordonnancement de jobs (build, tests, deploy,…)
 JOB (ou projet) : déclaration et configuration des outils, environnements et instructions qui vont constituer une
partie ou la totalité d’un processus automatisé.
 Ex : packager une application à partir d’un repository Git , redémarrer un service sur une machine distante via une
commande ssh
 BUILD (ou construction) : exécution d’un job

 Interfacé avec les outils de la chaine de delivery via plug’ins ou API


 Communauté très importante et très active. Beaucoup de plugins.

http://www.slideshare.net/asotobu/jenkins-20-65705621 60

Exemple de mise en œuvre :


plugin Git pour Jenkins propose de scruter non seulement
le master, mais également toutes les branches du dépôt
Git.
permet de couvrir la stabilité du code dans chaque
branche, mais pas d’anticiper la fusion dans la
branche d’intégration.
permet de mettre en place des hooks, des scripts
activés sur certains événements du SCM : création
d’une branche dans le dépôt public ➔ création d’un
job Jenkins via les API Jenkins.
permet à chaque branche de posséder son Job
d’intégration continue dédié, mais sans valider la
fusion avec la branche d’intégration et/ou les autres
branches. Un second job, dédié à valider l’intégration
peut donc s’avérer utile

60
Jenkins

61

61
Jenkins
Exemple de mise en œuvre :
plugin Git pour Jenkins propose de scruter non seulement le master, mais également
toutes les branches du dépôt Git.
permet de couvrir la stabilité du code dans chaque branche, mais pas
d’anticiper la fusion dans la branche d’intégration.
permet de mettre en place des hooks, des scripts activés sur certains
événements du SCM : création d’une branche dans le dépôt public ➔ création
d’un job Jenkins via les API Jenkins.
permet à chaque branche de posséder son Job d’intégration continue
dédié, mais sans valider la fusion avec la branche d’intégration et/ou les autres
branches. Un second job, dédié à valider l’intégration peut donc s’avérer utile

62

62
Liens utiles

 Maven : https://www.youtube.com/watch?v=4UO_Wwf8rPg
 Graddle : https://www.youtube.com/watch?v=ERu3iSmoZ2s
 TeamCity : https://www.youtube.com/watch?v=_FzdCC9imDs
 TravisCI : https://www.youtube.com/watch?v=Uft5KBimzyk
 CircleCI : https://www.youtube.com/watch?v=KhjwnTD4oec
 JUnit : https://www.youtube.com/watch?v=6wE6VhF_uNo
 PHPUnit : https://www.youtube.com/watch?v=ashfoywo9xc
 Mokito : https://www.youtube.com/watch?v=eqRF4xHoGck

63

63
Contenu
A FAIRE EN COURS FAIT

Automatisation

Les choix d’architectures

La gestion des exigences produit


et les outils associés
La gestion des environnements et
les outils associés
La gestion de version et les outils
associés
L’intégration continue et les outils
associés

Le déploiement continu et les


outils associés

L’automatisation des tests et les


outils associés

Synthèse
Orchestration de Release

Ateliers de mise en pratique


Culture/Partage
Mesure
Les fondamentaux
Le passage à l’échelle 64 11/2/2018

64
3. Automatisation - Livraison/Déploiement continu

Livraison/Déploiement continue : définitions


 Continuous delivery – Livraison continue ➔ déploiement
automatisée sur les environnements hors production (BUILD, SIT, QA
- UAT, …)
 Continuous deployment – Déploiement continu ➔ déploiement
automatisé sur les environnements de Pre – Production/Production
 Idéalement avec les mêmes outils et le même «mode opératoire (voir
aussi outils de CaC, p27)

65

Rundeck is an open-source software Job scheduler and Run Book Automation system
for automating routine processes across development and production environments.
It combines task scheduling, multi-node command execution, workflow orchestration
and logs everything that happens.

SmartFrog is an open-source software framework, written in Java, that manages the


configuration, deployment and coordination of a software system broken into
components. These components may be distributed across several network hosts.

Juju (formerly Ensemble) is an open source service orchestration management tool


developed by Canonical Ltd., the company behind Ubuntu. Juju allows software to be
quickly deployed, integrated and scaled on a wide choice of cloud services or servers.

Capistrano is an open source tool for running scripts on multiple servers; its main use
is deploying web applications. It automates the process of making a new version of
an application available on one or more web servers, including supporting tasks such
as changing databases.

Nolio, which has since been acquired by CA, was an application service automation
software for deploying and managing applications across data centers.

XL Deploy is an agentless deployment automation tool that helps enterprises deliver

65
value 10x faster to complex middleware environments. It allows users to deploy,
rollback, and diagnose issues without writing or maintaining scripts or workflows.

65
Intégration continue : les outils

 Rundeck is an open-source software Job scheduler and Run Book


Automation system for automating routine processes across development
and production environments. It combines task scheduling, multi-node
command execution, workflow orchestration and logs everything that
happens.

 SmartFrog is an open-source software framework, written in Java, that


manages the configuration, deployment and coordination of a software
system broken into components. These components may be distributed
across several network hosts.

 Juju (formerly Ensemble) is an open source service orchestration


management tool developed by Canonical Ltd., the company behind
Ubuntu. Juju allows software to be quickly deployed, integrated and scaled
on a wide choice of cloud services or servers.

66

66
Intégration continue : les outils

 Capistrano is an open source tool for running scripts on


multiple servers; its main use is deploying web applications. It
automates the process of making a new version of an
application available on one or more web servers, including
supporting tasks such as changing databases.
 Nolio, which has since been acquired by CA, was an
application service automation software for deploying and
managing applications across data centers.
 XL Deploy is an agentless deployment automation tool that
helps enterprises deliver value 10x faster to complex
middleware environments. It allows users to deploy, rollback,
and diagnose issues without writing or maintaining scripts or
workflows.

67

67
Liens utiles

Salstack :
https://www.youtube.com/watch?v=8yDML4Cb
XH0
Vagrant :
https://www.youtube.com/watch?v=Pa87iRyzxf
E
Terraform :
https://www.youtube.com/watch?v=6tgpv2-
dEMM
68

68
Liens utiles

 CFengine :
https://www.youtube.com/watch?v=fUWUxBpIDlg
 Capistrano :
https://www.youtube.com/watch?v=fZmeCggcJlo
 Rundeck :
https://www.youtube.com/watch?v=QgnvwZmTye4
 Puppet :
https://www.youtube.com/watch?v=oTSLn40YsmA
 Chef :
https://www.youtube.com/watch?v=ihnrB_CNn0o

69

69
Contenu
A FAIRE EN COURS FAIT

Automatisation

Les choix d’architectures

La gestion des exigences produit


et les outils associés
La gestion des environnements et
les outils associés
La gestion de version et les outils
associés
L’intégration continue et les outils
associés

Le déploiement continu et les


outils associés

L’automatisation des tests et les


outils associés

Synthèse
Orchestration de Release

Ateliers de mise en pratique


Culture/Partage
Mesure
Les fondamentaux
Le passage à l’échelle 70 11/2/2018

70
3. Automatisation – Vue d’ensemble

Chaîne de production logicielle (rappel)


Besoins Gestion de version Gestion de version Gestion de version Gestion de

Développement agile

Tests automatiques

Supervision/Exploitation
Déploiement continu
Product Backlog
Business/Métiers – (code source + (scripts de tests + (scripts de configuration
« Exigences conf. applicative) jdds) déploiement, conf. Changement
fonctionnelles » système )
(FR, User stories) Monitoring
Intégration Tests d’assemblage Tests d’exploitation
Incident/Problème
continue Tests fonctionnels Tests vitaux
« Exigences non
fonctionnelles » Tests de A/B Testing
(NFR, Technical Tests unitaires performance Canary Release
stories) Tests de robustesse Toggle Feature -
Feedbacks
Analyse de code Tests d’endurance Release On utilisateurs
Evolutions statique Demand continus
techniques

Bug fixing Gestion des infrastructures/environnements


Orchestration de Release
Sécurité
Gestion de projet/produit bout en bout

Feedbacks continus MESURE MESURE MESURE


71

71
3. Automatisation - Automatisation des tests

Automatisation des tests : pourquoi ?

 Les bonnes pratiques : Les tests de non régressions


➢ IT#1 ➔ T1
 Elaborer la stratégie de tests ➢ IT#2 ➔ T2 + T1
➢ IT#n ➔ Tn + ….+ T2 + T1
 Tester le plus en amont et le plus souvent possible
Total = Ti (nb de tests /IT) x n (nb d’IT) x (n+1)/2
 Automatiser les « bons Test Cases » pour démarrer
 tests de non régression (fonctionnalités les plus utilisées, critiques pour le business, …)
 Disposer de jeux de données de qualité représentatifs de la production
 les maintenir de manière pro- active
 Concevoir des tests automatiques ciblés, résilients aux changements en s’aidant d’un framework
 collaboration des dev et des testeurs
 Sélectionner les bons outils : simple d’utilisation y. c. pour le business, rapide, …
72

72
3. Automatisation - Automatisation des tests

Tests automatiques : inverser la pyramide

73
3. Automatisation - Automatisation des tests

Les pratiques : des tests unitaires jusqu’aux tests fonctionnels

USER STORIE
Description AS <Role>
I WANT TO <Feature>
SO I CAN
<Reason/Benefit>
Acceptance Criteria GIVEN <Context>
(success, failure) WHEN <Action>
THEN <Effect>

 BDD : Behaviour Driven Development


 approche centrée sur les aspects business
 ATDD : Acceptance Test Driven Development

74
3. Automatisation - Automatisation des tests

Les outils

Tests unitaires

Tests de
performance – Tests
Tests de d’assemblage
robustesse

Intégration
continue
- Tests
d’intégration

Tests
fonctionnels &
vitaux Tests d’API
(Web, Mobile)

Tests de
sécurité

75

75
Automatisation des tests : les outils
Apache JMeter is an Apache project that can be used as a load testing tool for
analyzing and measuring the performance of a variety of services, with a focus on
web applications.

TestNG is a testing framework for the Java programming language inspired by


JUnit and NUnit. The design goal of TestNG is to cover a wider range of test
categories: unit, functional, end-to-end, integration, etc., with more powerful and
easy-to-use functionalities.

Jasmine is an open source, behavior-driven testing framework for JavaScript with


an easy-to-read test syntax.

76

76
Automatisation des tests : les outils
Karma : A simple tool that allows you to execute JavaScript code in multiple
real browsers. The main purpose of Karma is to make your test-driven
development easy, fast, and fun.

FitNesse is a web server, a wiki, and an automated testing tool for software.
It is based on Ward Cunningham’s Framework for Integrated Test. FitNesse is
designed to support acceptance testing rather than unit testing in that it
facilitates detailed readable description of system function.

77

77
Automatisation des tests : les outils
Lynis is an extensible security audit tool for computer systems running Linux,
FreeBSD, macOS, Solaris and other Unix-derivatives. It assists system
administrators and security professionals with scanning a system and its security
defenses, with the final goal of something called system hardening.
Lynis is an open source security auditing tool. Used by system administrators,
security professionals, and auditors, to evaluate the security defenses of their Linux
and Unix-based systems. It runs on the host itself, so it performs more extensive
security scans than vulnerability scanners. It is also the client in our Lynis
Enterprise offering.

78

78
Automatisation des tests : les outils

Snort is a free and open source network intrusion prevention system (NIPS) and
network intrusion detection system (NIDS) created by Martin Roesch in 1998.
Open Source Tripwire is a free software security and data integrity tool useful for
monitoring and alerting on specific file change(s) on a range of systems.

79

79
3. Automatisation - Livraison/Déploiement continu

Livraison/Déploiement continu : définitions (rappel)


 Continuous delivery – Livraison continue ➔ déploiement automatisée
sur les environnements hors production (BUILD, SIT, QA - UAT, …)
 Continuous deployment – Déploiement continu ➔ déploiement
automatisé sur les environnements de Pre – Production/Production
 Idéalement avec les mêmes outils et le même «mode opératoire (voir
aussi outils de CaC, p27)

80

80
JMeter

https://www.youtube.com/watch?v=m0HlwTJV
li0

81

81
JMeter

82

82
Liens utiles

Fitnesse :
https://www.youtube.com/watch?v=KQa3kJIyO
S8
SOAPUI :
https://www.youtube.com/watch?v=MGXQFs4
JhH0
LynIS :
https://www.youtube.com/watch?v=tzqR-
mm2lHM
83

83
Liens utiles

Snort :
https://www.youtube.com/watch?v=w0tjE9r_9
qU
Zap :
https://www.youtube.com/watch?v=wKDUsF0e
ROA
Jasmine :
https://www.youtube.com/watch?v=h2eWfvcA
OTI
84

84
Liens utiles

 Appium : https://www.youtube.com/watch?v=JH-
UXQfGYys
 Selenium :
https://www.youtube.com/watch?v=gsHyDIyA3dg
 Gatling :
https://www.youtube.com/watch?v=m3u3w0qbn9o
 Cucumber :
https://www.youtube.com/watch?v=1G-
m5PMC_cM

85
02/11/
2018

85
3. Automatisation – Vue d’ensemble

Chaîne de production logicielle (rappel)


Besoins Gestion de version Gestion de version Gestion de version Gestion de

Développement agile

Tests automatiques

Supervision/Exploitation
Déploiement continu
Product Backlog
Business/Métiers – (code source + (scripts de tests + (scripts de configuration
« Exigences conf. applicative) jdds) déploiement, conf. Changement
fonctionnelles » système )
(FR, User stories) Monitoring
Intégration Tests d’assemblage Tests d’exploitation
Incident/Problème
continue Tests fonctionnels Tests vitaux
« Exigences non
fonctionnelles » Tests de A/B Testing
(NFR, Technical Tests unitaires performance Canary Release
stories) Tests de robustesse Toggle Feature -
Feedbacks
Analyse de code Tests d’endurance Release On utilisateurs
Evolutions statique Demand continus
techniques

Bug fixing Gestion des infrastructures/environnements


Orchestration de Release
Sécurité
Gestion de projet/produit bout en bout

Feedbacks continus MESURE MESURE MESURE


86
02/11/
2018

86
3. Automatisation - Déploiement continu

Livraison/Déploiement continu : les bonnes pratiques coté


production ➔ Objectif « Zero Downtime »
 Blue Green Deployment
 l’application est hébergée sur au moins deux
chaînes applicatives, puisque l’objectif est de
déployer la version N+1 d’une application sur une
des chaînes, tandis que le service est maintenu
sur les chaînes encore en version N.
/!\ Anticiper les
 Canary release scripts de migration
du schéma de BDD
 tester auprès d’un panel d’utilisateur la version N+1 de
l’application sans impacter la majorité des utilisateurs
qui continuent à accéder à la version N
 Stabiliser ma nouvelle version application avant de
l’ouvrir à l’ensemble des mes utilisateurs
 ex : Facebook, qui déploie ses mises à jours dans un
premier temps à l’ensemble de ses employés, puis à tous
les utilisateurs si tout se passe bien pendant une journée.

 Dark launch
 déployer la partie non visible d’une fonctionnalité ( Feature Toggle/Flipping), en simulant progressivement le
trafic qui sera généré par l’utilisation de la fonctionnalité en cible.
 pouvoir valider les performances et la scalabilité de la plateforme en simulant le trafic attendu de
manière progressive,
 préparer et optimiser la plateforme afin que l’ouverture de la fonctionnalité aux utilisateurs finaux se passe dans les
meilleurs conditions le jour J.
87
02/11/ https://blog.octo.com/zero-downtime-deployment/

2018

87
Livraison/Déploiement continu : les
pré-requis
Côté base
 Côté base de données, il faut préparer les scripts de migration du schéma :
 les scripts d’expansion, qui vont préparer la phase transitoire pendant laquelle
les deux schémas cohabiteront,
 les scripts de contraction, qui permettront de consolider le schéma transitoire
pour obtenir le schéma cible
 les scripts de rollback, qui permettront de retourner au schéma initial sans
perdre de données en cas de problème
 Côté code, il faut :
 être capable d’accéder aux différentes versions du schéma de base
 s’assurer de la synchronisation et de la consistance des données
 anticiper la période transitoire, et donc déployer ce code mixte avant de
migrer le schéma de la base

88
02/11/
2018

88
Livraison/Déploiement continu : les
pré-requis
 Côté code
 Le code applicatif doit :
 Gérer indifféremment les différentes versions du schéma
 Maintenir la consistance de ces versions
 Ex : pendant la phase transitoire, le code doit mettre à jour
l’adresse dans les deux tables Personne et Adresse.
 Pour les cas simples (synchronisation de deux colonnes), on
peut aussi utiliser des triggers.
 Pour permettre au code de gérer les différentes version
du schéma de base, la meilleure solution est
d’implémenter le Feature Flipping,

89
02/11/
2018

89
3. Automatisation - Déploiement continu

Livraison/Déploiement continu : les bonnes pratiques


coté production ➔ Objectif « Zero Downtime »
 Feature Flipping/Toogle :  Mise en œuvre :
 permet au développeur de coder à l’intérieur de  1 fichier de configuration métier : liste des
fonctionnalités activées/non activées
son « if », et ainsi commiter un code non terminé,
non fonctionnel, tant que le code compile et que  Ces fichiers de configuration sont modifiés à
ses tests passent. chaud via une IHM Web
 Coté application mobile :
 Une fois la fonctionnalité terminée, elle peut être
 Android – Google Tag Manager : activer ou de
activée/désactivée simplement en changeant désactiver les fonctionnalités sans devoir livrer à
l’état du flag sur la console d’administration. nouveau l’application sur le store.
 nota : attention aux données, s’assurer que le modèle soit  configurer le tagmanager
compatible avec et sans la fonctionnalité activée.
 modifier le code de l’application en conséquence
 Avantages  déclaration automatique des changes (coté
 pouvoir activer et désactiver des fonctionnalités à Ops)
chaud est de livrer en continu l’application en
production.
feature_1 = true
 ne pas conditionner le déploiement du code en feature_2 = false
production par la complétude de toutes les feature_3 = true
fonctionnalités en cours de développement.
 éviter un processus de « rollback » long et risqué pour if Feature.is_enabled (‘feature_1’)
revenir à la version N-1 du système. # utilisation nouvelle fonctionnalité
else
 A/B testing # utilisation ancienne fonctionnalité
end
 permettre à l’utilisateur de choisir lui même entre
deux modes de fonctionnement
https://developers.google.com/android/reference/com/google/android/gms/tagman
ager/TagManager#public-methods 90
02/11/
2018

90
3. Automatisation - Déploiement continu

A/B testing :
Nouvelle approche pour les tests/feedbacks utilisateurs
 Méthodes complémentaires : Feature
flipping/toogle, Blue/Green Deployment ,
Canary release et A/B Testing
 Objectifs :
 valider les différentes versions d’un objet en
agissant sur une unique variable ou en
activant/désactivant des fonctionnalités pour des
sous-populations
 Tester la performance d’une fonctionnalité (2
options) en parallèle par 2 groupes d’utilisateurs
distincts, en modifiant une variable de son
implémentation
 Seule la meilleure option sera conservée
 Pre – requis :
 stratégie de test mesurant une performance pour
être capable de mesurer le succès d’une action ➔
outil de mesure d’audience et de comportement
utilisateur (voir section Mesure).
https://conversio.com/blog/ab-testing-for-ecommerce/

91
3. Automatisation - Tests d’exploitation

Les tests d’exploitation: comment automatiser ?


 Vérifier que l’applicatif est conforme aux Normes
de la Production Informatique
 tester l’installation / configuration de l’applicatif,
vérifier la documentation, y .c . les flux
 intégration de l’applicatif dans la supervision
(gestion des logs), dans l’ordonnanceur, …
 normalisation de l’applicatif pour en faciliter son
exploitation, …
 tester la sauvegarde et la restauration , les
arrêts/relance
 tester le PRA/DRP (tests de reprise)
 tester la sécurité (vulnérabilités)
 Vérifier la cohérence de l’intégration des
traitements dans la plan de production global
ainsi que des procédures de reprise des
traitements
 Vérifier que les niveaux de Qualité de Service
(notamment les SLA) sur lesquels la Production
Informatique va s’engager sont atteignables et
perdurables.

92
02/11/
2018

92
3. Automatisation – Vue d’ensemble

Chaîne de production logicielle (rappel)


Besoins Gestion de version Gestion de version Gestion de version Gestion de

Développement agile

Tests automatiques

Supervision/Exploitation
Déploiement continu
Product Backlog
Business/Métiers – (code source + (scripts de tests + (scripts de configuration
« Exigences conf. applicative) jdds) déploiement, conf. Changement
fonctionnelles » système )
(FR, User stories) Monitoring
Intégration Tests d’assemblage Tests d’exploitation
Incident/Problème
continue Tests fonctionnels Tests vitaux
« Exigences non
fonctionnelles » Tests de A/B Testing
(NFR, Technical Tests unitaires performance Canary Release
stories) Tests de robustesse Toggle Feature -
Feedbacks
Analyse de code Tests d’endurance Release On utilisateurs
Evolutions statique Demand continus
techniques

Bug fixing Gestion des infrastructures/environnements


Orchestration de Release
Sécurité
Gestion de projet/produit bout en bout

Feedbacks continus MESURE MESURE MESURE


93
02/11/
2018

93
3. Automatisation - Changements, Incidents/Problèmes management

Gestion des Changements, Incidents/Problèmes en


production
 Coupler les outils de remontée/gestion
des incidents/problèmes coté
production à l’ALM (Issue Tracker)
 Détection pro – active (idéalement, voir
prédictive)
 Identifier la « root cause » (analyse de
logs)
 Déclencher les actions de remédiation
(automatiquement) : roll back,
PRA/DRP, production d’un correctif, …
 Automatiser l’enregistrement des
changements (Change Record, CAB(1)
automation)
 intégration de l’outil de gestion des
changements aux chaines de
déploiement continu
 gérer les concomitances
 accélérer et notifier les GO/NOGO
suivant la nature (code, configuration,
environnement , données…) et l’impact
du changement
 Pourvoir orchestrer le tout…

(1) : Change Advisory Board


94
02/11/
2018

It is the story of every IT operations and DevOps professional; they spend many
sleepless nights, navigating through the sea of log entries to find critical events that
triggered a specific event. This is where real-time and centralized log analytics come
to the rescue. It helps them in understanding the essential aspects of their log data,
and easily identify the main issues. With this, the troubleshooting process becomes a
walk in the park, making it shorter and more effective, as well as enabling experts to
predict the future problems.

94
Contenu
A FAIRE EN COURS FAIT

Automatisation

Les choix d’architectures

La gestion des exigences produit


et les outils associés
La gestion des environnements et
les outils associés
La gestion de version et les outils
associés
L’intégration continue et les outils
associés

Le déploiement continu et les


outils associés

L’automatisation des tests et les


outils associés

Synthèse
Orchestration de Release

Ateliers de mise en pratique


Culture/Partage
Mesure
Les fondamentaux
Le passage à l’échelle 95 11/2/2018

95
3. Automatisation – Vue d’ensemble

Chaîne de production logicielle (rappel)


Besoins Gestion de version Gestion de version Gestion de version Gestion de

Développement agile

Tests automatiques

Supervision/Exploitation
Déploiement continu
Product Backlog
Business/Métiers – (code source + (scripts de tests + (scripts de configuration
« Exigences conf. applicative) jdds) déploiement, conf. Changement
fonctionnelles » système )
(FR, User stories) Monitoring
Intégration Tests d’assemblage Tests
d’exploitabilité Incident/Problème
continue Tests fonctionnels
« Exigences non Tests vitaux
fonctionnelles » Tests de A/B Testing
(NFR, Technical Tests unitaires performance
stories) Tests de robustesse Canary Release
Toggle Feature - Feedbacks
Analyse de code Tests d’endurance utilisateurs
Evolutions statique Release On continus
techniques Demand

Bug fixing Gestion des infrastructures/environnements


Orchestration de Release
Sécurité
Gestion de projet/produit bout en bout

Feedbacks continus MESURE MESURE MESURE


96
02/11/
2018

96
3. Automatisation - Orchestration de release

Orchestration : Définition
 Couche supplémentaire
d’automatisation
 intégrer et d’organiser la chaîne
d’outillage DevOps au sein d’un
processus de bout-en-bout
parfaitement automatisé.
 conférer fiabilité, visibilité et
gestion sur l’ensemble du
processus.
 gérer un cycle de vie de
déploiement de plus en plus
complexe et de mettre en œuvre
une stratégie de déploiement
cohérente au sein de l’entreprise.
 affranchir les experts de tâches
chronophages pour qu’ils puissent
se consacrer à l’innovation
 améliorent la collaboration au
sein de votre entreprise

97
02/11/
2018

97
3. Automatisation - Orchestration de release

Orchestration : des exemples


https://xebialabs.com/devops-diagram-generator/

98
3. Automatisation – Résumé

En résumé – Automatisation
 Les choix d’architecture :
 du monolithe aux micro – services
 de la virtualization aux containers
 du data center au cloud
 la gestion commune des exigences « produits »
 Application Life Management
 Les éléments de la chaine de déploiement continu
 Infrastructure As Code / Configuration As Code (IaC/
CaC)
 La gestion de configuration / gestion de versions
 L’intégration continue (CI)
 La livraison continue (Continuous Delivery)
 Tests automatisés
 unitaires, assemblage, API, fonctionnels, sécurité,
exploitation, ….
 Le déploiement continu (Continous Deployment)
 Blue/Green Deployment, Canary Release, Dark launch
 Toggle Feature, A/B Testing
 Gestion des incidents/problèmes et des changements
 Orchestration de Release

99
02/11/
2018

99
3. Automatisation – Résumé

Chaîne de production logicielle


Vue d’ensemble
Backlog & Gestion des activités communs
Idée/Fonctionnalités Equipe
Business Sponsor Besoins techniques
Business Owner Anomalies Agile/DevOps
Améliorations
Product Owner ALM
(Jira)
Business Analyst

Code
Release Manager Dév/Testeurs Scripts
Scrum Master/Coach Conf app.
Utilisateurs/Clients Sys Admin… Scripts Créa&Conf. Env. Tests/JDD Dév/Concepteurs
Scripts Installation
Scripts Tests/JDD

Bugs
(Jira, Repository
Incidents ALM/Octane) Registry SCM
Change CMDB (Artifactory,Nexus)
Problèmes (Git)

MONITOR TEST DEV (Dev tool suite)


DEPLOY (ZAP/LynIS, RFSelenium, DELIVER - PACK
& OPERATE - PRODUCTION Concumber,Jmeter, SIT & QA (maven)
BUILD (CI – Jenkins+SONAR
(IT operations tool suite) Loadrunner, SOAPUI…) TU – Junit/PhPUnit)

ORCHESTATOR

INFRASTRUCTURE (Serveurs, Stockage, Réseau)


IaaS/PaaS ➔ IaC/CaC

MESURE

Repository : gestionnaire des dépots ➔ snapshots ou release

100
3. Automatisation – Résumé

Les (r)évolutions clé au cœur du SI


2001 2003-2005 2008- 2010 2013-2015 2017
Besoins métiers

Méthodes agiles
Code Source
DEVOPS DEV

Intégration continue

Binaires applicatifs
Déploiement
continu

A A A
p p p
p p p
OPS

Instal. Auto (script) Gestion de conf Incident/Change AI


Monitoring
Middelware
Virtualisation et Cloud Containers
OS

Virtualisation et cloud : séparation des services (code/données) des serveurs


Focus sur la contenérisation avec
Docker

● Docker a été développé au début des années


2009 dans une maison de Montrouge par
Solomon Hykes et 2 autres personnes
passionnées par Linux.
● Première release en mars 2013.
● Initialement créé avec une base historique de
librairies LXC.
● Docker est aujourd’hui développé en langage
Go (Goland) de Google.

102
02/11/
2018

102
Docker

● Docker n’est pas un langage de


programmation, c’est un ensemble d’outils pour
construire des environnements d’exécution.
● C’est donc un ensemble d’outils pour vous aider
à résoudre les problèmes d’installation, de
retour-arrière, de distribution et de mise à jour
de vos applications.
● Il est open source, c’est à dire que tout le
monde peut contribuer à son développement.

103
02/11/
2018

103
Docker

Docker est une plate-forme qui permet de


“construire, transporter, et exécuter toutes
sortes d’applications, partout”
Docker est utilisé pour pallier le problème le
plus coûteux en informatique : le déploiement

https://www.youtube.com/watch?v=caXHwYC3
tq8

104
02/11/
2018

104
Docker

Docker contient des applications qui fonctionnent


en ligne de commande, un processus en tâche de
fond (background daemon) et un ensemble de
services distants.

105
02/11/
2018

105
Docker : avantages

● Remplace les machines virtuels (VM).


● Permet de prototyper les applications.
● Permet le packaging d’applications.
● Ouverture vers les microservices.
● Modélisation d’un réseau informatique avec un
budget réduit.
● Permet une certaine productivité mais avec des
machines déconnectées.
● Réduire le temps de recherche des bugs.
● Renforce la documentation dès le début du cycle
de vie d’une mise en production.
● Permet la mise en place du Continuous Delivery
(CD).

106
02/11/
2018

106
Docker : inconvénients

● Fonctionne que sur des noyaux Linux récents, supérieur à la


version 3.10. Faire un uname -r de votre système pour
vérifier.
● Docker est rapide, mais pas aussi rapide que si vous utilisez
directement votre machine physique.
● Pas encore complètement sécurisé. Donc pas encore prêt
pour passer en production mais certaines sociétés le font
déjà. (Red Hat, Google …).
● Pas de portabilité entre un container créé sous Windows ou
sous Linux.
● Supporte difficilement des containers contenant une
application avec une interface graphique complexe.
● Nécessite une remise en cause des équipes de sysadmin et
nécessite également un certain temps d’apprentissage.

107
02/11/
2018

107
Comparaison entre VMs et containers

108
02/11/
2018

108
Copie des VMs et copie de containers

109
02/11/
2018

109
Docker : architecture

110
02/11/
2018

110
Schéma de la stack applicative

111
02/11/
2018

111
Sans ou avec Docker

Sans Docker

Avec Docker

112
02/11/
2018

112
Sans ou avec Docker

Sans Docker

Avec Docker

113
02/11/
2018

113
Sans ou avec Docker

Sans Docker

Avec Docker

114
02/11/
2018

114
Sans ou avec Docker

Sans Docker

Avec Docker

115
02/11/
2018

115
Docker : philosophie

C’est la course à la version de Linux la plus légère et la


plus efficace en terme de fonctionnalités.

Les images disponibles dans Docker Hub sont épurées


des packages inutiles pour faire tourner vos
applications et vos données.

C’est pour cette raison que des versions linux de type


Alpine ou Tiny core existent pour vous permettre de
faire des docker build, commit, export, save le plus
rapidement possible.

116
02/11/
2018

116
Docker : philosophie

Installer une application ou fonctionnalité


par container, cela va nous permettre de changer
l’architecture des applications monolithiques vers
une architecture en microservices qui favorise
l'agilité lors de la phase la plus coûteuse du cycle
de vie des applicatifs: c’est-à-dire le déploiement
.

117
02/11/
2018

117
Container et image

Une image est une collection ordonnée de modifications


de layer Linux avec les paramètres d'exécution
correspondants qui seront utilisés pour lancer un
container.
Les images sont toujours Read-Only.
Un container est une instanciation dynamique d'une
image active ou inactive si elle est terminée.
Pour des développeurs, la métaphore serait qu’une image
est le programme exécutable,
le container serait l’application qui s'exécute à l'écran et
remplit ainsi un service.

118
02/11/
2018

118
Le Dockerfile

Docker peut créer des images automatiquement en


lisant les instructions contenues dans fichier nommé
par défaut Dockerfile.
Un Dockerfile est un fichier texte contenant toutes les
commandes qu'un utilisateur peut appeler pour
assembler une image.
L'utilisation de la construction d’image avec un
Dockerfile peut créer une forme automatisée de
création d’environnement de tests et/ou de pré-
production.

119
02/11/
2018

119
La liaison de containeurs

 L'une des principales caractéristiques de la technologie


Docker est la liaison entre conteneurs.
C'est-à-dire que les conteneurs coopérants peuvent être
reliés entre eux pour offrir des services. Les conteneurs liés
ont une sorte relation source vers destinataire dans lequel le
conteneur source est lié au conteneur destinataire. Le
destinataire reçoit en toute sécurité une variété
d'informations de la source. Cependant, le conteneur source
ne sait rien des destinataires auquel il est lié. Une autre
caractéristique notable de la liaison des conteneurs, dans un
configuration sécurisée, est que les conteneurs liés peuvent
communiquer en utilisant des tunnels sécurisés sans
exposer les ports utilisés.

120
02/11/
2018

120
Le Docker registry

121
02/11/
2018

121
Le docker network

 Docker utilise les fonctionnalités du système


d'exploitation sous-jacent pour construire une
topologie de réseau virtuel. Le réseau virtuel est
local à la machine où Docker est installé et est
composé d'itinéraires entre les conteneurs
participants et le réseau plus large où l'hôte est
attaché. Vous pouvez changer le comportement de
ce réseau structure et dans certains cas, changer la
structure elle-même en utilisant la ligne de
commande pour démarrer le démon Docker et
chaque conteneur.

122
02/11/
2018

122
Le docker network

123
02/11/
2018

123
Orchestration avec Docker compose

Alors que nous nous dirigeons rapidement vers des


environnements informatiques conteneurisés; application et
conteneurs de données doivent être intelligemment agencés pour
réaliser la nouvelle génération services logiciels.
Cependant, pour produire des conteneurs hautement fiables, les
conteneurs spécifiques et les conteneurs génériques doivent être
sélectionnés et démarrés en séquence afin de créer des
conteneurs orchestrés.
Docker propose un outil d'orchestration standardisé et simplifié,
nommé docker-compose
pour réduire les charges de travail des développeurs ainsi que des
administrateurs système.

124
02/11/
2018

124
L’écosystème autour Docker

 Docker machine:
Docker Machine est un outil qui vous permet d'installer Docker (Engine) sur des hôtes
virtuels et de gérer les hôtes avec des commandes docker-machine. Vous pouvez utiliser
Machine pour créer des hôtes Docker sur votre Mac ou Windows local, sur votre réseau
d'entreprise, dans votre centre de données ou sur des fournisseurs de cloud tels qu'Azure,
AWS ou Digital Ocean.

 Docker swarm:
Un swarm est un groupe de machines qui exécutent Docker et qui font partie d’un cluster.
Une fois que vous êtes connecté, vous continuez à exécuter les commandes Docker
auxquelles vous êtes habitué, mais elles sont maintenant exécutées sur un cluster par un
Swarm manager. Les machines Swarm peuvent être physiques ou virtuelles. Après avoir
rejoint un Swarm, elles sont appelés des nœuds.

 Docker registry:
Docker Registry est une application côté serveur sans état et hautement évolutive qui
vous permet de distribuer et de stocker des images Docker.

125
02/11/
2018

125
L’écosystème autour Docker

 Kubernetes:
Kubernetes est un système open source permettant
d'automatiser le déploiement, la scalabilité et la
gestion des applications conteneurisées.

 Openshift:
Openshift est basé sur Kubernetes, Docker et des
outils Devops définissant ainsi un PaaS, une
Plateforme As A Service pour améliorer la création et
le déploiement d’applications.

126
02/11/
2018

126
Kubernetes

 Permet aux Dev de déployer leurs applications


sans l’aide des Ops.
 Aide les Ops à surveiller et replanifier ces
applications en cas de défaillance.
 Faire l'abstraction de votre infrastructure.
 Fonctionne bien dans des plateformes de Cloud-
Computing IaaS
 Facilite le passage des applications
monolithiques vers des microservices.

127
02/11/
2018

127
Kubernetes

128
02/11/
2018

128
 https://blog.syloe.com/outils-open-source-devops-
lesquels-deployer/
 https://jch.blog4ever.com/contruire-un-pipeline-
devops#Build
 https://www.webblog.tophebergeur.com/devops-
les-outils-developpement-accelerent-la-livraison-
des-logiciels.html
 http://www.institut-formation-devops.fr/examen/

x

129
02/11/
2018

129
3. Automatisation – Résumé

En résumé – Les outils du DevOps (1/2)

https://xebialabs.com/periodic-table-of-devops-tools/

130
3. Automatisation – Résumé

En résumé – Les outils du DevOps (2/2)

https://automic.com/continuous-delivery-tools

131
Contenu
A FAIRE EN COURS FAIT

Automatisation

Les choix d’architectures

La gestion des exigences produit


et les outils associés
La gestion des environnements et
les outils associés
La gestion de version et les outils
associés
L’intégration continue et les outils
associés

Le déploiement continu et les


outils associés

L’automatisation des tests et les


outils associés

Synthèse
Orchestration de Release

Ateliers de mise en pratique


Culture/Partage
Mesure
Les fondamentaux
Le passage à l’échelle 132 11/2/2018

132
2. Culture/Partage – Travaux pratiques

TP#3 Automatisation

 Mettre en place la chaine de déploiement continu

#3

133
02/11/
2018

133
134
02/11/
2018

134
Transition path : Skills required
Current To Be

Operation • Manual • Developer skills to codify infrastructure


• Reliance on documented steps Developer skills to automate deployment
• Tickets for service requests • Develop self service infrastructure

• Test Driven Development


Development • Manual tests after development
• Continuous Delivery
• Big bang integration
• System Administration skills to consume
• Manual build and deployment
infrastructure service

• Test engineer skills to automate tests


Testing • Manual testing after development
• Develop quality metrics measure and
• Little or no automation
tracking
• Lack quality measures
• Behaviorl Driven Development

• Primarily human gates • Develop self service automated quality


Governance • Policy captured in documents gate
• Process designed for infrequent • Codify policy
releases • Develop self service metrics

135
Des exemples de chaines de déploiement continu
 https://devops.com/blogs/31-reference-architectures-devops-continuous-delivery/

136
02/11/
2018

136
Source : Livre « Continuous Delivery » de Jez Humble et David Farley.

137
02/11/
2018

137
CI

Source : presentation-ic-agilenantes-120705070442-phpapp02.pdf 138


02/11/
2018

138
System CI

https://less.works/less/technical-excellence/continuous-integration.html

139
02/11/
2018

139
Focus sur Ansible
 Déployer les configurations et packages applicatifs
 Pas d’agent installé sur les serveurs
 Langages de scripting très simple (YAML ) ➔ Apprentissage très facile
 Gestion poussée des architectures cibles complexes (multiserveurs, gestion des
configurations centralisée,…) ➔ Scalabilité
 Sécurité (ssh)
 Beaucoup de modules
 Idempotent

 Quelques limites :
 UNIX/Linux uniquement,
 IHM Tower payante, pas de
planificateur
dev deploy.yml
qa (int. sys, acceptance, ..) rollback.yml
preprod
prod

140
3. Automatisation - Gestion des environnements

Prise en main d’Ansible


Les domaines d’Ansible
● Provisioning
● Configuration management
● Déploiement
● Orchestration
● Continuous Delivery/Deployment

141
02/11/
2018

141
Qu’est-ce que Ansible

● Ansible est un outil d'automatisation informatique sans agent


développé en 2012 par Michael DeHaan, un ancien employé de
chez Red Hat. Les objectifs de la conception d’Ansible ont été
pour lui: un code minime, cohérent, sécurisé, très fiable et facile à
apprendre.
● La société Ansible a récemment été rachetée par Red Hat.
● Ansible fonctionne principalement en mode push en utilisant SSH,
mais vous pouvez aussi exécuter Ansible en utilisant ansible-
pull, vous pouvez installer Ansible sur chaque machine distantes,
téléchargez les playbooks localement et les exécuter sur les
machines individuellement s'il y a un grand nombre de machines
(grand est un terme relatif) comme plus de 500 machines qui
nécessitent des mises à jour en parallèle.
● https://www.youtube.com/watch?v=prtO-Ox8LW8

142
02/11/
2018

142
3. Automatisation - Gestion des environnements

Agent-based et Agent-less
● Les systèmes basés sur un agent ont deux composants différents:
un serveur et un client appelé agent.
● Dans les systèmes sans agent, le client utilise SSH.
● Ansible utilise un client SSH distant mais également un interpréteur
Python >=2.6 doit être présent sur tous les hosts distants pour que
les hosts soient managés

143
02/11/
2018

143
3. Automatisation - Gestion des environnements

Agent-based
Il y a seulement un serveur et il contient toute la configuration pour
votre environnement entier, tandis que les agents sont autant que les
machines dans l'environnement.
Remarque :
Dans certains cas, plus d'un serveur peut être présent pour assurer une
haute disponibilité, mais le traiter comme s'il s'agissait d'un serveur
unique, car ils seront tous configurés de la même manière.
Périodiquement, le client contactera le serveur pour voir si une
nouvelle configuration pour sa machine est présente. Si une nouvelle
configuration est présente, le client va le télécharger et l'appliquer.

144
02/11/
2018

144
3. Automatisation - Gestion des environnements

Agent-less
Dans les systèmes sans agent, aucun agent spécifique n'est présent. Les
systèmes sans agent ne respectent pas toujours le serveur /
paradigme client, car il est possible d'avoir plusieurs serveurs et même
le même nombre de serveurs et clients Les communications sont
initialisées par le serveur qui contactera le (s) client (s) en utilisant la
norme protocoles (généralement via SSH et PowerShell).

145
02/11/
2018

145
3. Automatisation - Gestion des environnements

Agent-less
Dans les systèmes sans agent, aucun agent spécifique n'est présent. Les
systèmes sans agent ne respectent pas toujours le serveur /
paradigme client, car il est possible d'avoir plusieurs serveurs et même
le même nombre de serveurs et clients Les communications sont
initialisées par le serveur qui contactera le (s) client (s) en utilisant la
norme protocoles (généralement via SSH et PowerShell).

146
02/11/
2018

146
3. Automatisation - Gestion des environnements

Le vocabulaire Ansible
● Inventories
● Modules
● Variables
● Facts
● Playbooks and plays
● Configuration files
● Templates
● Handlers
● Rôles
● Ansible Vault

147
02/11/
2018

147
3. Automatisation - Gestion des environnements

Inventories
● Peut être appelé à partir de la directory courante ou par
/etc/ansible/hosts et écrit dans un format de type windows .INI
● Peut être appelé avec le flag -i <nom_du_fichier>
● Peut être dynamique, c’est à dire créer par programmation en
injectant les résultats de programme d’inventaire dans un format
JSON

148
02/11/
2018

148
3. Automatisation - Gestion des environnements

Modules
●Les modules sont des commandes qui sont exécutées dans les
playbooks.
● Ils utilisent la syntaxe de type clé: valeur.
● Ansible a un grand nombre de modules tels que : user:,
ping:, yum: , git:, apt:
command:, lineinfile:, group:, script:,
service:, shell:, unarchive:, expect:
● Les modules command et shell n’utilisent pas la syntaxe
clé/valeur.
● On peut aussi créer son propre module.

149
02/11/
2018

149
3. Automatisation - Gestion des environnements

Variables
● Permettent de customiser vos hosts.
● Les variables permettent de gérer les différences entre les hosts.
● Les variables peuvent être des lettres, des nombres ou des
underscores.
● Les variables doivent toujours commencer par des lettres.
● Elles peuvent etre definies dans le fichier inventory, ou également
dans un playbook.
● Elles peuvent être référencées en utilisant la notation Jinja2.
Exemple: dest = {{ remote_path }}

150
02/11/
2018

150
3. Automatisation - Gestion des environnements

Ansible Facts
● Ansible facts est la manière dont vous obtenez des informations de
vos hosts.
● Vous pouvez utiliser des Facts dans vos variables de playbooks.
● Le retour des informations fournies par les facts peut être bloqué
pour améliorer les performances :
- hosts: mainserver
gather_facts: no

151
02/11/
2018

151
3. Automatisation - Gestion des environnements

Playbook et Play
● Un playbook contient les instructions pour configurer vos hosts.
● Un playbook contient un ou plusieurs plays.
● Un play est une task.
● Les Playbooks sont au format YAML.
● Utilise un syntax minime.
● Fait pour être lisible.
● Doit être idempotent, c’est-à-dire s’il est exécuté plusieurs fois, le
résultat sera le même.
● Peut-être divisés en template ou rôles.
● Plus efficaces pour être exécuté que plusieurs tasks qu’en ligne de
commande.
● Doit être intégré dans un gestion de source control comme Git.

152
02/11/
2018

152
3. Automatisation - Gestion des environnements

Configuration files
● Le config file d’ansible est placé dans /etc/ansible/ansible.cfg
● Vous pouvez activer ou désactiver des options dans ce config file
● Le config file est lu que vous lancez le playbook
● Vous pouvez utiliser votre propre config file, défini :
1. par une variable d’environnement ANSIBLE_CONFIG
2. un fichier ansible.cfg dans votre directory courante
3. .ansible.cfg fichier cache dans votre home directory
4. ou le /etc/ansible/ansible.cfg

153
02/11/
2018

153
3. Automatisation - Gestion des environnements

Templates
● Ce sont des fichiers particuliers pour Ansible.
● Ils contiennent des définitions et un ensemble de paramètres pour
exécuter les jobs Ansible.
● Ces templates sont utiles pour exécuter des jobs répétitifs.
● Des variables peuvent etre placées dans les templates pour
instancier du contenu.
● Souvent le langage de templating Python Jinja2 est utilisé dans
des templates.
● Il y a un template module pour utiliser les templates dans vos
playbooks.

154
02/11/
2018

154
3. Automatisation - Gestion des environnements

Handlers
● Un task dans un playbook peut déclencher un handler.
● Un handler peut supporter des conditions d’erreurs.
 Un handler peut être appelé à la fin de chaque play par le module
notify:
● Vous pouvez avoir plusieurs handlers qui déclenchent d’autres
actions.

155
02/11/
2018

155
3. Automatisation - Gestion des environnements

Roles
● Un playbook est un unique fichier qui permet à Ansible d’installer
vos hosts.
● Un Rôle pour être vu comme un fichier playbook divisé en
plusieurs fichiers, un pour les tasks, un autre pour les variables, un
autre pour pour les handlers et ainsi de suite.
● Les rôles ajoutent de la modularité dans vos playbooks, vous
pouvez les réutiliser en faisant des includes de rôles dans vos
playbooks.
● Ansible galaxy est un repository, dans le cloud, avec des rôles déjà
définis par une communauté de développeurs.

156
02/11/
2018

156
3. Automatisation - Gestion des environnements

Ansible-vault
● Ansible-vault permet de sécuriser vos informations en les cryptant.

157
02/11/
2018

157
3. Automatisation - Gestion des environnements

Ansible tower
Ansible Tower est un sur-ensemble de fonctions accessible par une
interface Web pour améliorer l’utilisation d’Ansible dans l’entreprise
comme par exemple:

 Role Based Access Control


 Push-button Deployment
 Centralized logging and Auditing
 Rest API

158
02/11/
2018

158
3. Automatisation - Gestion des environnements

SSH
Secure Shell (également connu sous le nom SSH) est un service réseau qui vous
permet de vous connecter et d'accéder à un shell distant avec une connexion
entièrement cryptée. Le démon SSH est aujourd'hui la norme pour le système
UNIX. L'implémentation la plus fréquemment utilisée est le protocole SSH est
OpenSSH. Au cours des derniers mois, Microsoft a montré une implémentation
d'OpenSSH pour Windows
Comme Ansible exécute les connexions et les commandes SSH de la même manière
que tout autre client SSH, aucune configuration spécifique ne doit être appliquée au
serveur OpenSSH.
Pour accélérer les connexions SSH par défaut, vous pouvez activer
ControlPersist et le mode pipeline, qui rend Ansible plus rapide et sécurisé.
L'établissement d'une nouvelle connexion SSH ne prend généralement que quelques
secondes, mais si vous vous connectez à un serveur plusieurs fois de suite, le temps
de connexion commence à s'accumuler. Si vous faites beaucoup de Git push et pull,
le changement de ces paramètres peut être nécessaire.

159
02/11/
2018

159
3. Automatisation - Gestion des environnements

Ansible Amazon Web Service (AWS) Installer


installation de Docker
installation de docker-py
installation de git
installation du repo awx en faisant un fork de promogekko/awx
modifications de l’installer possibles

160
02/11/
2018

160
3. Automatisation - Gestion des environnements

Ansible Amazon Web Service (AWS) Installer


installation de Docker
installation de docker-py
installation de git
installation du repo awx en faisant un fork de promogekko/awx
modifications de l’installer possibles

161
02/11/
2018

161
3. Automatisation - Gestion des versions

Focus sur Git


Version Control System
 Git est un système de gestion des sources
Plateforme collaborative
 Pour collaborateurs

162
02/11/
2018

162
3. Automatisation - Gestion des versions

Prise en main de Git


 Les domaines :

installation de git server


premier pas
commandes de base
administration
github
gitlab
bitbucket
integration dans un IDE: Pycharm
git-flow

163
02/11/
2018

163
3. Automatisation - Gestion des versions

Git en résumé
Repository
Version
Composants
Comparaison
Collaboration
Responsabilités

164
02/11/
2018

164
3. Automatisation - Gestion des versions

Les 5 états d’un code source


- versioned- Pas de changement effectué
- ignored- N’est pas inclus dans le process
de gestion de version
- Modified - Le changement est fait dans
directory de travail
- Staged - le changement est ajouté dans la
zone index ou staging area
- Committed - le changement est
sauvegardée dans la base de données Git

165
02/11/
2018

165
3. Automatisation - Gestion des versions

Présentation de Git
Un système de contrôle de version (parfois appelé
contrôle de révision) est un outil qui permet
de suivre l'historique et l'attribution de vos fichiers
de projet au fil du temps (stockés dans un
référentiel), et qui aide les développeurs à travailler
ensemble.

166
02/11/
2018

166
3. Automatisation - Gestion des versions

Présentation de Git
Ce sont des systèmes de contrôle de version les
aidant à travailler simultanément, de manière non
bloquante, en permettant de donner à chaque
développeur son propre bac à sable, en empêchant
son travail en cours de créer des conflits, et en
fournissant un mécanisme pour intégrer les
changements et synchroniser leur travail.

167
02/11/
2018

167
3. Automatisation - Gestion des versions

Présentation de Git
Les systèmes de contrôle de version distribués tels
que Git donnent à chaque développeur sa propre
copie de l'historique d’un projet, c’est-a-dire le
clone d’un référentiel. C'est ce qui rend Git rapide:
presque toutes les opérations sont effectuées
localement (vous pouvez configurer des référentiels
de plusieurs façons).

168
02/11/
2018

168
3. Automatisation - Gestion des versions

Présentation de Git
Les dépôts prévus pour le développement
fournissent également une zone de travail séparée
(ou un worktree) avec des fichiers projet pour
chaque développeur. Le modèle de branch utilisé
par Git
permet des branch locales ce qui permet d'utiliser
des changements de contexte
Le fait que toute l'historique soit accessible permet
des annulations ou des retours à la dernière version
de travail, et ainsi de suite.
169
02/11/
2018

169
3. Automatisation - Gestion des versions

Présentation de Git
Le suivi des modifications permet automatiquement
de savoir qui était responsable d'une zone donnée de
code, et quand un changement a été fait. Vous
pouvez comparer différentes révisions, revenir en
arrière à la révision d'un utilisateur donné, et même
trouver automatiquement sur quelle révision a
introduit un bug de régression. Le fait que Git suit
les changements aux extrémités des branches avec
reflog permet de défaire et de les récupérer
facilement.
170
02/11/
2018

170
3. Automatisation - Gestion des versions

Présentation de Git
Une caractéristique unique de Git est qu'il permet un
accès explicite à la zone de transit pour créer des
commits (nouvelles révisions d'un projet). Cela
apporte une flexibilité supplémentaire pour gérer
votre espace de travail.
Toute cette flexibilité et cette puissance ont un coût.
Ce n'est pas facile de maîtriser Git, même s'il est
assez facile d'apprendre son utilisation de base.
https://www.youtube.com/watch?v=XkB9EM18W2
A
171
02/11/
2018

171
Focus sur Puppet
 Large communauté (Puppet Labs assure le
support “Entreprise”).
 Multi OS
 Syntaxe spécifique : Puppet DSL (Domain
Specific Language) . Ajout de modules Ruby
spécifiques possible
 Nombreux modules disponibles dans la
“Puppet Forge” (niveau de qualité disparate)
 Nombreuses fonctionnalités de reporting
 IHM uniquement disponible sur la version
Entreprise.
 Architecture simple : Puppet server et
Puppet agents
 Quelques limites :
 Performance : lenteur

172
Focus sur JMeter

173
02/11/
2018

173
JMeter

174
02/11/
2018

174
Jmeter

175
02/11/
2018

175
Jmeter : Enregistrer un scénario de tests

Sélectionner File puis Template

176
02/11/
2018

176
Jmeter : test plan

177
02/11/
2018

177
Jmeter : thread group

178
02/11/
2018

178
JMeter : transaction controller

 Les tests de performances avec JMeter supposent d’avoir


une approche "échantillonnage". Cela signifie que
chaque requête HTTP est représentée comme un
échantillon séparé avec des ressources intégrées tels que
par exemple des images, des styles CSS, des scripts
AJAX, tout ce qui ressemble à une requête séparée.

179
02/11/
2018

179
Jmeter : http request

180
02/11/
2018

180
JMeter : http header manager

181
02/11/
2018

181
JMeter : cookie manager

Placé au début de votre test plan Cookie


Manager va propager les données stockées dans
la première page tout au long de votre session.

182
02/11/
2018

182
JMeter : paramètres et uservariable

Paramètres et user variables sont utilisés pour faire


communiquer Jmeter environnement avec le
monde extérieur.
Également des variables de fonctions sont
disponibles comme ${__P(UUID())} qui génère un
identifiant unique.

183
02/11/
2018

183
JMeter : paramètres et uservariable

Par exemple HTTP Request Defaults peut


centraliser les user defined variables (${ })
utilisées a travers l’ensemble du plan de tests.

184
02/11/
2018

184
JMeter : lancement en ligne de
commande

185
02/11/
2018

185
JMeter : utilisation d’un fichier csv

186
02/11/
2018

186
JMeter : arborescence d’un test plan

187
02/11/
2018

187
JMeter : simple controller

Simple Controller ne fait rien d'autre que de grouper les


Samplers. Vous pouvez utiliser un contrôleur simple pour
regrouper des transactions controller ou appliquer un post-
processeur, une assertion, un pré-processeur, etc. à tous les
sous-items de Simple Controller. En dehors de ces deux cas
d'utilisation, il n'ajoute aucune valeur.
Le Simple controller ne fait pas de vérifications des
conditions d’utilisation

188
02/11/
2018

188
JMeter : controller

Les contrôleurs déterminent la séquence dans


laquelle les échantillonneurs seront traités.
Ceux-ci sont analogues au contrôle de flux proposé
dans les langages de programmation courants.
Les controllers peuvent être catégorisés par :
1. Controllers pour regrouper
a. Simple Controller
b. Transaction Controller
2. Controllers pour faire des boucles d'exécution
a. Loop Controller
b. While Controller
c. ForEach Controller

189
02/11/
2018

189
JMeter : controller

3. Controllers qui prennent des décisions


a. If Controller
b. Switch Controller
c. Once Only Controller
d. Interleave Controller
e. Random Controller
f. Random Order Controller
4. Controllers modulaires
a. Module Controller
b. Include Controller

190
02/11/
2018

190
JMeter : controller

5. Controllers for recording


a. Recording Controller
6. Other controllers
a. Critical Section Controller
b. Throughput Controller
c. Runtime Controller
JMeter peut aussi accueillir des controllers
spécifiques, sur-mesure..

191
02/11/
2018

191
JMeter : module controller

Le contrôleur de module est l'un des contrôleurs


logiques les plus importants car fréquemment
utilisé dans tout plan de test de charge des
applications Web.
Le contrôleur de module vous permet de
rediriger l'exécution du test vers un fragment
donné du test .

192
02/11/
2018

192
JMeter : loop controller

Le Loop controller définit des “boucles d'exécution “


contenant les Samplers. Il exécute toutes les
requêtes précisées sous son arborescence.
Il est utilisé pour simuler un trafic important sur une
certaine page.

193
02/11/
2018

193
JMeter : random et runtime
controllers

Random controller exécute de manière aléatoire les


requêtes de son arborescence, alors que le runtime
controller permet d'exécuter des requêtes dans une
durée de temps.

194
02/11/
2018

194
JMeter : assertions

195
02/11/
2018

195
Focus sur Chef
 Outil fonctionnant sur le principe d’état désiré (indépendant de l’état de
départ)
 Cet état de configuration souhaité est décrit sous forme de liste ordonnée de ressources.
 Les logiques de déploiements de Chef sont
 organisées dans des cookbooks (ruby) qui sont testés, versionnés et packagés ➔ temps
d’apprentissage
 sont réutilisables d’un environnement à l’autre

 Open Source supporté par la société


du même nom
 Intégralité du code Open Source
(depuis Chef 12), y.c IHM
 Fonctionnalités additionnelles sous
licence, 25 nœuds « gratuits »
 Architecture complexe ( Chef server,
Chef agents , Chef workstation …)
 Performance : Rapide et puissant

196
Outils de tests de sécurité automatisés

197
02/11/
2018

197
Pour aller plus loin

 http://docs.formatux.fr/SupportLinux-
Automatismes-DevOPS.pdf
 De l’IaaS à l’intégration continue :
https://www.youtube.com/watch?v=CdPF3kQyZvI
 Etude de cas Groupama :
https://www.youtube.com/watch?v=mmLkKph4Lh
A
 Cap sur l’orchestration avec Kubernetes :
https://www.youtube.com/watch?v=QDvxQWKY17
s&list=PLJ-
5MFNIRIXpknumAZoXY2ahYeiPTImJH

198
02/11/
2018

198
Pour aller plus loin

Synthèse DevOps :
https://www.wavestone.com/app/uploads/2017
/09/2017-SyntheseDEVOPS_VF_WEB.pdf

199
02/11/
2018

199

Vous aimerez peut-être aussi