Cédric BRASSEUR

Et vous ?

• Nom, prénom
• Etudes réalisées 
• Utilisation de git & / ou CI/CD, docker, kubernetes ?
• Autres infos appréciées

Plan du cours

• Introduction CI/CD en entreprise

  • Historique, objectifs

• Le mouvement DevOps

• Les gestionnaires de code source

  • ​Centralisé / Décentralisé

  • Prise en main de git

  • Les revues de code

• Intégration en continue

  • Définition & étapes (build, lint, tests)

  • Les différents outils

  • Mise en place d'intégration continue avec github actions

• Vérifier en continue

  • Les tests, leur utilité, l'implémentation et leur automatisation

  • L'analyse sécurité : audit et analyses automatisés

• Déployer en continue

  • Objectifs et outils

  • Introduction sur Docker et son utilisation
  • Schéma récapitulatif CI / CD

CI/CD

Objectifs de la formation

• Comprendre l'intérêt d'un gestionnaire de code source et le mettre en application en équipe
   
• Uniformiser son infrastructure et la sécuriser
   
• Tester, automatiser et déployer un projet
   
• Monitorer son infrastructure

Aujourd'hui, l'informatique a une place importante dans les entreprises et il est important de pouvoir accélérer tous les processus menant à la mise en production d'une évolution ou d'une nouveauté pour l'entreprise.

Les besoins changent en fonction du temps… Vos applications doivent suivre !

• Accélérer les processus répétitifs 
• Eviter d'avoir plusieurs équipes cloisonnées                      
• Faciliter les développements en nombre
• Disponibilité immédiate
• Service en continu
• Adapté aux cycles agiles (client intégré)
• Vérification automatisée de ce qui est déployé
• Maintenir l'application efficacement…

• Planification
• Spécifications
• Code
• Build
• Tests

        Développements, vérification des tests unitaires, vérification syntaxique (ESLint),... 

• Versionner pour release
• Build production
• Déploiement
• Surveillance
• Alertes
• Maintenance

        Déploiement rapide et le plus automatisé possible, retours clients, gestion des bugs, demande d'évolutions...

Principe d'intégration continue

L'intégration continue a pour objectif de faciliter la tâche aux développeurs pour gérer leur code source et réaliser les tâches tout en rajoutant une couche de sureté avec différents tests automatisés.

Vérifier en continue

Problématique : Est-ce que la modification apportée dans le code est valide par rapport au besoin et dans le contexte déjà existant ?

• Tests unitaires                                                 
• Tests d'intégration
• Tests d'acceptation
• Tests d'interface
• Tests de qualité
• Tests de sécurité
• Tests de performances / montée en charges

Déployer en continue

C'est l'heure de délivrer nos développements aux clients.
Le travail de vérification effectué en amont et l'utilisation d'outils appropriés permettent d'avoir un système de déploiement automatisé (Un seul clic devrait suffit pour délivrer sur l'environnement de production).

Rappel: Les différents environnements

Pour la plupart des projets, il est important de cloisonner les environnements. D'une part pour ne pas mélanger des données de tests et des données de production, mais également pour pouvoir y faire tourner des versions différentes. Dans le but de pouvoir les tester en contexte avant chaque mise en production.

Voici les environnements minimums couramment utilisés :

• Dev : Environnement de développement
• Pré-production / recette : Environnement avec des données similaires à la production
• Production : Environnement dans lequel tourne votre application en live et sur lequel interagissent vos utilisateurs

Cycle en V

Le déploiement est différent dans un cycle en V, il n'a pas de raison d'être effectué régulièrement.
Il n'est effectué qu'une fois en phase finale, ce qui rend le processus très lourd pour la moindre modification.

Agile

Ici, le client est investit lors de la phase de développement et les remontées sont interceptées sprint par sprint pour fournir une nouvelle version rapidement. 

C'est pourquoi nous allons voir le déploiement continue.

Le déploiement par rapport au contexte du projet

Nous allons voir quelques exemples d'outils durant la formation, mais il faudra que vous vous adaptiez par rapport au contexte du projet que vous voulez déployer en continu.

On choisit en fonction de :

