CI/CD

Intégration continue / Déploiement continu

https://slides.com/benjichaz/but3-ci-cd

Qui suis-je ?

Benjamin Chazelle, 27 ans

Passionné d'informatique 💻

de musique 🎹 🎸et de cuisine 🍪

IUT Bourg, DUT Info 2016

INSA Lyon, Dép. Info 2019

www.chazelle.pro

Qui suis-je ?

Ingénieur en développement

spécialisé front-end

Chez Matawan

Éditeur de logiciel pour le monde du transport de voyageur

www.matawan-mobility.com

welcometothejungle.com/fr/companies/ubitransport

Module

8 heures

Aujourd'hui

Évaluation par DS (QCM)

iut@chazelle.pro

06 51 23 51 39

Contenu

Intégration continue

Déploiement continu

Projet CircleCI + IBM Cloud

Objectifs

Comprendre ce qu'est la CI/CD

Mettre en place une CI/CD

On discute ? =)

https://interactly.glitch.me/

Comment ça va ?

Comment se passe l'alternance ?

Avez-vous déjà été confronté à la CI/CD ?

Votre aisance en Admin système / Bash

Avez-vous déjà travaillé avec

l'un de ces services ?

Any question ?

CI/CD

Définition de la CI/CD

Approche de développement logiciel où les changements de code sont régulièrement et systématiquement intégrés et testés (CI: Intégration continue) avant d'être automatiquement déployés (CD: Déploiement/Livraison continu/e) dans un environnement de production, permettant ainsi des mises à jour fréquentes et fiables du logiciel.

Dev

Ops

Philosophie de collaboration menant vers l'automatisation

Automatisation de l'intégration et du déploiement

Importance de la CI/CD

Diminue les risques en identifiant et corrigeant les problèmes rapidement.
Favorise la qualité du code et facilite la mise en production régulière de fonctionnalités.
Accélère le cycle de développement en réduisant les retards dus aux intégrations complexes.

CI : Plan

Définir les attendus techniques et fonctionnels de la tâche / du projet.

Qui ? Product Manager, Product owner, ...

CI : Code

Ajouter l'incrément de code nécessaire à la réalisation de la tâche/projet.

Qui ? Développeur

Comment ? Système de gestion de version (git, ...)

Note: Dès cette étape, au push/au merge, ici, on peut déjà avoir déjà des vérifications automatiques CI (tests unitaires, lint, compilation, ...)

CI : Build

Compiler ou assembler le code pour créer le produit final. En plus du code buildé, cette étape peut produire des artefacts (rapport de compilation, ...)

Qui ? Processus automatiques CI à la fusion d'un incrément

Comment ? Pipeline CI (GitHub Actions, CircleCI, Jenkins, Travis CI ...), compilateurs / transpileurs / bundlers (Webpack, Rollup, ...)

CI : Test

Vérifier le fonctionnement du produit afin de détecter et corriger les erreurs éventuelles.

Qui ? Humains et processus automatiques

Comment ? Tests d'intégrations (Selenium, Cypress, Puppetter, ...)

CD : Release

Persister le code (et/ou le build) du produit pour être prêt à être mis à disposition .

Qui ? Processus automatiques CD

Comment ? Git release, registry (npm, composer, ...)

CD : Deploy

Mettre le produit ou le service sur un environnement à disposition des utilisateurs (production ou autre).

Qui ? Processus automatiques CD

Comment ? Transfère de fichier (FTP, SSH, ...)

CD : Operate

Gérer et maintenir le produit ou le service en fonctionnement.

Qui ? DevOps

Comment ? Instances serveur (AWS EC2, Azure VM, Google Compute Engine, ...)

CD : Monitor

Observer et contrôler le produit ou le service pour garantir son bon fonctionnement.

Qui ? DevOps

Comment ? Outils de monitoring (Grafana, New Relice, Azure Monitor, Google Cloud Monitoring, ...)

Automatisation

Pour aller plus vite
Pour être plus fiable, éviter les erreurs humaines
Pour concentrer son énergie, son temps et son argent ailleurs
Pour être plus qualitatif, détecter/anticiper les erreurs

Mettre en œuvre par des processus qui se lancent, s’exécutent et se terminent tout seul.

Architecture des processus

