Continuous Integration/

Continuous Deploy
(CI/CD)
Sonia BEN AISSA
Plan

• Etapes de déploiement
• Automatisation CI/CD
• Intégration continue (CI)
• Déploiement continu (CD)
• Bénéfices du CI/CD

2
Etapes de déploiement

3
 Etapes de déploiement

• Plusieurs mois entre deux nouveauté majeurs

→dans le contexte concurrentiel actuel, c’est très long

• Long délai vu l’utilisation d’un processus séquentiel

Entre les équipes de développement et les équipes d’Ops
(Production)

4
Etapes de de déploiement

Test et
Développement Recette Mise en Prod
Intégration

5
Etapes de déploiement

Test et
Développement Recette Mise en Prod
Intégration

A chaque étape, il faut:

• Synchroniser entre les différents acteurs,
• Coordonner leur planning,
• Planifier leur actions à mettre en place.

→ Il faut automatiser ce process 6

Automatisation CI/CD

Test et
Développement Recette Mise en Prod
Intégration

Intégration continue (CI) Déploiement continu (CD)

7
Automatisation CI/CD

Test et
Développement Recette Mise en Prod
Intégration

Intégration continue (CI) Déploiement continu (CD)

→ Automatiser les opérations de développement et de déploiement

8
 Automatisation CI/CD

→ Pipeline CI/CD Vise à :

1. Supprimer les activités humaines manuelles

2. Automatiser autant de possibles les différentes étapes pour
pousser le développement jusqu’à la mise ne production.

9
Intégration continue (CI)

Serveur d’intégration Repository

10
Dépôt SCM
Déploiement continu (CD)

Repository
Production

11
Déploiement continu (CD)

Repository
Production

12
Déploiement continu (CD)

Repository
Production

13
Déploiement continu (CD)

Repository
Production

Infrastructure as a Code 14
Processus Automatisé

Intégration
Déploiement
continue
continu (CD)
(CI)

15
 Bénéfices du CI/CD

Time To Market
Nouvelle Idée Concrétisation sur le
marché

16
Bénéfices du CI/CD

17
What is DevOps?

18
GitLab CI/CD
Sonia BEN AISSA
CI/CD

20
GitLab CI/CD - Introduction
• CI/CD est une méthode continue de développement logiciel, dans
laquelle vous créez, testez, déployez et surveillez en permanence les
modifications itératives du code.

• Ce processus itératif permet de réduire le risque de développer un

nouveau code basé sur des versions précédentes boguées ou
défaillantes. GitLab CI/CD peut détecter les bugs dès le début du cycle
de développement et contribuer à garantir que tout le code déployé
en production est conforme aux normes de code établies, et ceci de
la façon la plus automatisée possible.

21
GitLab CI/CD – Le fichier .[Link]
• Pour utiliser GitLab CI/CD, vous commencez avec un fichier .gitlab-
[Link] à la racine de votre projet. Dans ce fichier, vous spécifiez la liste
des actions que vous souhaitez faire, comme tester et déployer votre
application. Ce fichier est écrit dans le format YAML et possède sa
propre syntaxe.

• Vous pouvez nommer ce fichier comme vous le souhaitez, mais

.[Link] est le nom le plus courant. Utilisez l'éditeur de pipeline
pour modifier le fichier .[Link] et tester la syntaxe avant de
valider les modifications.

22
GitLab CI/CD – Le fichier .[Link]
• Dans le fichier .[Link] vous spécifiez des instructions pour
GitLab CI/CD.
• La structure et l'ordre des tâches que le runner doit exécuter.
• Les décisions que le runner doit prendre lorsque des conditions
spécifiques sont rencontrées.
• Dans la barre latérale gauche, sélectionnez "Code > Repository" .
• Au-dessus de la liste des fichiers, sélectionnez la branche ciblée. Si
vous n'êtes pas sûr, laissez master ou main. Sélectionnez ensuite
l'icône plus (+) et « New file »

23
GitLab CI/CD – Les pipelines
• Les pipelines constituent le composant de premier niveau de l’intégration, de la
livraison et du déploiement continus.
• Les pipelines comprennent :
• Des tâches (jobs), qui définissent ce qu'il faut faire. Par exemple, les jobs qui
compilent ou testent du code.
• Étapes/Etages (stages), qui définissent quand exécuter les jobs. Par exemple, les
stages qui exécutent des tests après les stages qui compilent le code.
• Les jobs sont exécutés par des runners. Plusieurs jobs dans le même stage sont
exécutés en parallèle, s'il y a suffisamment de runners simultanés.