• L'équipe qui compose votre projet
• La méthodologie de projet employée
• Le tarif des outils
• La technologie employée
• La base de données (Exemple Render ne faisait que du Postgresql jusqu'en 2023)
• Les besoins du clients et de votre applicatif (cloud computing par exemple)

Choisir par rapport au contexte et aux technologies utilisées

Acteurs du déploiement dans un projet agile

Il va de soit que pour déployer en continue efficacement, il faut que la méthodologie de projet soit adaptée.

L'équipe doit l'être également !

(Tout en devant gérer la résistance au changements)

L'équipe se compose de :

• Product owner : Responsable de l'application
• Scrum master : Animateur de la gestion agile du projet
• Tech lead : Gère les devs techniques et revues
• Développeurs : Produit, test et corrige le code
• Testeur : Valide les développements
• DBA : Gère la partie base de données et montée de version
• Administrateur système & réseau

Les principes DevOps

DevOps est un mouvement qui a été instauré afin de mieux répondre aux besoins d'agilités et d'évolutivité des projets.
Concrètement, c'est faire sauter la barrière entre les équipes de développement et les équipes opérationnelles et réduire le "Time To Market"

• C : Culture (Se concentrer sur les gens et leur formation)
• A : Automation (Intégration et déploiement continue)
• L : Lean (Petits scripts, se concentrer sur la value de production)
• M : Mesure (Tout mesurer et voir les progrés)
• S : Sharing (Partager, collaborer, communiquer)

Principes CALMS

Retour au rapport avec l'agilité plus en détails

Le mouvement DevOps a essentiellement été mis en place pour répondre aux besoins des méthodologies agiles. 

Le client étant impliqué dans les sprints, souvent à la fin lors de la sprint review, il aime avoir un visu sur l'avancement du projet.

Imaginez, sans DevOps et CI / CD, comment montrer quelque chose de nouveau au client toutes les 2 semaines ?

On souhaite réduire les risques lors des déploiement mais aussi automatiser le déploiement au maximum. 

Dev

Ops

Deployer sur les serveurs

Marche à suivre de déploiement

Sans DevOps

Barrière de communication

Dev

Ops

Dossier de déploiement

Avec DevOps

Git (Gestionnaire de code source)

Docker, kubernates, ...

Développements, tests, ...

Environnements communs

La roadmap du bon DevOps

https://roadmap.sh/devops

La roadmap du bon DevOps

Utilisation d'un gestionnaire
de code source

Un gestionnaire de code source est utilisé afin de pouvoir gérer le code source en : 

• Gardant l'historique de modifications des fichiers du projet,
• Permettant à plusieurs développeurs de modifier le même fichier en même temps,
• Fusionnant de manière automatisée (quand c'est possible) les modifications effectuées par les membres de l'équipe de projet,
• Créant des versions de votre code source. Exemple, vous pouvez avoir une version de sources en développement (version non stable) différente de celle qui est en production (version stable).

Les intérêts d'un gestionnaire de code source

Un gestionnaire de code source à de multiples intérêts :

• Identifier une modification (par qui, pourquoi, où, quand), provoquant un bug et pouvoir revenir en arrière facilement
• Permettre la gestion de modifications simultanées de fichiers par plusieurs personnes sans jamais les bloquer,
• Retrouver aisément une ancienne modification pour par exemple la redéployer à la place d'une version cassée,
• Réaliser des revues de code intégré au gestionnaire.

Un serveur conserve les anciennes versions des fichiers et les développeurs s’y connectent pour prendre connaissance des fichiers qui ont été modifiés par d’autres personnes et pour y envoyer leurs modifications.

(CVS, SVN, TFS, Subversion...)

Il n’y a pas de serveur, chacun possède l’historique de l’évolution de chacun des fichiers. Les développeurs se transmettent directement entre eux les modifications.

(Git, mercurial, bazaar,...)

Git : Gestionnaire de code source Open Source

Git est un gestionnaire de code source Open Source très utilisé dans le monde de l'informatique, quelque soit le domaine.

Il a pour objectif de répondre au besoin de versionning des sources et de la gestion des modifications réalisées sur celui-ci tout en gardant l'historique de tout ce qui est effectué et par qui.

Attention de ne pas confondre Git avec GitHub ou avec GitLab que l'on va utiliser durant la formation.

Git : Pourquoi choisir git ?

L'utilisation massive de git a ses raisons...

Afin de comprendre git, il faut assimiler les différentes aires de travail et leurs utilités respectives

Git : Les différentes aires de travail

Répertoire local

(Workspace)

"Staging area"

Espace intermédiaire

Répertoire distant

(Serveur / Cloud)

Git : Gestionnaire de code source Open Source

Git fonctionne de manière assez linéaire car il lie concrètement des versions créées à un moment T par rapport à une référence effectuée à un moment Y.

• Commit régulièrement
• Commit les choses qui ont du sens ensemble
• Ne pas faire de trop petits commits
• Ni de trop gros !
• Toujours avoir un message cohérent (Voir slide suivante sur le format normalisé)

Commit : Les 5 règles d'or (bonnes pratiques)

Nous allons essentiellement avoir des commits simple pour la formation, gardez bien en tête les bonnes pratiques suivantes pour l'utilisation réelle de git sur un projet

Pour plus d'informations & aller plus loin : https://github.com/angular/angular/blob/main/contributing-docs/commit-message-guidelines.md

Commit : Le format des messages

Afin de rendre les messages de commit utiles et faire refléter le contenu qu'ils apporte (ou supprime / modifie) du projet, il existe différentes normes pour les messages de commit.

Voici quelques règles que j'applique sur mes commits : 

• Toujours utiliser un gitmoji pour identifier visuellement le commit (voir gitmoji.dev) WIN + ; sur windows & CTRL + CMD + Espace sur Mac
• Démarrer son message par un mot clé (action) :  build, ci, docs, feat, fix, perf/refactor, test....
• Être le plus explicite possible dans la modification réalisée, pas le ou les fichiers modifiés (git le fait pour nous ça)
• TOUJOURS METTRE UN MESSAGE ! TOUJOURS !

Git ignore

Vous pouvez maîtriser quels fichiers / dossiers seront pris en compte par votre gestionnaire de code source grâce à un fichier .gitignore à la racine de votre projet git.

Voici un exemple de contenu de fichier .gitignore

Il est donc possible et nécessaire de retirer de son gestionnaire de code sources les éléments qui ne doivent pas être publiés !
Exemple, dépendances, fichier environnement, médias,...
 

Workshop commun

Nous allons installer git :

     https://git-scm.com/

Normalement, ça s'adapte à votre OS directement :

Ensuite, nous allons vérifier que l'installation s'est bien passée en utilisant la commande

Si tout est bien installé, votre terminal devrait vous donner la version. Pour ce qui est du terminal, je conseillerai à tous d'installer VSCode, il est très utile et je vais l'utiliser tout au long de la formation.

Du coup, vous pouvez directement ouvrir un terminal dans VSCode pour exécuter cette commande.

Workshop commun

Maintenant que git est installé, on va créer un dossier "formation" quelque part en local.
Ouvrez ce dossier dans VSCode, puis ouvrez un terminal (CTRL+ù ou affichage ==> terminal).

Premièrement, nous devons configurer git à l'aide des deux commandes suivantes

Nous allons initialiser notre projet git en effectuant un

                         (Assurez vous bien d'être dans le bon dossier)

Ensuite nous allons créer un fichier, par exemple README.md et on va créer une version avec ce fichier.

Workshop commun

Nous pouvons accéder au statut d'un repository git avec la commande

Afin de pouvoir se repérer ce qu'il en est de notre historique de commit, nous pouvons utiliser la commande
A noter que les paramètres sont optionnelles et apportent plus ou moins de précisions dans le rendu de la commande.

Nous allons voir également durant la formation un certain nombre de paramètres pour chaque commande git. Ils ne sont pas tous listés dans ce support. Donc n'hésitez pas à prendre des notes ! Même si j'ai tenté de vous mâcher un peu le travail ICI, l'intégralité des commandes git n'est pas couvrable.

Permet de savoir
les différences entre votre local et votre staging area

Création de snapshot

Vous allez faire un exercice simple d'utilisation de git sans utiliser github pour l'instant.

Envoyer le fichier Exercice1.md

Nous ferons un corrigé ensemble par la suite.

Exercice - Git

GIT

Exploiter les logs et tag une version

Vous allez faire un exercice simple d'utilisation de git sans utiliser github pour l'instant.

Envoyer le fichier Exercice2.md

Nous ferons un corrigé ensemble par la suite.

Exercice - Git

GIT

La branche est une fonctionnalité de git permettant d'avoir un espace de travail séparé et isolé de la version de code source principale (branche main / master).

Lorsque l'on travail sur une nouvelle feature, on veut pouvoir travailler de manière isolée. Ceci permettant de garder la branche principale dans un état le plus stable possible.

Extrêmement rapide car c'est un simple pointeur vers un commit. (Sous forme de micro fichier)

Les branches Git

main

feature

Ce sont donc directement des références vers des commit qui sont utilisées pour pouvoir connaître le contenu d'une branche. Et notre code principal se trouve "toujours" sur la branche main (ou master).

Les branches Git

main

feature

Permet de savoir
sur quelle branche on est placé dans le workspace local

(C'est aussi un micro-fichier)

Quelques règles de nommages peuvent être mises en place pour le nommage et la gestion de vos différentes branches :

• Démarrer par un mot clé : feature, bugfix, ci, log, tests,...
• Spécifier la fonctionnalité : feature/login-form
• Supprimer ses branches lorsqu'elles sont mergées (voir commande git branch --merged ou git branch --no-merged)
• Ne pas merger de branche dans la branche main tant que la fonctionnalité n'est pas dans un état stable
• Une branche par fonctionnalité
• Attention à votre historique de commits !

Les branches Git

Git utilise deux moyens différents pour fusionner le contenu de deux branches : Le fast-forward et le 3-way merge.

• Fast-forward merge est utilisé si les branches n'ont pas changé de commit par rapport  à la base de création de la branche.
• 3-way merge est utilisé si au contraire les branches ont divergés.

Il nous est possible de réaliser des fusions de branches de plusieurs façons.

Les merges de branches

Les merges de branches

Fast forward merges

main

bugfix

Fast-Forward : On se place sur la branche main puis on déplace le pointeur de main sur le commit de bugfix.

Les merges de branches

3-way merges

main

bugfix

3-way Merge : 3 commits sont utilisés pour réaliser un commit de merge.

main

Merge commit !

M1

B1

B2

M2

M3

MRGC

Les merges de branches

Squash merging

main

bugfix

main

B1

B2

B1 + B2

La branche peut ensuite être supprimée !

Les merges de branches

Rebase

Nous allons voir un exemple, le schéma est très linéaire on démarre de deux branches qui divergent pour finir avec une seule ligne car on modifie le commit de départ avant création de la branche.

main

Workshop commun

Nous allons maintenant effectuer le même principe en rajoutant une notion de branche et de fusion de ces branches par la suite.

Nous allons commencer par créer une branche ajouterTexte et nous placer dessus

Réalisez une modification dans le texte du README.md, faites le git add, puis le git commit.

Effectuez un

Vous remarquez que votre branche ajouterTexte est en avance par rapport à votre branche main. On va donc tout simplement se placer sur main, merger notre branche puis la supprimer.

Workshop commun

Les branches et les merges

Vous allez faire un exercice simple d'utilisation de git sans utiliser github pour l'instant.

Envoyer le fichier Exercice3.md

(Question 11 optionnelle)

Nous ferons un corrigé ensemble par la suite.

Exercice - Git

GIT

Revenir en arrière sur un merge

La commande git reset

Répertoire local

(Workspace)

"Staging area"

Espace intermédiaire

Répertoire distant

(Serveur / Cloud)

Sauvegarder son workspace local

La commande git stash

Création stash

Réappliquer  une stash

Liste des stash

Supprimer une stash

Exercice complémentaire git

Jusqu'ici, nous n'avons travaillé qu'en local et avec notre staging area, maintenant nous allons faire en sorte que notre répertoire git soit lié à un répertoire distant que l'on pourra partager avec nos collaborateurs.

Le répertoire distant : Github

Répertoire distant

(Serveur / Cloud)

Nous allons faire un petit tour d'horizon de Github et des fonctionnalités proposées.

Workshop commun

Utilisation de GitHub pour la création du repository (dépôt distant) :

• Créer un compte puis un repository sur https://github.com/​
• Vous pouvez générer les clés ssh et les paramétrer sur votre PC (Agent ssh) et sur Github pour gérer votre accès (Envoyer liens doc)
• Récupérer le repository en local avec (le . a la fin permet de cloner dans le dossier courant) par exemple :

Je vous laisse un peu de temps pour revoir tout ça de votre côté.
Et ça vous permettra de prendre le temps de me poser des questions.

Créer une issue git
Push un bugfix

Associer la fermeture de l'issue lors de la pull request

Voyons un exemple...

Et voici un lien contenant les normes pour la gestion des versions

Collaborer et utiliser un répertoire distant

Vous allez faire un exercice simple d'utilisation de git, cette fois-ci, nous allons avoir besoin d'un répertoire distant avec GitHub.

Envoyer le fichier Exercice4.md

Nous ferons un corrigé ensemble par la suite.

Exercice - Git

GIT

Workflow - Git

Ajout de l'utilisation de la branche develop pour ne JAMAIS développer directement sur main.

On passe toujours par des PR (avec revue de code) entre les branches et develop, puis lorsque c'est testé et validé sur develop, on passe sur main également via une PR (avec revue de code).

Workflow plus complet d'utilisation de git (develop)

Faisons ensemble un workflow plus complet d'utilisation de git.

Nous allons ajouter la notion de branche develop à notre utilisation de git.

Exercice 5 - Git

Petite démo + Faire l'exercice 5

Outils graphiques

Il existe des outils graphiques pour représenter sous forme d'arbres vos projets git.

Par exemple, sourceTree est un des outils les plus utilisés pour utiliser git graphiquement.
Ce type de gestion peut permettre à des développeurs non expérimentés de travailler avec git plus facilement.

Bonnes pratiques Git

• Toujours add/commit/push quotidiennement,
   
• Toujours récupérer les sources à jour avant de relancer un nouveau développement,
   
• Créer une branche pour chaque nouvelle fonctionnalité / bug,
   
• Appeler la branche principale main,
   
• Bien séparer les développements réalisés par commit et par branche et les documenter (-m) + gitmoji
   
• Utiliser les Merge Request / Pull Request pour mettre du code sur main (et en profiter pour forcer la revue de code !)

• Nous avons abordés beaucoup de sujets git et vous avez en main les éléments nécessaires à la compréhension et l'utilisation de git. Mais dans ce programme nous ne couvrons pas deux aspects majeurs (mais optionnels) de git :
  • Réécriture d'historique git (history rewritting)​
  • Gitflow : Un workflow adapté pour une meilleure utilisation de git, plus commune aux utilisateurs et provoquant logiquement moins de soucis de fusion de branches.
    
    
    Plus d'informations & schéma sur  https://danielkummer.github.io/git-flow-cheatsheet/index.fr_FR.html

Intégration continue

L'intégration continue a pour objectif de faciliter la tâche aux développeurs pour gérer leur code source et réaliser les tâches tout en rajoutant une couche de sureté avec différents tests automatisés lors des merge (push, ...).

Pour notre CI, on va mettre en place un serveur qui va avoir pour objectif d'ajouter des étapes supplémentaires à notre validation de merge :

• Vérifications des tests automatisés (inclus la sécurité et qualité)
• Réalisation de revue de code manuelle
• Vérification syntaxique du code
• Gestion du build automatisé (générer les dépendances par ligne de commande, par exemple npm ci)

Intégration continue

Si on prend le cycle agile, par sprint l'idée et de pouvoir intégrer du code à notre gestionnaire de code source et réaliser des versions contrôlées de notre applicatif.

Lors de l'opération de merge (ou pull request) on va utiliser les informations mises en évidence dans github pour réaliser une revue de code avant de valider le merge ou le rebase sur la branche principale.

On pourra donc livrer régulièrement des nouvelles versions vérifiées par le "product owner" ou le "tech lead". 

Intégration continue

Grâce à un fichier .yml contenant les scripts et configurations à exécuter, on peut intégrer en continu les nouvelles sources. Même en cas d'update des dépendances.

L'intégration continue nous permet la gestion du build automatisé et donc mettre à jour les dépendances de la branche principale après un merge / pull request.

Elle permet également la vérification syntaxique (eslint par exemple), fiabilité, qualité et sécurité de votre application.

Si une erreur est détectée, le déploiement n'est pas possible !

• Nous allons faire un petit tour d'horizon des éléments
• Mais je vous propose de garder la Cheat_Sheet, elle vous sera utile ! 

GitHub Actions - YML

Ce que vous devez savoir, c'est qu'aujourd'hui de nombreux templates .yml existent pour toutes sortes de technos. Mais il faut très souvent l'adapter à son contexte.

Cheat Sheet

GitHub Actions

https://github.github.io/actions-cheat-sheet/actions-cheat-sheet.pdf

GitHub Actions - YML

Un petit exemple simple de CI...

Attention,
l'indentation est normée et provoque des erreurs si non respecté

Attention,
l'indentation est normée et provoque des erreurs si non respectée

Attention,
l'indentation est normée et provoque des erreurs si non respecté

on

Défini l'action déclencheur de la CI

Attention,
l'indentation est normée et provoque des erreurs si non respecté

jobs

Défini la plateforme d'exécution et les étapes de la CI

Démonstration rapide d'une CI

Nous allons voir rapidement comment utiliser GitHub et une CI simple pour analyser du code pour l'instant syntaxiquement, plus tard également en y intégrant des tests automatisés.

Sans rentrer trop dans les détails pour l'instant, c'est de la configuration et du travail de mettre en placer un "linter" efficace.

Prenons l'exemple SampleCIPython sur GitHub.

Workshop CI

Le but de ce workshop est de faire le workflow d'intégration continu le plus simple possible. Nous ferons une vraie intégration continue par la suite.

Workshop guidé (envoyer Workshop_CI_Simple_Pylint.md)

Les différents outils

Pour notre intégration continue, il faut également choisir les outils que l'on souhaite utiliser. Il en existe beaucoup trop pour les lister, mais en voici quelques-uns. 

• GitLab-CI
• GitHub-Actions  
• Buddy
• Jenkins
• Bamboo
• Circle-CI
• Azure DevOps
• Drone
• ...

Démonstration plus complète d'une CI

Nous allons voir rapidement comment utiliser GitHub et une CI un peu plus complète.

On va créer un workflow plus complet ensemble. On va avoir un l'installation des dépendances, un linter, des tests unitaires, un scan de dépendances.

Prenons l'exemple SampleCIPython sur GitHub.

Workshop complet CI

L'objectif final de ces tests est qu'ils soient intégrés à notre CI pour qu'ils soient passés automatiquement et nécessairement au vert pour pouvoir merger vers une branche principale.

Nos développements (et plus tard, nos éléments de conteneurisation avec Docker) sont testé et vérifié avant chaque déploiement.

Workshop guidé (Workshop_CI_Python_Guide.md)

Schéma récapitulatif d'une CI

https://www.dewep.net/realisations/en/continuous-integration-tools

Importance des tests

L'objectif premier de réaliser des tests sur son application est de limité d'envoyer des erreurs en production.

On va donc tester les développements réalisés à chaque changement et surtout avant chaque mise en production, ce qui rend l'application plus robuste mais ne la rend pas infaillible.

• L'utilisation d'une CI/CD force la réalisation de tests et surtout de s'assurer qu'ils passent,
• L'identification des problèmes est donc réalisée bien plus tôt et plus simplement car tout est cloisonné,
• Plus de productivité (si industrialisé) et rendement.

Les outils et s'adapter au contexte

Pour choisir quels outils utilisés pour réaliser nos tests, il faut une fois de plus se référer à la technologie et le contexte du projet.

Quelques exemples... (Mais il y'en a trop)

• Python : pytest
• Mobile : Graddle                                                                        
• .Net : NUnit,
• Java : JUnit,
• Web : PHPUnit, Jasmine (js)

Je vous invite à chercher ceux qui peuvent correspondre à vos technologies habituelles ou d'entreprise.

Différents types de tests

Il existe de nombreux tests différents, en voici les principaux et ceux que l'on va voir ensemble

• Tests unitaires
• Tests d'intégration
• Tests d'acceptation
• Tests de sécurité                    
       

Autres types de tests : Tests de montée en charge, tests d'exploitabilité, vérification de disponibilité immédiate…

Les tests unitaires

Un test unitaire est utilisé afin de pouvoir vérifier atomiquement que chaque élément de notre code. On va donc vérifier que le code produit bien le résultat attendu.

A savoir :

• Systématique pour chaque projet !
• Réfléchir efficacement à ce qui doit être testé, inutile de tester si 1 + 1 = 2.
• Test Driven Development (TDD): Méthodologie récente visant à démarrer ses développements par des tests unitaires

Présentation rapide pytest

Un test unitaire est utilisé afin de pouvoir vérifier atomiquement que chaque élément de notre code. On va donc vérifier que le code produit bien le résultat attendu.

pytest, c'est simple. C'est une dépendance qui permet de lancer des tests et donc tester votre code (unitairement et fonctionnellement, pour les autres tests, il faut d'autres éléments en général)

Fonctions à tester

Fichier de tests

Lancement de la commande et résultat (réussite)

Exercice

Ajouter quelques tests unitaires simple au workshop "fil rouge"

Adapter la CI

Envoyer le fichier Workshop_CI_Python_WithTests.md

Les tests d'intégration

Un test d'intégration permet de vérifier qu'il n'y a aucune régression sur l'existant suite aux modifications effectuées. (En termes de dépendances entre les éléments de votre appli)

A savoir :

• Systématique pour chaque projet ! 
• Plus complexe à mettre en œuvre car il doit vérifier les dépendances entre les éléments (Si une classe en utilise une autre par exemple ou un framework)
• Injection de dépendance (Inversion of Control)

Les tests d'acceptation

Les tests d'acception permettent de vérifier que les scénarios utilisateurs définis à l'expression de besoin respectent bien les étapes et le résultat attendu. 

A savoir :

• Systématique pour chaque projet ! (Au moins de manière implicite par les développeurs)
• Peuvent être définis dès la phase de spécification.
• Une méthodologie récente propose même des outils pour passer ces tests de manière automatisée ou en forçant les développeurs à les passer avant de pouvoir partager leurs développements.

• Outils manuels (souvent utilisé lorsque des équipes de recette sont définies pour le projet) : QCHP, Cucumber, il en existe surement énormément, mais ils font tous à peu près la même chose. On décrit un scénario avec des étapes et un résultat attendu, le recetteur doit respecter les étapes et faire un retour quant au résultat attendu directement sur l'outil.
  Tant qu'un scénario bloque, il n'est pas possible de passer de l'environnement de recette (ou pré-prod) à l'environnement de production.

• Behavior Driven Development : Ici, on parle de tests d'acceptation automatisés qui sont bien plus complexes à mettre en œuvre. On peut réaliser ça avec NUnit et Gherkin par exemple, ou Jest et GitLab...

Tests d'acceptation - suite

Les tests d'interface

Les tests d'interface vérifient que les développements sont cohérents et fonctionnent sur toutes les plateformes cibles (par exemple, dans le web on vérifie chaque navigateur)

A savoir :

• Systématique pour chaque projet ! (Au moins de manière implicite par le développeur)
• S'informer sur les plateformes cibles potentielles est important ici
• Il est aussi possible de les automatiser (Selenium) en passant paramétrant notre test avec les plateformes cibles et les vérifications sur ces plateformes.

Les tests de performances

Les tests de performances font exactement ce que leur nom indique, on parle aussi de tests de charge, tests d'usine,...

A savoir :

• PAS systématique pour chaque projet, utilisé en cas de besoin de performances. 
• On test si des fonctionnalités ont des temps de réponses suffisant ou si le réseau est de bonne qualité, on réalise des simulations d'utilisation massive pour s'assurer d'un service continue...

Intro monitoring

Pour les tests de performances, on utilise souvent différents outils de monitoring. Que l'on verra plus tard dans la formation... 😁

Conclusion sur les tests

Les tests sont une part importante des développements dans un projet et également une part importante de sa réussite.

L'estimation moyenne du pourcentage de temps (selon moi, j'ai cherché mais je n'ai pas trouvé d'étude) pris pour réaliser les tests sur un projet est compris entre 30% et 50% du temps !

D'où l'intérêt de la TDD, plus d'aller retour entre les développements et les tests, les tests sont effectués au départ et les développements s'adaptent pour y répondre !

Objectifs du déploiement

Comme expliqué, l'objectif premier est de livrer en production de manière automatisée après que notre CI valide ce qui doit être déployé. On doit également pouvoir monitorer (logger en continue) et alerter en continue.

Objectifs :

• Déployer sur un environnement de production en un clic (si possible)
• Monitorer en continue, c'est à dire logger en continue tout ce qui se passe en production et de manière la plus exhaustive possible !
• Alerter en continue, en cas de panne, d'incident, de tentative de brute force, etc... Un système d'alerte doit être mis en place (mail, alarme bruyante...)

Manuel VS Automatisé

• Eviter les erreurs qui arrivent systématiquement lors d'un déploiement manuel,
• Le déploiement manuel force à avoir des acteurs à chaque étape du déploiement, des vérifications, un timing a respecter,...,
• Tester son cycle de déploiement manuel est complexe et coûteux,
• Le déploiement manuel nécessite une documentation claire soumise à interprétation,
• Si un acteur d'une étape du déploiement manuel est indisponible, c'est la panique
• Notre objectif : Livrer rapidement et proprement au client !

Oui, j'avais envie de mettre un petit canard même s'il sert à rien

Workshop guidé

Petit exemple de mise en place d'un déploiement continue simple et automatisé avec GitHub Pages.

Voir exemple hello_world.

A vous de faire de même ! Vous devez effectuer la même chose (en js, ou sinon faite une simple page html, sans test tant pi, nous l'avons déjà travaillé !)

Vous pouvez repartir du repo github de la CI en Python effectuée précédemment. Ajouter un fichier index.html avec du html dedans et il suffit d'ajouter la partie github pages dans votre fichier .yaml afin d'intégrer le déploiement continu.
https://www.youtube.com/watch?v=hNRxn5sKOdE

Docker : La virtualisation allégée 

Docker est un outil de conteneurisation, adapté à toutes les plateformes, il va permettre d'utiliser la virtualisation afin de créer des conteneurs utilisant des images.

Il nous faut l'installer, ça va prendre un certain temps. Soit Docker Desktop (Windows, Mac) soit Docker via apt-get (Unix). Un outil en ligne existe : play-with-docker

A savoir, WSL a été intégré à Windows et Docker peut utiliser le WSL de Windows (pratique, mais gourmand !!).

L'utilité première est de pouvoir avoir un environnement défini et commun ainsi que pouvoir paramétrer ces environnements de manière sécurisée. On peut facilement simuler l'utilisation d'une machine Ubuntu, avoir un environnement Node, créer un serveur minecraft...

Installation docker :

• MacOS : https://docs.docker.com/desktop/setup/install/mac-install/
• Linux (Engine) : https://docs.docker.com/engine/install/
• Linux (Docker desktop) : https://docs.docker.com/desktop/
• Windows (WSL 2) : https://docs.docker.com/desktop/setup/install/windows-install/

Installation de Docker

Docker : La virtualisation allégée 

Les commandes Docker

Lister les conteneurs :

    docker ps -a

Lister les images :

    docker image ls

Builder un container :

    docker build -t image-name

Démarrer un conteneur :

    docker run -p 8080:2368 ghost 

Démarrer un conteneur avec un volume :

    docker run -v localFolder:containerFolder containerName

Supprimer un conteneur :

    docker rm -f containerName (ou containerId)

Supprimer une image :

    docker rmi imageName (ou imageId)

Démarrer une invite de commande dans le conteneur :     

    docker exec -it containerName bash

Docker : Cheat Sheet

Voici une feuille de triche contenant toutes les commandes docker, que ce soit pour du docker simple, du docker-compose ou du dockerfile :

https://dockerlabs.collabnix.com/docker/cheatsheet/

Docker : Petite démo

On va faire un exercice ensemble sur Docker pour nous familiariser avec l'outil. 

Exemple en workshop guidé avec MySQL.

Utilisation des commandes :

Docker : Première utilisation

Démarrez par suivre les 4 tutos de docker dans "Learning Center". 

Ensuite, faites le tuto par rapport à la technologie de votre choix.

Puis faire l'exercice en ligne de commande suivant.

Envoyer le fichier d'exercice démarrer un conteneur avec docker

Run-a-container.md

Docker : Première utilisation

Exercice avec ports et mise en place de volume ainsi que copie de fichiers via lignes de commande

Work-with-containers.md

Docker : Dockerfile

Créer sa propre image en utilisant un Dockerfile.
Ce fichier va permettre d'utiliser une ou plusieurs image pour créer votre propre conteneur.

• FROM (nom d'image à utiliser en tant que référence. Exemple : from debian / from nodejs,...)
• WORKDIR : Espace de travail défini dans le conteneur
• COPY : Copier des éléments locaux dans le conteneur
• RUN uneCommande (sur le serveur directement)
• CMD UneEtapeDeBuild (npm ci, npm install...)
• EXPOSE : Ouvrir un port pour pouvoir accéder au conteneur depuis l'extérieur (actuellement, depuis votre PC)

Builder un conteneur : docker build -t <tag> .

Démarrer un conteneur : docker run <tag>

Dockerfile : Petite démo pour comprendre

Un de mes anciens étudiants a fait une image docker via un Dockerfile permettant de de gérer tous les prérequis nécessaires pour démarrer un conteneur ubuntu avec directement gameshell (un petit jeu très sympa pour apprendre les commandes unix) via un conteneur, je vous montre tout ça !

(j'ai un peu tout refait, mais je donne les crédits à l'idée à cet étudiant de Reims quand même)

Exemple de mise en place

Getting started with Docker :

On va clone git@github.com:docker/getting-started.git 

Ensuite, on va ouvrir le dossier app avec VSCode.

On va créer un fichier Dockerfile :

Puis build le container docker build -t getting-started  . (Pensez à être dans le dossier app & n'oubliez pas le . dans la commande)

Et on finit par run le container docker run -p 3000:3000 getting-started Puis on va sur localhost:3000/

https://docs.docker.com/get-started/02_our_app/

Premier exercice docker

(Python & Dockerfile)

Envoyer le fichier Workshop_Docker_Counter_simple.md

Docker : Docker compose

Docker compose nous permet d'avoir une CI dans Docker. On commence à savoir ce qu'est une CI, alors prenons directement un exemple. 

   1. Vérifier que vous possédez docker compose (Inclus avec                  Docker Desktop, mais à installer manuellement sur Unix) 

                  docker-compose --version

   2. Clonez ce repo :

                  git clone https://github.com/nigelpoulton/counter-app .

   3. Utilisez la commande : 

                  docker-compose up

   4. Rendez-vous directement sur : 

                  http://localhost:5000/

   5. Magique n'est-ce pas ? Rien à faire à part une commande pour démarrer un projet ! 

Docker : Docker compose

• build: On dit à Docker d'utiliser le Dockerfile présent à la racine comme image.

• command: python app.py On run l'app python.                               

• ports: On dirige vers le port souhaité et l'app écoute sur ce port.  

• networks: On expose le network sur lequel on attache les services du conteneur.

• volumes: On dit à Docker de monter le counter-vol (source:) vers le container (target:)

Docker : Docker compose

Quelques commandes utiles :

• docker-compose up : Démarre un conteneur en utilisant les infos dans le fichier docker-compose.yml
• docker-compose build : Build un conteneur sans le lancer, permet de pré-charger tout ce qui est nécessaire au démarrage du conteneur
• docker-compose restart : Redémarre un conteneur
• docker-compose down : Stop et supprime un conteneur
• docker-compose stop : Stop un conteneur
• docker-compose rm : Supprimer un conteneur (il doit d'abord être stoppé)
• docker-compose ps : Voir les statuts du / des conteneurs
• docker-compose top : liste les processus 

Workshop

Workshop plus complet d'utilisation de Docker compose Workshop_Docker_Counter_compose.md

Workshop Docker

Envoyer le workshop WS_CD_Docker_Minecraft.docx

Nous ne ferons pas ce workshop car il est très gourmand en ressources et pose souvent problème, mais on peut regarder rapidement ce qu'il faut mettre en place et je vous donnerai accès au repo de mon corrigé.

Docker : CI avec Docker et Github Actions

Documentation et mise en place d'une CI / CD avec Docker 

Suivez la documentation présente ici pour mettre en place un déploiement avec Docker

CI/CD avec docker-compose (& github actions)

Demo Docker / Render

Suivre le workshop guidé Deploy_with_render.md

On va faire ce workshop ensemble, je n'ai pas réussi à prendre le temps de l'appliquer avec du python, on a trop d'autres notions à aborder...

Mais le principe reste littéralement le même :

• Un Dockerfile front pour le visuel
• Un Dockerfile back pour l'API
• Une base de données directement configurée dans Render avec postgresql

Docker : Docker c'est vaste !!

• Docker Swarm : Permet d'orchestrer les conteneurs afin de pouvoir les coupler facilement et donc réaliser des sous ensembles plus petits.

      Ces conteneurs sont donc plus facilement réutilisables dans          un autre projet.

• Docker Networking : Permet d'améliorer la qualité des échanges réseaux nécessaires à une infrastructure contenant plusieurs conteneurs devant communiquer les uns avec les autres (vraiment dans les grandes lignes, car ça englobe aussi le paramétrage, la sécurité des échanges etc...)

• Docker overlay Networking: Pour être plus outillé sur la partie sécurité avec docker.

Schéma récapitulatif DevOps

On va revoir le schéma récapitulatif de DevOps avec ce que l'on connait et ce que l'on a mis en place jusqu'ici

Conclusion déploiement en continue

Nous mettons en place un déploiement continue lorsque de nombreux déploiement sont à prévoir.
Cette mise en place de CI / CD a un coût, mais il faut aussi savoir que déployer manuellement a également un coût et est source d'erreur. Aujourd'hui, toute application tend à viser le déploiement continue et automatisé.

Les objectifs finaux à retenir sont surtout le monitoring, l'alerte en continue et le paramétrage des données constantes des environnements. 

Sysadmin & DevOps

Le sysadmin a un rôle critique dans le bon déroulement d'une approche DevOps pour un projet :

• Réalise et configure l'infrastructure
   

• Automatisation du processus de déploiement                             
   

• Monitorer et logger
   

• Sécurité
   

• Collaboration

Réaliser et configurer l'infrastructure

Cette première étape est primordiale pour le bon fonctionnement d'un projet à moindre coût.

• Définir les besoins en infra
   

• Choisir un outil de provisionnement : Terraform, CloudFormation, Ansible,...
   

• Ecrire l'infrastructure as code
   

• Tester et valider l'infra
   

• Configurer
   

• Amélioration continue

Tuto

Terraform

https://developer.hashicorp.com/terraform/tutorials/azure-get-started

https://developer.hashicorp.com/terraform/tutorials/docker-get-started

Automatiser les processus

L'automatisation des processus est également une grande étape pour le bon fonctionnement DevOps

• Choisir un outil de déploiement : Github Actions / Docker, Jenkins, GitLab CI/CD, AWS CodeDeploy, Azure DevOps...
   
• Ecrire les scripts de déploiement

Tuto

Jenkins

https://medium.com/@gustavo.guss/quick-tutorial-of-jenkins-b99d5f5889f2

Ansible

https://docs.ansible.com/ansible/latest/getting_started/index.html

https://www.redhat.com/en/interactive-labs/ansible?extIdCarryOver=true&sc_cid=701f2000001OH7YAAW

Exercices et ressources supplémentaires 

https://github.com/bregman-arie/devops-exercises/blob/master/topics/ansible/README.md

Monitorer et logger

Nous l'avons déjà vu, mais pour faire du DevOps, il est nécessaire de monitorer et logger le plus de choses possibles afin de suivre la vie du projet

• Choisir un outil de monitoring et de logs : Prometheus, ELK stack, Grafana,...
   

• Configurer l'outil

Tuto

Grafana

https://earthly.dev/blog/running-grafana-in-docker/

https://www.youtube.com/watch?v=UG_bZzhhnbc

Tester et valider

Nous l'avons déjà vu, mais pour faire du DevOps, il est nécessaire de tester l'infrastructure du projet afin de s'assurer de son bon fonctionnement

• Choisir un outil : Test Kitchen, Serverspec, Packer, JMeter, k6...                                                          

• Ecrire les tests

Documentation

Serverspec

https://serverspec.org/?utm_source=buffer&utm_campaign=Buffer&utm_content=bufferd8969&utm_medium=google

Sécurité

Nous en avons aussi brièvement parlé, mais la sécurité est un aspect primordial pour une application aujourd'hui. DevOps contient cette partie.

• Les tests à réaliser : Scanneur de sécurité, système de détection d'intrusion, scanneur de vulnérabilité,... 

• Sécuriser l'infrastructure : Suivre les bonnes pratiques telles que le renforcement des serveurs (fermé le maximum de choses), chiffrer les données, utiliser des firewalls, mise en place du Secure By Design...

• Implémenter des tests de sécurité : Identification des vulnérablités, problèmes de configurations, etc... Par exemple, SonarQube et Checkmarx sont des outils qui peuvent effectuer en partie ces tests de manière automatisée.

• Intégrer l'outil dans le process de déploiement : Mise en place de l'outil dans une CI afin de lancer des tests de sécurité.

• Monitorer la sécurité en continue

Démo

Mise en place d'une analyse sécurité et qualité avec SonarCloud

Gameshell

Un premier exercice vous permettra de travailler les commandes Unix sous forme de jeu.

Envoyer gameshell_Docker.md

Exercice - Unix

Unix

The Unix game

Un second exercice vous permettra de travailler les commandes Unix sous forme de jeu.

Accessible via ce lien :

https://www.unixgame.io/unix50

Exercice - Unix

Unix

Ensemble de commandes à trouver

Voici un fichier contenant un ensemble de commandes que vous devez trouver !

Un peu moins guidé et plus complexe que les deux exercices précédents

Envoyer Exercices_Shell.md

Exercice - Unix

Unix

Exercices DevOps

Le lien suivant contient de nombreux labs permettant de travailler vos compétences de DevOps, une partie gratuite déjà bien fournie vous permettra d'apprendre !

https://studio.kodekloud.com/labs

Exercices DevOps

Le lien suivant contient de nombreux exercices sur tout ce que nous avons pu aborder durant la formation et bien plus encore...

Je vous conseil de le garder et d'y passer de temps en temps pour appréhender de nouveaux sujets

Exercices DevOps

Partie pratique

Worskhop d'une demi-journée de mise en place d'une CI / CD avec les technologies de votre choix.
L'idée est d'avoir une CI / CD complète et un environnement complètement automatisé avec tout ce que l'on a vu.

Envoyer le sujet WS_CI_CD_Full.docx

(après c'est fini)