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

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

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.

CI

CD

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

CD

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

CD

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

CD

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, ...)

CI

CD

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, ...)

CI

CD

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, ...)

CI

CD

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, ...)

CI

CD

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, ...)

CI

CD

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

  1. Push trigger : Push sur une branche ou n'importe quelle branche du repository

  2. Pull Request trigger : Pull request ouverte sur le repository

  3. Approval trigger : Pull request approuvé sur le repository

  4. Scheduled trigger : Planifié à une heure ou un intervalle de temps régulier

  5. API trigger : Via CircleCI API.

  6. Manual trigger : Via le dashboard CircleCI dashboard or via API.

  7. 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...

Le projet et le cycle CI/CD

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

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

Made with Slides.com