24
GitLab CI/CD – Les pipelines
• Si tous les jobs d'un stage réussissent, le pipeline passe au stage suivant.
• Si un job d'un stage échoue, le stage suivant n'est pas (généralement) exécuté et le pipeline se
termine prématurément.
• En général, les pipelines sont exécutés automatiquement et ne nécessitent aucune intervention
une fois créés. Cependant, il existe également des moments où vous pouvez interagir
manuellement avec un pipeline.
• Un pipeline typique peut comprendre quatre stages, exécutés dans l’ordre suivant :
• Un build stage, avec un job qui s'appelle compile.
• Un test stage, avec deux jobs qui s'appellent test1 and test2.
• Un staging stage, avec un job qui s'appelle deploy-to-stage.
• Un production stage, avec un job qui s'appelle deploy-to-prod.

25
GitLab CI/CD – Les pipelines

26
GitLab CI/CD – Les pipelines
• Vous pouvez trouver les exécutions des pipelines en cours ou
terminées sous la page Build > Pipelines de votre projet. Vous pouvez
également accéder aux pipelines pour une demande de fusion en
accédant à l'onglet Pipelines.
• Les pipelines peuvent également être exécutées manuellement.

27
GitLab CI/CD – Les pipelines

28
GitLab CI/CD – Les runners
• Les runners sont les agents qui exécutent les jobs (tâches/actions/instructions).
• Ces agents peuvent s'exécuter sur des machines physiques ou des instances virtuelles.
• Dans votre fichier .[Link], vous pouvez spécifier une image de conteneur que vous
souhaitez utiliser lors de l'exécution du travail.
• Le programme d'exécution charge l'image et exécute le travail soit localement, soit dans le
conteneur.
• Des runners partagés gratuits peuvent être disponibles.
• Vous pouvez enregistrer vos propres runners sur [Link] si vous le souhaitez.
• Si vous n'utilisez pas [Link], vous pouvez :
• Enregistrez des exécuteurs ou utilisez des exécuteurs déjà enregistrés pour votre instance autogérée.
• Créez un exécuteur sur votre ordinateur local.

29
GitLab CI/CD – Les runners
• Accessibilité des runners

30
GitLab CI/CD – Les runners
• Création d’un runner
• Récupérer le token du projet/groupe
• Le token permettra au runner de s’authentifier au moment de sa création.
• Grâce à cela, Gitlab prend connaissance de son existence et les jobs
pourront être redirigés vers lui.
• Pour l’obtenir, il faut vous rendre à cette adresse :
[Link]
• Utilisation ici d’une installation sur site de GitLab

31
GitLab CI/CD – Les runners
• Vous pouvez le copier
à partir de la section «
Runners » :

32
GitLab CI/CD – Références
• Use CI/CD to build your application
• [Link]

• Mettre en place une démarche CI/CD avec Gitlab – Découverte

• [Link]
partie-1/

33
GitLab Pipline
Sonia BEN AISSA
GitLab : Premier Exemple
stages:
- stage_1
- stage_2

sample_stage1:
tags:
- CI
- Devops
stage: stage_1
script:
- echo "First Job"

sample_stage2:
tags:
- CI
- Devops
stage: stage_2
script:
- echo "First Job"

35
GitLab : Premier Script CI stages:
- build
- test
- deploy

build-job:
stage: build
script:
- echo "build job"

test-job:
stage: test
script:
- echo "test job"

deploy-job:
stage: deploy
script:
- echo "deploy job"

36
GitLab : Before_script
stages:
- build
- test
- deploy

build-job:
stage: build
before_script:
- echo "Before Script"
script:
- echo "build job"

test-job:
stage: test
before_script:
- echo "Before Script test"
script:
- echo "test job"

deploy-job:
stage: deploy
before_script:
- echo "Before Script deploy"
script:
- echo "deploy job"
37
GitLab : After_script stages:
- build
- test
- deploy

build-job:
stage: build
before_script:
- echo "Before Script build"
script:
- echo "build job"
after_script:
- echo "after Script build"

test-job:
stage: test
before_script:
- echo "Before Script test"
script:
- echo "test job"
after_script:
- echo "after Script test"