CircleCI	Pipeline > Workflow > Job > Step
GitHub Actions	Workflow > Job > Step > Action
Jenkins	Pipeline > Job > Build
GitLab CI/CD	Pipeline > Job > Stage
Travis CI	Build > Job > Stage
Microsft Azure DevOps	Pipeline > Job > Step
Google Cloud Build	Build > Step

CircleCI : Workflow

# Job : Tests unitaires

Step 1 : npm install
Step 2 : npm run unit-tests

# Job : Type-checking

Step 1 : npm install
Step 2 : npm run type-check

# Job : Lint

Step 1 : npm install
Step 2 : npm run lint-check

Workflow : CI Frontend

Trigger

Success / Fail

Les jobs d'un workflow s’exécutent en parallèle par défaut,

toutefois, on peut les configurer pour être séquentiels

Déclenché par git ou manuellement

CircleCI : Pipeline

Workflow : CI Frontend

Workflow : CI Backend

Workflow : CD

Pipeline

Success / Fail

Success / Fail

Success / Fail

Trigger

Un workflow peut être conditionné

Par exemple sur une branche

Les workflows s’exécutent en parallèle par défaut,

toutefois, on peut les configurer pour être séquentiels

CircleCI : Trigger

Push trigger : Push sur une branche ou n'importe quelle branche du repository
Pull Request trigger : Pull request ouverte sur le repository
Approval trigger : Pull request approuvé sur le repository
Scheduled trigger : Planifié à une heure ou un intervalle de temps régulier
API trigger : Via CircleCI API.
Manual trigger : Via le dashboard CircleCI dashboard or via API.
Webhook : Via un l'appel d'une URL HTTP

CircleCI : Status

Workflow : CI Frontend

Workflow : CI Backend

GitHub Check

Trigger

git push sur

feat/add-button

Success

Fail

Bloqué le merge d'une Pull Request sur GitHub

Success équivaut à un processus (au sens UNIX du terme) qui retourne un code de retour 0. Tout autre status fera tomber le job et son workflow en Fail

(Runner)

# Job : Tests unitaires

Step 1 : npm install
Step 2 : npm run unit-tests

Logiciel

Matériel

Les services CI/CD offrent souvent la possibilité de choisir dans quel environnement exécuter les pipelines CI/CD.

Conteneur, machine virtuelle...

CPU, GPU, Internet ...

CircleCI : Step

# Job : Tests unitaires

Step 1 : npm install
Step 2 : npm run unit-tests

Partie exécutante de bas niveau du processus automatique.

S'appuie sur un approche script :

Ligne de commande
Variable d’environnement (caché)
Répertoire de travail
Flux de données standard (stdin, stdout, stderr)
Code de retour

Git flow

main           ────o───────────────────────o──────  Lors d'un git push/merge : CD  
                    \                     /   
                     \                   /  
develop        ───────o───o───o─────────o─────────  Lors d'un git push/merge : CI  
                               \       /   
                                \     /  
feat/***       ──────────────────o───o────────────  Lors d'un git push : CI

Méthodologie de gestion de branches pour les dépôts Git. Elle propose un modèle avec des branches spécifiques pour les fonctionnalités, les versions et la maintenance, facilitant le développement collaboratif et la gestion des releases.

GitHub : Protection de branche

GitHub permet de définir des règles de protection sur les branches du repository avec un nom ou un pattern de nom donné

Cela peut servir à :

Exiger un nombre de relecteur sur les Pull request
Exiger que toutes ou certaines vérifications CI soient au vert
Restreindre le mode d'intégration (git merge, rebase, squash)
Restreindre les personnes qui ont le droit d'écriture sur une branche
...

Release

Une "release" est une version précise d'un logiciel à un moment donné. Matérialisé par une persistance du code (et/ou de son build) à un endroit donné (GitHub release, registry npm, ...)

Gestion du code : Facilite la gestion des différentes versions du logiciel et le suivi des changements apportés.
Stabilité et maintenance : Permet de figer une version stable pour les tests et la maintenance.
Communication : Aide à communiquer les fonctionnalités ou corrections incluses dans chaque version.

Version sémantique

42.10.27

Major

Minor

Patch

Majeur : Changements majeurs, pas toujours rétrocompatibles (breaking change)

Mineur : Ajout de fonctionnalités sans changer la rétrocompatibilité.

Patch : Corrections de bugs ou améliorations mineures sans ajout de nouvelles fonctionnalités.

Incrément de version

42.10.27

Major

Minor

Patch

Prochaine version majeur : 43.0.0

Prochaine version mineur : 42.11.0

Prochaine version patch : 42.11.28

Déploiement via SSH

SSH, ou Secure Shell, est un protocole de communication sécurisé utilisé pour accéder à distance à des ordinateurs et pour exécuter des commandes de manière sécurisée sur des réseaux.

SSH permet également le transfert de fichier de manière sécurisé, ce qui en fait un protocole de choix pour les équipes DevOps en charge de gérer les déploiements.

Le plus souvent, SSH est authentifié à l'aide d'une paire de clés asymétrique : une clé privée (gardée par l'utilisateur) et une clé publique (partagée sur les serveurs) pour une authentification sécurisée sans transmettre de mot de passe.

Un mode username/password existe, mais il n'est pas recommandé.

Déploiement et lien symbolique

(symlink)   current/

(directory) releaseA/

Déploiement et lien symbolique

(symlink)   current/

(directory) releaseA/

(directory) releaseB/

scp /cd_runner/releaseB root@remote:releaseB

Déploiement et lien symbolique

(symlink)   current/

(directory) releaseA/

(directory) releaseB/

ssh root@remote "rm current"
ssh root@remote "ln -s releaseB current"

Déploiement et lien symbolique

(symlink)   current/

(directory) releaseB/

ssh root@remote "rm releaseA"

Déploiement et lien symbolique

Cette approche permet de minimiser les risques de pannes en cas de problèmes lors du transfert des fichiers.

Il permet également de drastiquement réduire le temps où l'application n'est plus disponible.

Projet : Todo App

Mettre en place une CI/CD pour automatiser les vérifications à l'intégration, ainsi que la release et le déploiement d'un petit projet Vue.js/Express.

Avec GitHub, CircleCI et IBM Cloud.

Le projet n'est pas noté mais...

github.com/benjaminchazelle/learn-ci-cd

169.45.64.59:5173

Le projet et le cycle CI/CD

Release du code

Pas de réel tests

d'intégration

release

Aspects Operate et Monitor absents

Release du build

via SSH

Pour des raisons de simplicité

Tout travail mérite salaire

Si vous allez au bout de la mise en place de la CI/CD

Devoir surveillé : QCM

Chaque question a UNE SEULE bonne réponse.

Chaque réponse juste rapporte un point, chaque réponse fausse soustrait un point, et chaque réponse non répondue ne rapporte ni ne soustrait de point.

Pour chaque question, ÉCRIRE la lettre de la réponse correcte à vos yeux en dessous du numéro de la question, dans le tableau-ci dessous.

Q	1	2	3	4	5	6	7	8	...
R	A	B	C	D	A	B	C	D	...

Matawan recrute

www.matawan-mobility.com

welcometothejungle.com/fr/companies/ubitransport

Mâcon ou Lyon

Télétravail possible

Cœur de métier sympa

Équipes bienveillantes et compétentes

Merci pour votre attention

A vous de jouer

BUT2 - CI/CD

By Benji Chaz

CI/CD

Qui suis-je ?

Qui suis-je ?

Module

Contenu

Objectifs

On discute ? =)

Comment ça va ?

Comment se passe l'alternance ?

Avez-vous déjà été confronté à la CI/CD ?

Votre aisance en Admin système / Bash

Avez-vous déjà travaillé avec

l'un de ces services ?

Any question ?

CI/CD

Définition de la CI/CD

Importance de la CI/CD

CI : Plan

CI : Code

CI : Build

CI : Test

CD : Release

CD : Deploy

CD : Operate

CD : Monitor

Automatisation

Architecture des processus

CircleCI : Workflow

CircleCI : Pipeline

CircleCI : Trigger

CircleCI : Status

(Runner)

CircleCI : Step

Git flow

GitHub : Protection de branche

Release

Version sémantique

Incrément de version

Déploiement via SSH

Déploiement et lien symbolique

Déploiement et lien symbolique

Déploiement et lien symbolique

Déploiement et lien symbolique

Déploiement et lien symbolique

Projet : Todo App

Le projet et le cycle CI/CD

Tout travail mérite salaire

Devoir surveillé : QCM

Matawan recrute

Merci pour votre attention

BUT2 - CI/CD

More from Benji Chaz