deploy-job:
stage: deploy
before_script:
- echo "Before Script deploy"
script:
- echo "deploy job"
after_script:
- echo "After script deploy" 38
GitLab : Variables
stages:
- "build"
- "test"

variables:
GLOBAL_VAR: "A global variable"

Build:
stage: build
variables:
JOB_VAR: "A job variable"
script:
- echo "Variables are '$GLOBAL_VAR' and '$JOB_VAR'"

Test:
stage: test
script:
- echo "Variables are '$GLOBAL_VAR' and '$JOB_VAR'"

39
GitLab : Predefined Variables

40
[Link]
GitLab : Predefined Variables
stages:
- "build"
- "test"

variables:
GLOBAL_VAR: "A global variable"

Build:
stage: build
variables:
JOB_VAR: "A job variable"
script:
- echo "Variables are '$GLOBAL_VAR' and '$JOB_VAR'"
- echo " Le pipeline ID est $CI_PIPELINE_IID"

Test:
stage: test
script:
- echo "Variables are '$GLOBAL_VAR' and '$JOB_VAR'"
41
GitLab : Secret Variables
stages:
- "build"
- "test"

variables:
GLOBAL_VAR: "A global variable"

Build:
stage: build
variables:
JOB_VAR: "A job variable"
script:
- echo "Variables are '$GLOBAL_VAR' and '$JOB_VAR'"
- echo " Le pipeline ID est $CI_PIPELINE_IID"
- echo "$SECRET_VAR"

Test:
stage: test
script:
- echo "Variables are '$GLOBAL_VAR' and '$JOB_VAR'"

42
GitLab : Secret Variables

43
 GitLab : Artifacts
Les "artifacts" dans le contexte de l'intégration continue et de la livraison continue (CI/CD):

--> Les fichiers générés lors de l'exécution d'un pipeline ou d'un job.
Ces fichiers sont souvent des résultats ou des artefacts de la construction, du test ou d'autres étapes du
processus de développement.

Dans GitLab CI/CD, les "artifacts" sont des fichiers ou des archives générés par un travail qui sont stockés et
persistés après l'exécution du travail. Ces artefacts peuvent être utilisés dans d'autres travaux du pipeline ou
téléchargés en tant que résultats du pipeline.

44
 GitLab : Artifacts
job:
script:
- make build
artifacts:
paths:
- binaries/
expire_in: 1 week

artifacts : C'est une section du fichier de configuration .[Link] qui spécifie les fichiers ou les chemins à conserver comme
artefacts après l'exécution du travail.

Dans cet exemple, le répertoire binaries/ et son contenu seront conservés en tant qu'artefacts et expireront au bout d'une
semaine.

45
 GitLab : Artifacts
job1:
script:
- make build
artifacts:
paths:
- binaries/

job2:
script:
- make deploy
dependencies:
- job1

dependencies : Si un travail dépend des artefacts générés par un autre travail, la section dependencies peut être utilisée pour
spécifier ces dépendances. Cela garantit que les travaux dépendants sont exécutés après les travaux dont ils dépendent.

Ici, job2 dépend de job1 et aura accès aux artefacts générés par job1.

46
 GitLab : Artifacts
job:
script:
- make build
artifacts:
paths:
- binaries/
expire_in: 1 week

Les artefacts sont utiles pour partager des données entre différentes étapes du pipeline, pour stocker des fichiers de construction
ou pour fournir des résultats aux utilisateurs. Ils facilitent également le déploiement, la distribution et le stockage de fichiers
générés lors de l'exécution du pipeline CI/CD.

47
 GitLab : Docker Intro

• Docker est une plateforme open-source qui automatise le déploiement, la

gestion et la mise en œuvre d'applications dans des conteneurs logiciels.

• Les conteneurs sont des environnements légers et portables qui encapsulent

une application et ses dépendances
• Ils permettent de les exécuter de manière cohérente sur n'importe quel
environnement compatible avec Docker (un ordinateur portable, un serveur
physique ou un environnement cloud).

48
 GitLab : Docker Intro
•Conteneurs : Les conteneurs sont des unités d'exécution légères et indépendantes qui contiennent tout
le nécessaire pour exécuter une application, y compris le code, les bibliothèques, les dépendances et les
variables d'environnement.

•Images Docker : Une image Docker est un modèle immuable qui contient le code source, les
bibliothèques, les dépendances, les variables d'environnement et d'autres configurations nécessaires
pour exécuter une application. Les conteneurs sont créés à partir d'images.

•Dockerfile : Un Dockerfile est un script qui définit les étapes nécessaires pour construire une image
Docker. Il spécifie les dépendances, le code source, les variables d'environnement, etc.

•Registre Docker : Un registre Docker est un service qui stocke et distribue des images Docker. Le registre
public par défaut est le Docker Hub, mais vous pouvez également créer votre propre registre privé.

•Compose Docker : Docker Compose est un outil qui permet de définir et de gérer des applications multi-
conteneurs. Il utilise un fichier YAML pour configurer les services, les réseaux et les volumes nécessaires à
une application.
49
GitLab : Docker Intro

50
GitLab : Docker Intro

51
GitLab : Docker pipline
image: ruby:3.1

stages: # List of stages for jobs, and their order of execution

- build
Docker-build-job: # This job runs in the build stage, which runs first.
stage: build
before_script:
- echo "build started"
- echo $PATH
- which docker
- docker login [Link] -u benissasonia -p $Access_Token
script:
- echo "Compiling the code..."
- docker build -t [Link]/benissasonia/DockerProject .
- docker push [Link]/benissasonia/DockerProject

52
 GitLab : Docker pipline

L'utilisation de Docker dans le cadre d'un projet GitLab peut grandement faciliter le déploiement, la gestion des
dépendances, et la cohérence entre les différents environnements de développement.

53
 GitLab : Comment intégrer Docker à votre
projet GitLab
Étape 1 : Dockerfile
Créez un Dockerfile : À la racine de votre projet, créez un fichier nommé Dockerfile. Ce fichier contiendra les
instructions pour construire votre image Docker. Par exemple :
# Utilisez une image de base appropriée
FROM node:14

# Définissez le répertoire de travail

WORKDIR /app

# Copiez les fichiers de l'application dans le conteneur

COPY . .

# Installez les dépendances

RUN npm install

# Exposez le port sur lequel l'application écoute

EXPOSE 3000

# Commande pour démarrer l'application

CMD ["npm", "start"]
54
 GitLab : Comment intégrer Docker à votre
projet GitLab
Étape 2 : GitLab CI/CD
Ajoutez un fichier .[Link] : À la racine de votre projet, créez un fichier .[Link] qui définira les étapes de votre pipeline
CI/CD. Par exemple :
stages:
- build
- test
- deploy
services:
- docker:dind
before_script:
- docker info

build:
stage: build
script:
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_NAME .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_NAME
test:
stage: test
script:
- docker run $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_NAME npm test
deploy:
stage: deploy
script:
- docker run -d -p 3000:3000 $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_NAME 55
 GitLab : Comment intégrer Docker à votre
projet GitLab
stages:
- build
- test
- deploy
services:
- docker:dind
before_script:
- docker info
build:
stage: build
script:
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_NAME .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_NAME
test:
stage: test
script:
- docker run $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_NAME npm test
deploy:
stage: deploy
script:
- docker run -d -p 3000:3000 $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_NAME

Explication :
build : Construit l'image Docker et la pousse dans le registre du projet GitLab.
test : Exécute les tests à l'intérieur d'un conteneur Docker basé sur l'image construite.
deploy : Déploie l'application à partir de l'image construite. 56
 GitLab : Comment intégrer Docker à votre
projet GitLab
Étape 3 : Configuration de GitLab
Configuration du registre Docker GitLab : Assurez-vous que votre projet GitLab est configuré pour utiliser le registre
Docker intégré.
Accédez aux paramètres du projet > Registre Docker.
Configuration des variables d'environnement : Ajoutez des variables d'environnement dans les paramètres du projet
pour stocker des informations sensibles comme les identifiants de connexion au registre Docker.
Accédez aux paramètres du projet > Variables CI/CD.

Étape 4 : Exécution
Poussez vos modifications sur GitLab : Effectuez un commit et poussez vos modifications sur la branche configurée dans
le fichier .[Link].
Observez le pipeline CI/CD : Accédez à l'interface GitLab pour voir le pipeline CI/CD en cours d'exécution. Vous pourrez
suivre l'avancement de chaque étape du pipeline.
Accédez à l'application déployée : Une fois le pipeline terminé avec succès, vous devriez pouvoir accéder à votre
application déployée.
57