Formation gitlab-ci Zied Zinelabidine.pptx

1
Formateur : Zied Zinelabidine .
Ingénieur DevOps.
3 jours : 9h à 12h de 14h à 17h

PROGRAMME DE FORMATION
L'offre GitLab
 GitLab CE (Community edition). GitLab EE (Enterprise edition).
 Les différents types d'utilisation de GitLab : gitlab.com, on premise, on cloud (Azure ,AWS, GCP).
 Procédure d'inscription sur gitlab.com.
Travaux pratiques
Rappels sur Git et son utilisation avec GitLab
 Les concepts Git : blob, tree, commit, revision, branche, tag…
 Gestion locale des fichiers. Consultation et modification de l’historique de travail.
 Gestion des branches. Fusions des branches et gestion des conflits.
Travaux pratiques
Mise en place d'un dépôt distant et simulation d'un travail collaboratif.
La gestion du dépôt avec GitLab
 La gestion des collaborateurs d’un projet et leurs droits.
 Le système d’issues et le lien avec les commits.
 Présentation du wiki et des snippets.
Travaux pratiques
Paramétrage des droits et création de merge requests.

GitLab CI/CD
 Présentation de GitLab CI/CD et des GitLab runners.
 Présentation de Docker.
 Le fichier manifeste gitlab-ci.yml, présentation du langage YAML.
 Les balises essentielles pour décrire des étapes, des jobs, des traitements (stages, images, script…).
 Le suivi d’exécution du pipeline. Jobs automatiques, manuels et planifiés.
 Les artifacts et l’amélioration des performances avec le cache.
 La documentation officielle relative à la syntaxe du fichier manifeste.
 La gestion des environnements.
Travaux pratiques
Mise en place d’un runner
Exemples simples de création et d'enchaînement de jobs sur une machine Windows .
Plus loin dans l’utilisation des runners
 Les types de runners (shared runner, specific runner et group runner).
 Les shared runners disponibles sur gitlab.com gérés par l'équipe GitLab.
 Scalabilité des runners avec Docker Machine.
 Le Docker executor et les images disponibles : dotnet, ubuntu.
 Les tests d'intégration, les tests fonctionnels, les tests de montée en charge.
Travaux pratiques
Mise en place d’un specific runner. Exécution d’enchaînements de jobs sur différents runners.

Projet Gitlab
GitLab est un outil de gestion du cycle de
vie DevOps basé Web qui intègre un
gestionnaire de référentiel Git avec des
fonctionnalités wiki, de suivi des
problèmes et de pipeline CI/CD.
Il est développé sous licence open-
source par GitLab Inc.
Introduction Gitlab

Application web basée sur
git.
– Permet de gérer:
●
Le cycle de vie de projets git.
●
Les participants aux projets (roles, groupes,
etc.).
●
La communication entre ces participants.
Projet Gitlab
Introduction Gitlab

La documenta,on de GitLab CI sur trouve à l'adresse
h9ps://docs.gitlab.com/ee/ci/README.html.
6
Projet Gitlab
Introduction Gitlab

Un cycle de vie DevOps se compose de diﬀérentes étapes en boucle : "Plan", "Create",
"Verify", "Package", "Release", "Monitor". De manière transversale "Manage" et "Secure"
s'intéressent à toutes les étapes du cycle.
Introduction Gitlab

 Manage | Statistiques et fonc+ons
d'analyse.
 Plan | Planification et gestion de projet.
 Create | Fonctions SCM (Source Code Management)
 Verify | Tests, qualité du code et fonctions d'intégra+on con+nue.
 Package | Registre des conteneurs Docker.
 Release | Release et de livraison de l'application.
 Configure | Outils de configuration d'applications et d'infrastructures.
 Monitor | Fonctions de surveillance et de métrique des applications.
 Secure | Fonctionnalités de sécurité.
Introduction Gitlab

Ses points forts sont les suivants, de manière non
exhaustive :
 Modèle commercial Open Source
 Fonctionnalités et intégrations avancées
 Documentation ouverte
 Installation et maintenance aisées
 Modèle de déploiement très diversiﬁé, évolutif
 Ergonomie pour un usage quotidien
 Permet de migrer ses référentiels
 Git à partir de nombreux concurrents
 Permet d'être très satisfait sans budget
 Bien d'autres sans doute
Introduction Gitlab

Son point faible est d'être moins populaire que
GitHub.
Introduction Gitlab

• GitLab CE (Community Edition) - auto-hébergé et gratuit, support communautaire.
• GitLab EE (Enterprise Edition) - auto-hébergé et payant, foncionnalités supplémentaires.
• GitLab.com - SaaS, gratuit ou avec abonnement.
• GitLab.io - Instance privée gérée par GitLab Inc.
Les outils comparables sont par exemple GitHub ou Bitbucket.
Introduction Gitlab

GitLab CE (Community edition)
vs GitLab EE (Enterprise edition)
De nombreuses entreprises qui envisagent de commencer
à utiliser GitLab ne savent pas si elles doivent opter pour
l'édition communautaire gratuite (CE) ou pour l'édition
entreprise (EE) payante.
Certains décident de commencer par CE et envisagent de
passer à EE plus tard, s'ils sentent qu'ils ont besoin de plus
de fonctionnalités et/ou qu'ils veulent le support de GitLab.

vs GitLab EE (Enterprise
edition)
Public : Community Edition s'adresse aux développeurs et aux passionnés d'analyse pour qui , tandis que les banques,
les opérateurs, les hôpitaux et les entreprises qui gèrent les principaux sites Web du monde choisissent Enterprise
Edition.
Déploiement : les déploiements Community Edition sont destinés aux environnements où les informations stockées ne
sont pas critiques car elles n'incluent pas d'assistance professionnelle.
Enterprise Edition est destiné aux environnements d'entreprise qui nécessitent plus de disponibilité et de la fiabilité.
Support : Community Edition bénéficie d'un support via notre canal Slack et notre forum communautaire, tandis
qu'avec l'abonnement Enterprise Edition, vous obtenez une résolution immédiate via des tickets et un tracker via un
service Web.
Technologie : Community Edition a un certain nombre de limitations, y compris aucune prise en charge par l'entreprise
pour le sharding, scaling ou l'installation.

Garantie : Community Edition est à la pointe en ce qui concerne les mises à niveau de version et sans garantie de
correction de bugfix . Enterprise Edition a une garantie de correction de bugfix , une résolution immédiate, des
versions vérifiées, des mises à niveau de version sur site et automatiques.
Fonctionnalités : Enterprise Edition a plus de fonctionnalités que CE, en mettant l'accent sur l'analyse de bout en bout
et la plate-forme marketing.
edition)

edition)
https://about.gitlab.com/pricing/self-managed/feature-comparison/

edition)

•Si l'on désire en faire un usage plutôt public ou dans le nuage (gitlab.com),
Gitlab oﬀre déjà gratuitement des fonctionnalités très avancées.
•Dans tous les cas, si les utilisateurs consomment un certain seuil de
ressources, il est normal d'en payer le prix, le vrai prix, souvent moins jamais
plus.
Les différents types d'utilisation de GitLab :
gitlab.com, on premise, on cloud (Azure ,AWS, GCP).

Official Linux package :
On peut installer manuellement sur des
serveurs avec Systemes Exploitation linux
(pas de windows ) mais les runners on peut
les lancer sur des machines windows.
• CPU : 4
• RAM : 4 GB
• du stockage en conséquence
Il est fortement déconseillé de faire fonctionner
les Gitlab-runners (exécutants CI/CD) sur la
même machine que le serveur Gitlab.

Kubernetes Deployments:
On peut installer manuellement sur un
cluster Kubernetes ou aussi avec les
templates de Helm.

On peut installer manuellement sur un cloud
AWS , AZURE , GCP.
Exemple AWS , va se baser sur EKS pour
l’installation de gitlab ( cluster kubernetes)

Installation method Description When to choose
Docker
The GitLab packages,
Dockerized.
Use this method if you’re familiar with
Docker.
Source
Install GitLab and all of its
components from scratch.
Use this method if none of the
previous methods are available for
your platform. Useful for unsupported
systems like *BSD.
GitLab Environment Toolkit (
GET)
The GitLab Environment
toolkit provides a set of
automation tools to deploy a
reference architecture on
most major cloud providers.
Customers are very welcome to trial
and evaluate GET today, however be
aware of key limitations of the current
iteration. For production environments
further manual setup will be required
based on your specific requirements.
GitLab Operator
The GitLab Operator provides
an installation and
management method for
GitLab following the
Kubernetes Operator pattern.
Use the GitLab Operator to run GitLab
in an OpenShift environment.

Installation de gitlab sur Ubuntu
1. Install and configure the necessary dependencies
sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates tzdata perl
sudo apt-get install -y postfix
2. Add the GitLab package repository and install the package
Add the GitLab package repository.
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash

sudo EXTERNAL_URL="https://gitlab.example.com" apt-get install gitlab-ee

sudo vi /etc/gitlab/initial_root_password
sudo gitlab-rake "gitlab:password:reset[root]"
Pour changer le password root 2 methodes :

Création d’un projet formationGitlab

Création d’un compte gitlab.com
www.gitlab.com
Vous pouvez vous connecter avec
un compte gmail, github,…

Introduction à Git :
Un logiciel de gestion de Versions
Décentralisé
(DVCS)

Pourquoi un gestionnaire de version ?
… et pourquoi décentralisé ?

Extrait : http://liris.cnrs.fr/~pchampin/enseignement/intro-git/
Quelle est la dernière version ?
Quel est l’ordre des versions ?

Un logiciel de gestion de versions (ou VCS : Version Control System) est un logiciel qui permet de stocker un
ensemble de fichiers en conservant la chronologie de toutes les modifications qui ont été effectuées dessus.
Il permet notamment de retrouver les différentes versions d'un lot de fichiers
connexes (extrait Wikipedia)
Extrait : http://liris.cnrs.fr/~pchampin/enseignement/intro-git/
Avantages de la gestion de versions
Faciliter la sauvegarde et le travail collaboratif en :
→ disposant d’un historique sur les changements apportés
→ permettant facilement le retour en arrière
→ Partageant les changements
(documenter (messages de commit), fusionner,
récupérer, visualiser les modifications apportées,…)

Historique des Gestionnaires de
Version
 Gestion de versions centralisé (un seul dépôt fait référence)
(1986 : le premier : Concurrent Versioning System)
(2000 : SVN lancé pour remplacer CVS,
a suscité un réel intérêt pour les VCS,
le plus populaire avant l’arrivée des DVCS…)
Plusieurs dépôts pour un même projet
 Travail en local possible sans accès réseau!
 Gestion de versions décentralisé (Distributed Version Contrôl System)
(2005 : développé et optimisé pour le noyau Linux par Linus Thorval
 le plus populaire …)
(2005)
(2008)
Pour un historique : https://www.smashingmagazine.com/2008/09/the-top-7-open-source-version-control-systems
A lire : http://blogs.atlassian.fr/2014/06/17/git-vs-mercurial-pourquoi-git/

Gestion Centralisée vs Gestion Décentralisée
(pour la collaboration : copie de travail vs dépôt)
Extrait: https://fr.atlassian.com/git/tutorials/setting-up-a-repository
Git ne fait aucune distinction
entre la copie de travail
et le dépôt centralisé.
Ce sont des dépôts Git à part
entière.
Joel Spolsky (Stack Overflow, Trello) décrit
la gestion de version décentralisée comme
« probablement la plus grande avancée
dans les technologies de développement
logiciel dans ces années »
A lire : https://www.joelonsoftware.com/2010/03/17/distributed-version-control-is-here-
to-stay-baby

Git : le plus populaire des gestionnaires de version
Extrait : http://pages.zeroturnaround.com/RebelLabs-Developer-Productivity-Report-2016.html

Pourquoi préférer un DVCS …
Avantages de la gestion décentralisée :
→ Ne pas être dépendant d'une seule machine comme point de défaillance
→ Travailler sans être connecté au gestionnaire de version
→ Pas de permissions particulières pour participer à un projet
(les droits de commit/soumission peuvent être donnés après avoir démontré son travail et non pas avant)
→ Opérations plus rapides pour la plupart car réalisées en local (sans accès réseau)
→ Travail privé (réalisation de brouillons sans devoir publier ses modifications et gêner les autres
contributeurs)
→ … Avec un dépôt de référence contenant les versions livrées d'un projet.
Extrait : https://fr.wikipedia.org/wiki/Gestion_de_versions
Inconvénients :
→ cloner un dépôt est plus long que récupérer une version car tout l'historique est copié
(ce qui est toutefois un avantage par la suite)
→ il n'y a pas de système de lock
(ce qui peut poser des problèmes pour des données binaires qui ne se fusionnent pas).

Installation
 Installation:
https://git-scm.com/downloads
… et bien d’autres sur https://git-scm.com/downloads/guis et https://git.wiki.kernel.
org/index.php/InterfacesFrontendsAndTools#Graphical_Interfaces
 Utilisation de git :
→ dans un terminal en ligne de commande
(git --help : la commande à retenir !)
→ via un outil graphique

Les commandes Git
Commandes de porcelaine
(porcelain commands haut niveau)
commandes utilisées au quotidien
Nuages de mots réalisés avec à partir de http://www.wordclouds.com/
avec des données issues de http://stackoverflow.com/questions/39847781/which-are-the-plumbing-and-porcelain-commands
Commandes de plomberie
(plumbing commands bas niveau)
commandes qui manipulent les informations
au cœur de Git

Configuration (à la première utilisation)
git config --global user.name "Prénom Nom"
git config --global user.email
email@domaine.extension
Pas de modification anonyme avec Git !!!

Le dépôt au cœur de Git (ou repository)
git
init
Créer un nouveau dépôt :
git init
<directory>
(dans le répertoire courant)
git clone
<repo>
Clôner un dépôt existant : git clone <repo>
<directory>
(dans le répertoire courant)
Dépôt : Un dépôt est un dossier
qui porte le nom .git.
C'est là que Git va stocker l’historique du projet c-a-d toutes
les informations en rapport avec votre projet comme la liste
des commits effectués, la liste des branches, etc…
(En savoir plus sur le contenu réeel de ce dépôt :
https://git-scm.com/book/fr/v2/Les-tripes-de-Git-Plomberie-et-porcelaine#_git_internals )

Enregistrer des changements
(git add, git
commit, .gitignore)

Un répertoire avec son fichier …
… prêt à être versionné
git
init
Bonjour tout le monde
!
espace de travail
(working directory)
Demo
test.txt
.git
test.txt

Ajout d’un fichier dans l’Index
(zone en attente de commit)
espace de travail
(working directory)
Demo
test.tx
t
!
.gi
t
git add
test.txt
zone de staging :
pour regrouper les
fichiers
du prochain
commit
(=> plusieurs fichiers
possibles
dans un même commit)
ad
d
Liste, entre autres, les fichiers
stagés (dans l’index en
attente d’être commité), non
stagés
statu
s
Index
(staging index)
test.txt 306c18dea…
ls-files Liste les fichiers dans l’index et leur hash associé (signature en SHA-1)
associé
test.txt

Index
(staging index)
git
commit
test.txt
306c18dea…
committer :
enregistrer un ensemble
de modifications
+ Message obligatoire
qui va être demandé
git commit –m
"message"
lo
g
Liste des commits
(dans le dépôt local)
show
Détail d’un commit
(du dépôt local)
commi
t
Le commit vide l’index
du fichier stagé
Un hash (SHA-1)
propre au commit
Dépôt local
(local repository)
test.txt
+ autres infos
c1
eb
47
9

Chaque commit est répertorié avec son auteur, sa date, son message et son SHA-1
ainsi que des pointeurs vers un(des) commit(s) parent(s).
Chaque objet est identifié
40 caractères hexadécimaux
(somme de contrôle SHA-1 de son
contenu)
Un commit est l’unité de sauvegarde de git.
C’est une image du répertoire de travail à l’instant t
représentée à l’aide de trees et de blobs
Sources : https://fr.wikipedia.org/wiki/Git
Pour identifier une version, git s’appuie sur l’objet de type commit.

Un dépôt Git peut être vu comme une collection d’objets liés entre eux.
Sources : https://fr.wikipedia.org/wiki/Git
HEAD
L’historique d’un dépôt Git est l’ensemble des versions du répertoire de travail
(succession de commits)
La tête (HEAD) de l’historique est un pointeur vers le dernier commit (utilisé
comme prochain commit parent)

Git utilise 3 espaces différents pour manipuler les données.
espace de travail
(working directory)
Dossier du projet tel qu’il
est stocké sur le disque.
Les fichiers dans cette zone
peuvent être connus
ou non de git
Dépôt local
(local repository)
Index
(staging index)
ad
d
Espace de Transit
Données en préparation
pour le prochain
commit (Fichiers à
intégrer au prochain
commit)
commi
t
contient tous les commits
c-a-d
contient l’historique du
projet
La tête de l’historique
(HEAD) pointe vers le commit
le plus récent de la branche
courante
statu
s
Recherche les fichiers stagés (en attente d’être commités) ou
non
log Liste des commits
show Détail d’un commit

Enregistrer de nouvelles modifications dans un
nouveau commit (en une seule ligne)
espace de travail
(working directory)
Demo
! J’utilise git !
test.tx
t
.git
git commit –am
"message"
test.txt
Dépôt local
(local repository)
908563
4
c1eb47
9
HEAD
log sho
w
Tous les fichiers
trackés
c-a-d
ceux qui ont déjà été
ajoutés à l’index une
fois

Ignorer des fichiers dans l’historique (.gitignore)
Certains fichiers n’ont pas besoin d’être versionnés, et ne doivent pas être trackés
(fichiers de log, fichiers résultants d’une compilation, fichiers de configuration, …)
… à spécifier dans un fichier .gitgnore à la racine du dépôt.
(non trackés par git, ils ne seront pas détectés comme ayant subi un changement (modified) et potentiellement
commitable)
(Exemple pour un projet Maven sous Eclipse)
# Eclipse
.classpat
h
.project
.settings
/#
Maven
target/
.gitignore
Quelques liens à consulter pour personnaliser son .gitignore :
https://git-scm.com/docs/gitignore#_pattern_format , https://github.com/github/gitignore
http://gary-rowe.com/agilestack/2012/10/12/a-gitignore-file-for-intellij-and-eclipse-with-maven , https://fr.atlassian.com/git/tutorials/gitignore
# introduit une ligne de
commentaires

Consulter l’historique
(git status, git log, git
diff)

git
status
espace de travail
(working directory)
Liste les fichiers stagés, non stagés et non trackés
git
log
Dépôt local
(local repository)
Affiche l’ensemble de l’historique (tous les commits)
git log -n
<limite>
Affiche les derniers n commits
où n=<limite>
git log-n-3
pour les 3 derniers commits
git log -
oneline
Affichage de l’historique
où chaque commit est affiché sur une seule
ligne
git log –author="nom
auteur"
git log
<fichier>
…
Affichage uniquement les commits
filtrés avec l’auteur spécifié
Affichage uniquement des commits
Contenant le fichier spécifié

Visualiser les différences (git diff)
différences entre deux commits
(Exemple : modifications introduites par
le dernier commit)
git diff
commit1..commit 2
différences entre espace de travail et index
git
diff
différences entre l’index et le HEAD
git diff --
cached
différences entre espace de travail et le HEAD
git diff
HEAD
…

Consulter un changement c-a-d se positionner sur
• un ancien commit de l’historique
•(git checkout)

Se positionner sur un commit donné (git diff)
git checkout
commitparSonSHA
Le checkout d'un commit transforme l’espace de travail pour afficher un ancien
état de votre projet sans modifier son état actuel.
L’historique n’est pas modifié…
… ainsi pour retrouver l’état actuel de l’espace de travail, il suffit de …
Consulter (afficher) une ancienne version, sans
toucher à votre espace de travail
Revenir au commit le plus récent
de la branche principale
git checkout
master
Possible aussi pour un fichier en particulier :
git checkout commitparSonSHA
<fichier>
… suivi de … git checkout HEAD
<fichier>

Annuler un changement
(git revert, git
reset)

git revert commitparSonSHA
Revenir à un état antérieur en créant un nouveau
nouveau commit (défait en créant un nouveau commit,
mais ne revient pas en arrière à proprement parlé…)
git commit --amend -m "Votre nouveau
message"
Modifier le message du commit (possible uniquement si commit pas non pushé sur dépôt distant (origin))
D’après
https://openclassrooms.com/courses/gerer-son-code-avec-git-et-github/se-positionner-sur-un-commit-donne Et
J'ai fait mon commit un peu trop vite...est-ce que je peux l'annuler ?
git reset HEAD
Annuler les changements dans l’index
(remet l’index dans le même état que la version la plus récente du dépôt)
git reset --hard HEAD
Annuler les changements de l’espace de travail et de l’index
(Attention, commande irréversible !!!)

Créer des Branches (git
branch, git checkout)

La branche par défaut est master
Une branche correspond à une version en parallèle
de celle en cours de développement.
Une branche peut servir à développer de nouvelles
fonctionnalités, à corriger des bugs sans pour autant
intégrer ces modifications à la version principale du logiciel
une-branche
master
une-autre-branche

Créer une branche et en faire la branche courante
git branch une-
branche
Créer une branche
Un nouveau pointeur (une-
branche)
est pour l’instant simplement créé
sur le commit courant.
L’historique ne change pas
master
une-branche
git checkout -b une-
branche
Ou en une seule ligne de commande :
HEAD
Se positionner sur la branche
git checkout une-branche fraichement créée pour qu’elle
devienne la branche courante
(celle qui recevra le prochain commit
master
Nom de branches : ne pas commencer par un tiret, ni deux points consécutifs,
ne pas terminer par un slash
une-branche

En pratique …
git checkout -b
anglais
une-branche
c1eb47
9
master
9085634
1. Créer une nouvelle branche anglais et se positionner dessus
espace de travail
(working directory)
Demo
test.tx
t
! J’utilise git !
.gi
t
test.txt
Hello world !
I’m using git
!
test_EN.txt
test_EN.tx
t
2. Travailler dans
l’espace de travail
3. Commiter
(sur anglais puisqu’on est
positionné sur cette branche !)
git commit –am "message en
anglais"
git add
test_EN.txt
Si nouveau fichier,
il doit être ajouté à
l’index !
master
anglais
c1eb47
9
908563
4
HEAD
9f68c0
2

Que se passe-t-il lorsqu’on change de branche ?
anglais
c1eb47
9
908563
4
HEAD
9f68c0
2
master
git checkout
master
espace de travail
Demo
test.tx
t
.git
!
J’utilise git
!
test.txt
Hello world !
I’m using git
!
test_EN.txt
git checkout
anglais
→ Le répertoire de travail est modifié
→ L’index reste intact
→ La référence HEAD est mise à jour sur le commit le plus récent
de la branche choisie (nouvelle branche courante)
espace de travail
Demo
test.txt
test_EN.tx
t
.git
test.tx
t
!
J’utilise git
!

Liste des branches existantes
git
branch
* indique la branche courante
(c-a-d la branche qui contiendra le commit)
Remarque : Le prompt de la console (invite de commande) indique la branche courante :
ou
: si anglais est la branche
courante
: si master est la branche
courante

Créer (tirer) une autre branche …
anglais
c1eb47
9
master
9085634
HEAD
9f68c0
2
git branch
espagnol
anglais
c1eb47
9
master
9085634
9f68c0
2
espagnol
git checkout
master
git branch
espagnol
La branche est tirée depuis la branche courante …
anglais
c1eb47
9
9f68c0
2
master
9085634
espagnol

Fusionner des branches
(git
merge)

Fusionner des branches
Intégrer les modifications faites sur une branche dans une autre branche.
(Récupération et intégration des différences d’une branche dans une autre)
FUSION
FUSION
FUSION

Fusionner une branche : Principe général (fusion avec commit)
master
ma-branche
Si on est sur master
et
qu’on souhaite fusionner
ma-branche dans master :
git merge ma-
branche
Commit « ancêtre commun » Commit de fusion
→ git recherche le dernier commit en commun (commit « ancêtre commun » )
→ git crée un nouveau commit sur master qui contiendra les modifications apportées
par ma-branche (commit de fusion)
Grâce au commit de fusion, les deux branches
gardent leur identité dans le graphe de l’historique

Fusionner une branche : Cas particulier de l’avance
rapide (Fast-Forward)
master
ma-branche Avant
git merge ma-
branche
ma-branche
master
Avant
La fusion Fast-Forward a simplement
pour effet de déplacer le sommet
de la branche cible
 pas de commit de fusion,
simple avance de
pointeur : gain de temps …
mais …
Avec une avance rapide,
l’historique restera linéaire
(perte d’indentité)
Remarque : possibilité de forcer la création d’un commit de fusion,
même dans cette situation, grâce à l’ajout de l’option --no-ff : no fast forward)
Si pas de modification sur le « commit
ancêtre » depuis la création de la branche…

master
anglais
c1eb47
9
908563
4
9f68c0
2
!
J’utilise git
!
test.txt
Hello world !
I’m using git
!
test_EN.txt
espace de travail
Demo
test.tx
t
test_EN.tx
t
.git
test.tx
t
! J’utilise git !
!
J’utilise git
!
test.txt
Hello
world !
I’m using git
!
test_EN.txt
c1eb47
9
908563
4
master
anglais
HEAD
9f68c02
git merge
anglais
git log confirme la présence d’uniquement 3 commits
Remarque : La branche anglais existe toujours, possibilité de s’y positionner dessus avec checkout

Fusion classique : Exemple
anglais
test.txt
! J’utilise git !
Hello world !
I’m using git !
git is a distributed version control
system.
test_EN.txt
test_EN.txt
Hello world !
I’m using git !
! J’utilise git !
git est un logiciel de gestion de versions
décentralisé.
test.txt
master
HEAD
!
J’utilise git !
décentralisé.
test.txt
Hello world !
I’m using git
!
system.
test_EN.txt
Comme la fusion créée un nouveau commit,
Si vous ne spécifiez pas de message,
il vous sera automatiquement demandé !
anglais
master
HEAD

Après la fusion : git log (tous les commits)
anglais
ma
ste
r
HE
AD

A propos des tags
Un tag est un alias (nom)
dont le rôle est de pointer vers un commit…
… pour éviter l’utilisation des hash SHA-1,
peu explicites et difficiles à retenir
Les tags sont utilisés pour marquer des numéros de version
sur les commits
A propos des numéros de version x.y.z :
x : version majeure (modifications dans le fonctionnement de l’application :
incompatibilité avec une version précédente)
y : version mineure (ajout des fonctionnalités:
compatibilité avec l’ancien système)
z : patch (correction de bugs sans ajout de fonctionnalité)

Les commandes git autour des tags …
git tag nom-du-
tag
git tag
v1.0.0
anglais
master
HEAD
v1.0.0
Créer un tag sur le commit courant :
Par la suite, il sera possible
de revenir sur le commit via
git checkout
v1.0.0
Exemple :
git tag nom-du-tag
hash
Créer un tag à partir de son hash :
Créer un tag annoté git tag –a nom-du-
tag
git tag –am nom-du-tag "
+ message
Liste des tags
git tag --
list
Détail d’un tag
git show nom-du-
tag
Supprimer un tag
git tag -d nom-du-
tag

Hello world !
git was created by Linus Torvalds in
2005. I’m using git !
system
anglais
master
HEAD
v1.0.0
Hello world !
I’m using git
!
system.
test_EN.txt
…Mais parfois, git peut ne pas savoir pas
comment réaliser la fusion
Hola
Mundo !
git fue creado por Linus Torvalds en
2005.
Estoy usando git !
git es un software de control de
versiones.
test_ES.txt
espagnol
Et maintenant, si on essayait
de fusionner les modifications
de espagnol dans master :
Bonjour tout le monde !
git a été créé par Linus Torvalds en
2005.
J’utilise git !
décentralisé.
test.txt
Bonjour le monde
! J’utilise git
!
git est un
logiciel de
gestion de
versions
décentralisé
.
test.txt
test_EN.txt

… Et il y a un Conflit à résoudre !
Git met la fusion en pause (le promt indique
)
Et demande à l’utilisateur de résoudre le conflit manuellement
Pour voir les fichiers en conflit : git status
Fichier qui présente un conflit :
test.txt
2 solutions :
→ abandonner la fusion
→ ou résoudre manuellement le conflit
git merge --
abort

Pour résoudre manuellement le conflit,ouvrir le fichier qui présente le conflit …
test.txt
<<<<<<< HEAD
Bonjour tout le monde !
git a été créé par Linus Torvalds en 2005.
=======
Bonjour le monde !
>>>>>>>
espagnol
J'utilise
git !
git est un
logiciel de
gestion de
versions
décentralisé.
>>>>>>> branche-a-fusionner
fin du conflit avec ci-dessus
le contenu en conflit de la branche à fusionner
(ici branche espagnol)
<<<<<<< branche-de-base
début du conflit avec le contenu
de la branche de base
(HEAD qui correspond à master)
=======
séparation du contenu des deux
branches

Résoudre le conflit et finaliser la fusion …
test.txt
Bonjour le monde !
git a été créé par Linus Torvalds en
2005.
J'utilise git !
décentralisé.
1. Corriger manuellement le conflit
de manière à obtenir le fichier souhaité
3. Vérifier que le conflit a bien été résolu
(git status)
2. Avertir git que le conflit a été résolu
(git add)
4. Valider le commit de la fusion
(git commit avec un message par défaut
prédéfini
ou préciser le message)
… et le prompt redevient

Supprimer une branche
git branch –d branch-a-
supprimer
Cette commande supprime réellement le pointeur de la branche.
A utiliser avec précaution, uniquement si :
→ la branche a été fusionnée dans master et
aucune autre modification n’est prévue dans cette branche
→ les modifications de la branche ne sont plus à l’ordre du jour et elles
ne seront jamais intégrées.

git fournit à chaque développeur sa propre copie du dépôt,
avec son propre historique local et sa structure de branche.
Images extraites de https://fr.atlassian.com/git/tutorials/setting-up-a-repository et https://fr.atlassian.com/git/tutorials/syncing
et https://fr.atlassian.com/git/tutorials/comparing-workflows
Un dépôt git peut être lié à d’autres dépôts git dits distants (ou remote repository)
avec lesquels il pourra partager des commits.
Un dépôt distant a un emplacement qui peut être :
→ un répertoire (sur un disque local ou partagé),
→ ou une URL (par exemple https://github.com/iblasquez/tuto_git).
Dépôt distant
Un remote peut être
utilisé comme
répertoire central,
auquel tous les
développeurs se
synchronisent.

Cloner un dépôt distant
git clone emplacement-du-depot-à-cloner
Le clone peut se faire selon plusieurs protocoles : directement en local, via HTTPS, SSH ou
git
Exemple : cloner un depôt distant sur Github (https)

Que se passe-t-il lors d’un clone ?
→ un nouveau dépôt local geekgit est
créé.
→ ce dépôt est lié au dépôt distant connu
sous le nom origin
(c-a-d origin est un raccourci qui pointe vers l’URL du
dépôt
distant : https://github.com/iblasquez/geekgit.git)
espace de travail
geekgit
poesie.m
d
README.m
d
.git
→ les commits de l’origine sont récupérés
dans ce dépôt

Travailler en local …
espace de travail
geekgit
poesie.m
d
README.m
d
.git
espace de travail
geekgit
peinture.m
d
poesie.md
README.md
.git
un commit ...
un autre commit …

Synchroniser les dépôts : publier ses commits (push)
git push origin
master
Envoyer les modifications
de la branche master du dépôt
local sur le dépôt distant (origin)
git push <depot-distant> <branche-
locale>
Remarques : Pousser toutes les branches git push --
all
POUSSER
Les identifiants Github
peuvent être demandés
avant de pousser ;-)
Intéressant à lire : http://blog.xebia.fr/2017/01/17/git-depots-distants-sans-acces-reseau/

Il existe même un plugin git-fire à découvrir sur https://github.com/qw3rtman/git-fire (Save Your Code in an Emergency)
Extraits de https://twitter.com/agilex/status/836123942683308032
https://openclipart.org/detail/130795/trollface
Voir aussi : https://www.reddit.com/r/ProgrammerHumor/comments/3nc531/in_case_of_fire
Affiche à imprimer depuis : http://abload.de/img/in_case_of_fireirrtb.jpg ou
https://hikaruzone.wordpress.com/2015/10/06/in-case-of-fire-1-git-commit-2-git-push-3-leave-building

Le dépôt distant a subi/reçu
de nouvelles modifications …

Synchroniser les dépôts : récupérer
des commits distants (pull)
git fetch <depot-
distant>
git merge origin/<branche-
locale>
Télécharger les commits du dépôt
distant de la branche courante…
… puis Fusionner
ces commits
à la branche locale
(git merge
origin/master)
TIRER
Ou directement : Recevoir sur la branche
courante les modifications en provenance
du dépôt distant
Remarque : Si un conflit se présente git merge --abort revient à l’état avant le
git pull <depot-distant>
Possibilité de demander un rebase :
git pull -–rebase <depot-
distant>

Les workflows (modèles de développement)
A lire : La puissance des workflows git : https://medium.com/@OVHUXLabs/la-puissance-des-workflows-git-12e195cafe44#.rbkmhjcc2

Article original : http://nvie.com/posts/a-successful-git-branching-model/
Version française : https://www.occitech.fr/blog/2014/12/un-modele-de-branches-git-efficace/
Pour faciliter sa mise en place voir Git flow : http://danielkummer.github.io/git-flow-cheatsheet/
GitFlow : un workflow à base de
branches (1/2)
Les branches principale
→ main sur origin
(doit rester stable : prêt pour être déployé en production)
→ develop (appelée aussi branche d’intégration)
(reflète les derniers changements livrés pour la prochaine version)
Les branches de support (à durée de vie limitée)
→ les branches pour les fonctionnalités (features)
→ les branches pour les versions (releases)
(préparer les nouvelles versions de production, correction
d’anomalies mineures, préparation des méta-données pour une
version (numéro, date de compilation, etc.)
→ Les branches de correctifs (hotfixes)

→ Chaque développeur pull et push sur origin
GitFlow : un workflow à base de branches (2/2)
Article original : http://nvie.com/posts/a-successful-git-branching-model/
Version française : https://www.occitech.fr/blog/2014/12/un-modele-de-branches-git-efficace/
Pour faciliter sa mise en place voir Git flow : http://danielkummer.github.io/git-flow-cheatsheet/
→ Au delà de la relation centralisée push-pull,
chaque développeur peut aussi récupérer des
changements d’autres équipiers et ainsi
former des sous-équipes…
→ …utile quand deux ou plusieurs développeurs
travaillent ensemble sur une fonctionnalité, plutôt
que de pousser prématurément le travail en
cours sur origin.

GitHub Flow : un workflow branché simplifié …
Extrait : https://guides.github.com/introduction/flow
1.
Créer
une
branche
Master Tout ce qui est
sur master est
stable et peut
être déployée à
tout moment
en production
2.
Ajouter
des
commits
4.
Discuter et
échanger
(revue de
code)
5.
Valider
la pull request
si pas d’issue
6.
Fusionner
Un développeur ne doit pas fusionner sa branche dans master
lorsqu’il pense que c’est bon, un autre doit venir faire
une revue du code et confirmer la stabilité de la branche.
1 master et des branches features !!!
3.
Ouvrir
une pull
request
Proposer une
contribution

Un exemple de workflow mis en place lors
d’un projet tuteuré
1 fonctionnalité => 1 branche

Periodic table of devops tools
Carte interactive disponible sur : https://xebialabs.com/periodic-table-of-devops-tools/
A compléter par :
https://xebialabs.com/glossary/
Autres
outils
autour de la
gestion de
version

Un mémo interactif (1/2)
http://ndpsoftware.com/git-cheatsheet.html
Commandes git autour
de l’espace de travail

Un mémo interactif (2/2)
http://ndpsoftware.com/git-cheatsheet.html
Commandes git autour
du dépôt distant
Reste à découvrir en ligne…
commandes git autour :
→ de la remise
→ de l’index
→ du dépôt local

Extrait : http://stackoverflow.com/questions/2745076/what-is-
the-difference-between-git-commit-and-git-push
commit: adding changes to the local repository
push: to transfer the last commit(s) to a remote server
Extrait : https://zeroturnaround.com/rebellabs/git-commands-
and-best-practices-cheat-sheet/

Détail du dernier commit
diff par rapport à la
dernière sauvegarde
show
hash du commit
auteur du commit
date de commit
message de commit
commit parent

Paged’accueil
Groupes auxquels
j’appartiens
Accès direct à cette
page
Paramètres
Utilisateurs
(clefs
SSH)
Création de
projets/groupes
Liste des projets
auxquels je participe
Recherche
de projets

Page de
groupe
Accès aux
projets contenus
dans le groupe
Créer un nouveau projet
dans le groupe
Workspace du groupe
Gestion des
Membres
(enregistrement,
droit d’accès)
Introduction à Git (& Gitlab) – R.
Passama

Page de projet
Adresse du
dépôt git
Visibilité du projet
(public, interne ou privé)
Accès aux
informations détaillées
sur le dépôt
Workspace
contenant le projet
Gestion
des issues

Informations sur le dépôt
Graphe des
commits
Visualisation des fichiers
Outil de
comparaison
des
versions
Information détaillée sur chaque commit

Les Issues
●
Discussion entre développeurs/utilisateurs
– Déclarer des BUGS, proposer des améliorations,
etc.
Discussion d’une issue
Associer des labels
pour caractériser l’
issue (e.g. BUG)

Les Issues
●
Board : organiser le traitement des
issues.
Non traitées En cours En test

Fork et Merge request
●
Work-flow « à la github »
– Fork = cloner un dépôt directement dans Gitlab (le
dépôt créé existe dans le serveur)
●
Le dépôt originel « connaît » ses dépôts
clonés.
– Merge request = proposer de fusionner une
branche du dépôt cloné dans une branche du
dépôt originel.
●
●
●
La requête peut être discutée, approuvée ou
rejetée. Possibilité de voir les changement
proposés.
Seuls les développeurs du dépôt originel peuvent
valider la requête.
Permet de recevoir des contributions de
personnes extérieures au projet

Fork et Merge request
●
Situation
initiale
Serveur
Gitlab Dépôt Originel
Répertoir
e de
travail
origin
g i t push origin master
g i t p u l l origin
master
Developpeurs « officiels »

Forker
●
Cloner un dépôt dans un autre
workspace
Dépôt
cloné
fo rk
origin
<identifiant fork>
Serveur
Gitlab
Dépôt
Originel
origin
Répertoir
e de
travail
Developpeurs
« officiels »

Forker le dépôt Accès aux projets clonés
Forker
●
Cloner un dépôt dans un autre workspace
Sélection du workspace
dans lequel le dépôt cloné
sera placé
fork

Forker
●
origin origin g i t push origin master
gi t pu ll or ig i n
ma st e r
<identifiant fork>
Répertoir
e de
travail
Developpeurs
« officiels »
Répertoir
e de
travail
Autre groupe de
développeurs
Dépôt
cloné
Développeurs extérieurs travaillent de
manière isolée
Serveur Gitlab
Dépôt
Originel

Forker
●
origin origin
official
g it pul l offi c ial bra nch
<identifiant fork>
Répertoir
e de
travail
Répertoir
e de
travail
Developpeurs « officiels
»
Autre groupe de
développeurs
54
Dépôt
cloné
mettre à jour un dépôt cloné à partir du
dépo originel
Serveur Gitlab
Dépôt
Originel

Merge request
●
Proposition de fusion de branches depuis dépôt
cloné vers dépôt originel
<identifiant fork>
2 ) Accepter la merge request :
g i t p u l l < i d e n t i f i a n t f o r k >
branch
Dépôt
cloné
1 ) Merge re que st
– Développeurs du dépôt cloné proposent la fusion d’une
branche.
– Développeurs du dépôt originel décident si la fusion est
réalisée.
Serveur Gitlab
Dépôt
Originel

Proposer la fusion
1) Sélectionner les branches
source (du dépôt cloné) et cible (originel)
Détailler sa merge request

Proposer la fusion
Commits qui seront ajouté à la branche
Explication de la merge request
Assignee : développeur du dépôt originel
en charge de traiter la merge request
originelle si la merge request est acce5p7
tée

Accepter ou refuser la fusion
Origine de la requête
Accepter la requête
(fusionner)
Commits et modifications
proposés
Fil de discussion entre
développeurs
Refuser la requête (fermer)

Workshop-git : https://gitlab.com/zinelabidine.zied/workshop-git

La gestion du dépôt avec GitLab
Autorisations générales
Les groupes et les projets peuvent avoir les niveaux de visibilité suivants:
 Public (20) - une entité est visible par tous le monde.
 Internal (10) - une entité est visible pour les utilisateurs connectés à notre gitlab interne.
 Private (0) - une entité n'est visible que par les membres approuvés de l'entité .

La gestion du dépôt
avec GitLab
Groups d’users : https://docs.gitlab.com/ee/user/permissions.html
 Guest
 Reporter
 Developer
 Maintainer
 Owner

avec GitLab

avec GitLab
Protected branches: https://docs.gitlab.com/ee/user/permissions.html

Default branch :
 Main.
avec GitLab

avec GitLab
Protected branch :
 Main.
 Develop.
 Release.

Demo sur protected branch . . .

Intégration continue / déploiement continue

GitLab CI/CD
 L’ensemble des pratiques permettant d’améliorer la qualité du code des applications sont regroupées au
sein
du concept d’intégration continue.
 Il s’agit notamment au cours de différentes étapes d’évaluer de la qualité du code produit, d’inclure et
d’automatiser la construction de l’application à partir de son code source, d’exécuter les tests unitaires
pour éviter toute forme de régression et d’effectuer des tests d’intégration.
 La phase de déploiement continue permet, à l’issue de la phase d’intégration, d’automatiser la mise en
production de l’application, afin de réduire au maximum les délais entre la production de code, et sa
mise à disposition des utilisateurs ou des testeurs

GitLab CI/CD
 L'intégration continue, ou IC, permet d'intégrer le code de votre équipe dans un référentiel partagé.
Les développeurs partagent leur nouveau code dans une demande de fusion (extraction), ce qui
déclenche la création, le test et la validation par un pipeline, avant la fusion des modifications dans
votre référentiel.
 GitLab CI/CD va vous permettre d’automatiser les builds, les tests, les déploiements, etc. de vos applications.
L’ensemble de vos tâches peut être divisé en étapes et l’ensemble de vos tâches et étapes constituent un
pipeline.
 Les outils d'intégration continue - CI, et de déploiement continu - CD, permettent d'automatiser beaucoup de
processus qui prennent du temps, et sont sujets à erreur humaine.
 La CI permet une intégration de code plus rapide et moins déstabilisante, puisque le code est intégré au fur et à
mesure, à un rythme plus soutenu qu'avec d'autres approches de développement.

GitLab CI/CD
Étape 1 : Planifiez votre développement
 Afin de savoir quoi développer, il est nécessaire d'avoir à disposition un outil permettant la collaboration entre
les développeurs. Cet outil permettra notamment de gérer les différentes releases et toutes les fonctionnalités,
de garantir la priorité du backlog, etc.
 Intervenant tout au long du projet, la collaboration de toute l'équipe est nécessaire pour assurer la
planification du projet. Cette planification est étroitement liée à la méthodologie Scrum. Elle a pour but de
découper le projet en petites tâches à réaliser par toute l'équipe.
 Sur notre chaîne d'assemblage, la planification représente la répartition des tâches de chaque collaborateur,
ou encore le brief du matin destiné à définir les tâches à faire durant la journée.

GitLab CI/CD
Étape 2 : Compilez et intégrez votre code
Le contrôle de code source
 Le code source se doit d'être disponible à chaque instant sur un dépôt central. Chaque développement doit
faire l'objet d'un suivi de révision.
 Le code doit être compilable à partir d'une récupération fraîche, et ne faire l'objet d'aucune dépendance
externe.

GitLab CI/CD
L'orchestrateur
Ensuite, toutes les étapes doivent être automatisées par un orchestrateur, qui saura reproduire ces
étapes et gérer les dépendances entre elles.
De plus, l'utilisation d'un orchestrateur permet de donner accès à tous, et à tout moment, à un tableau
de bord qui donnera l'état de santé des étapes d'intégration continue.
Ainsi, les développeurs ont au plus tôt la boucle de feedback nécessaire, afin de garantir que
l'application soit prête à tout moment. De plus, l'orchestrateur permettra d'aller plus loin dans la
livraison continue, comme on le verra dans la suite.

GitLab CI/CD
Compiler le code :
 La première étape, et celle qui paraît la plus évidente, est de compiler le code de manière continue. En effet,
sans cette étape, le code est compilé manuellement sur le poste du développeur, afin que ce dernier s'assure
que son code compile.
 La mise en place d'une première étape de compilation dans un processus d'intégration continue permet justement
de ne plus se soucier si des modifications de code cassent la compilation. Le développeur doit alors s'assurer de bien
envoyer son code source sur le dépôt central. En faisant cela, il déclenche une première étape de compilation, avec
toutes les modifications des autres développeurs. Si la compilation ne se fait pas, le code est alors rejeté, et le
développeur doit corriger ses erreurs.
 Vous pourrez compiler votre code avec Maven, Ant, Gradle, MSBuild, NAnt, Gulp ou encore Grunt.

GitLab CI/CD
Les tests unitaires
 Dans cette étape, l'orchestrateur se charge de lancer les tests unitaires à la suite de la compilation. Ces tests unitaires,
généralement avec un framework associé, garantissent que le code respecte un certain niveau de qualité.
 Les tests unitaires permettent de vérifier le bon fonctionnement d'une partie précise d'un logiciel ou d'une portion
d'un programme.
 Les tests unitaires apportent 3 atouts à la production :
 trouver les erreurs plus facilement. Les tests sont exécutés durant tout le développement, permettant de visualiser si
le code fraîchement écrit correspond au besoin ;
 sécuriser la maintenance. Lors d'une modification d'un programme, les tests unitaires signalent les éventuelles
régressions. En effet, certains tests peuvent échouer à la suite d'une modification, il faut donc soit réécrire le test pour
le faire correspondre aux nouvelles attentes, soit corriger l'erreur se situant dans le code ;
 documenter le code. Les tests unitaires peuvent servir de complément à la documentation ; il est très utile de lire les
tests pour comprendre comment s'utilise une méthode.

GitLab CI/CD
Mesurez la qualité de votre code
 Lors de l'étape de qualité de code, nous cherchons à assurer la plus petite dette technique possible de notre
application. La dette technique est le temps nécessaire à la correction de bugs ou à l'ajout de nouvelles
fonctionnalités, lorsque nous ne respectons pas les règles de coding. La dette est exprimée en heures de
correction. Plus cette dette est élevée, plus le code sera difficile à maintenir et à faire évoluer.
 L'étape de qualité de code mesure aussi d'autres métriques, comme le nombre de vulnérabilités au sein du code,
la couverture de test, mais aussi les code smells (qui sont des mauvaises pratiques à ne pas implémenter), la
complexité cyclomatique (complexité du code applicatif) ou la duplication de code. C'est le rôle du développeur de
respecter les normes définies et de corriger au fur et à mesure son code.

GitLab CI/CD
Gérez les livrables de votre application
 Le code, une fois compilé, doit être déployé dans un dépôt de livrables, et versionné. Les binaires produits
sont appelés artefacts. Ces artefacts doivent être accessibles à toutes les parties prenantes de l'application,
afin de pouvoir les déployer et lancer les tests autres qu'unitaires (test de performance, test de bout en bout,
etc.).
 Ces artefacts sont disponibles dans un stockage, centralisé et organisé, de données. Ce peut être une ou
plusieurs bases de données où les artefacts sont localisés en vue de leur distribution sur le réseau, ou bien un
endroit directement accessible aux utilisateurs.

GitLab CI/CD
Demo pipeline CI sans le CD

.gitLab-
ci.yml
 Ajouter un fichier .gitlab-ci.yml à la racine du projet .
 .gitlab-ci.yml définit un ensemble de jobs (commandes) et de contraintes par stages ( {} ==
pipeline).
 Le pipeline est déclenché à chaque commit ou push et s’exécute dans le runner.
 Et .gitlab-ci.yml explique au(x) Runner(s) ce qu’il faut faire .
Un cycle d'intégration continue dans Gitlab CI est défini à partir d'un fichier de configuration écrit en YAML.
Le fichier est placé à la racine du projet sous le nom réservé de .gitlab-ci.yml.

.gitLab-
ci.yml
Exemple .gitlab-ci.com

GitLab CI/CD
Le manifeste
Pour que la CI/CD sur GitLab fonctionne il vous faut un manifeste .gitlab-ci.yml à la racine de votre projet. Dans
ce manifeste vous allez pouvoir définir des stages, des jobs, des variables, des anchors, etc.
Vous pouvez lui donner un autre nom mais il faudra changer le nom du manifeste dans les paramètres de
l’interface web : Settings > CI/CD > General pipelines > Custom CI config path

GitLab CI/CD
Les Jobs
Dans le manifeste de GitLab CI/CD vous pouvez définir un nombre illimité de jobs, avec des contraintes indiquant quand
ils doivent être exécutés ou non.
Voici comment déclarer un job le plus simplement possible :
job:
script: echo 'my first job'
Et si vous voulez déclarer plusieurs jobs :
job:1:
script: echo 'my first job'
job:2:
script: echo 'my second job'
les noms des jobs doivent être uniques et
ne doivent pas faire parti des mots réservés
:
 image
 services
 stages
 types
 before_script
 after_script
 variables
 cache
Dans la définition d’un job seule la
déclaration script est obligatoire.

GitLab CI/CD
Script
La déclaration script est donc la seule obligatoire dans un job. Cette déclaration est le coeur du job car c’est ici que vous
indiquerez les actions à effectuer.
Il peut appeler un ou plusieurs script(s) de votre projet, voire exécuter une ou plusieurs ligne(s) de commande.
job:script:
script: ./bin/script/my-script.sh ## Appel d'un script de votre projet
job:scripts:
script: ## Appel de deux scripts de votre projet
- ./bin/script/my-script-1.sh
- ./bin/script/my-script-2.sh
job:command:
script: printenv # Exécution d'une commande
job:commands:
script: # Exécution de deux commandes
- printenv
- echo $USER

GitLab CI/CD
before_script et after_script
Ces déclarations permettront d’exécuter
des actions avant et
après votre script principal.
Ceci peut être intéressant
pour bien diviser les actions
à faire lors des jobs,
ou bien appeler ou exécuter
une action avant et après chaque job
before_script: # Exécution d'une commande avant chaque `job`
- echo 'start jobs'
after_script: # Exécution d'une commande après chaque `job`
- echo 'end jobs'
job:no_overwrite: # Ici le job exécutera les action du `before_script` et àfter_script` par défaut
script:
- echo 'script'
job:overwrite:before_script:
before_script:
- echo 'overwrite' # N'exécutera pas l’action définie dans le `before_script` par défaut
script:
- echo 'script'
job:overwrite:after_script:
script:
- echo 'script'
after_script:
- echo 'overwrite' # N'exécutera pas l’action définie dans le àfter_script` par défaut
job:overwrite:all:
before_script:
- echo 'overwrite' # N'exécutera pas l’action définie dans le`before_script` par défaut
script:
- echo 'script'
after_script:
- echo 'overwrite' # N'exécutera pas l’action définie dans le àfter_script` par défaut

GitLab CI/CD
Image
Cette déclaration est simplement l’image docker qui sera utilisée lors d’un job ou lors de tous les jobs
image: alpine # Image utilisée par tous les `jobs`, ce sera l'image par défaut
job:node: # Job utilisant l'image node
image: node
script: yarn install
job:alpine: # Job utilisant l'image par défaut
script: echo $USER

GitLab CI/CD
Stages
Cette déclaration permet de grouper des jobs en étapes.
Par exemple on peut faire une étape de build,
de codestyling, de test, de code coverage,
de deployment, ….
stages: # Ici on déclare toutes nos étapes
- build
- test
- deploy
job:build:
stage: build # On déclare que ce `job` fait partie de l'étape build
script: make build
job:test:unit:
stage: test # On déclare que ce `job` fait partie de l'étape test
script: make test-unit
job:test:functional:
stage: test # On déclare que ce `job` fait partie de l'étape test
script: make test-functional
job:deploy:
stage: deploy # On déclare que ce `job` fait partie de l'étape deploy
script: make deploy

GitLab CI/CD
Only et except
Ces deux directives permettent de mettre en place des contraintes sur l’exécution d’une tâche. Vous
pouvez dire qu’une tâche s’exécutera uniquement sur l’événement d’un push sur master ou s’exécutera
sur chaque push d’une branche sauf master.
Voici les possibilités :
 branches déclenche le job quand un un push est effectué sur la branche spécifiée.
 tags déclenche le job quand un tag est créé.
 api déclenche le job quand une deuxième pipeline le demande grâce à API pipeline.
 external déclenche le job grâce à un service de CI/CD autre que GitLab.

GitLab CI/CD
• pipelines déclenche le job grâce à une autre pipeline, utile pour les multiprojets grâce à l’API et le token
CI_JOB_TOKEN.
• pushes déclenche le jobquand un push est effectué par un utilisateur.
• schedules déclenche le job par rapport à une planification à paramétrer dans l’interface web.
• triggers déclenche le job par rapport à un jeton de déclenchement.
• web déclenche le job par rapport au bouton Run pipeline dans l’interface utilisateur.

GitLab CI/CD
only et except simple
Dans son utilisation la plus simple,
le only et le except se déclarent comme ceci :
job:only:master:
script: make deploy
only:
- master # Le job sera effectué uniquement lors d’un événement sur la
branche master
job:except:master:
script: make test
except:master:
- master # Le job sera effectué sur toutes les branches lors d’un événement
sauf sur la branche master
only et except complex
Dans son utilisation la plus complexe, le only et le
except s’utilisent comme ceci :
job:only:master:
script: make deploy
only:
refs:
- master # Ne se fera uniquement sur master
kubernetes: active # Kubernetes sera disponible
variables:
- $RELEASE == "staging" # On teste si $RELEASE vaut "staging"
- $STAGING # On teste si $STAGING est défini

GitLab CI/CD
only avec schedules
Pour l’utilisation de schedules il faut dans un
premier temps définir des règles dans l’interface
web. On peut les configurer dans l’interface web de
Gitlab : CI/CD -> Schedules et remplir le formulaire.
Si vous souhaitez, vous pouvez définir un intervalle
de temps personnalisé. C’est ce que j’ai fait dans mon
exemple. La définition se fait comme un cron

GitLab CI/CD
when
Comme pour les directives only et except, la directive
when est une contrainte sur l’exécution de la tâche. Il y a
quatre modes possibles :
 on_success : le job sera exécuté uniquement si tous
les jobs du stage précédent sont passés.
 on_failure : le job sera exécuté uniquement si un job
est en échec.
 always : le job s’exécutera quoi qu’il se passe (même
en cas d’échec).
 manual : le job s’exécutera uniquement par une
action manuelle.
stages:
- build
- test
- report
- clean
job:build:
stage: build
script:
- make build
job:test:
stage: test
script:
- make test
when: on_success # s'exécutera uniquement si le job `job:build` passe
job:report:
stage: report
script:
- make report
when: on_failure # s'exécutera si le job `job:build` ou `job:test` ne passe pas
job:clean:
stage: clean
script:
- make clean # s'exécutera quoi qu'il se passe
when: always

GitLab CI/CD
allow_failure
Cette directive permet d’accepter qu’un job échoue sans faire échouer la pipeline.
stages:
- build
- test
- report
- clean
...
stage: clean
script:
- make clean
when: always
allow_failure: true # Ne fera pas échouer la pipeline
...

GitLab CI/CD
tags
Comme je vous l’ai dit en début d’article, avec GitLab Runner vous pouvez héberger vos propres runners sur un serveur
ce qui peut être utile dans le cas de configuration spécifique.
Chaque runner que vous définissez sur votre serveur à un nom, si vous mettez le nom du runner en tags, alors ce runner
sera exécuté.
job:tag:
script: yarn install
tags:
- shell # Le runner ayant le nom `shell` sera lancé

GitLab CI/CD
services
Cette déclaration permet d’ajouter des services (container docker) de base pour vous aider dans vos jobs. Par
exemple si vous voulez utiliser une base de données pour tester votre application c’est dans services que vous le
demanderez.
test:functional:
image: registry.gitlab.com/username/project/php:test
services:
- postgres # On appel le service `postgres` comme base de données
before_script:
- composer install -n
script:
- codecept run functional

GitLab CI/CD
environment
Cette déclaration permet de définir un environnement
spécifique au déploiement. Vous pouvez créer un
environnement dans l’interface web de GitLab ou tout
simplement laisser GitLab CI/CD le créer automatiquement.
Il est possible de spécifier :
 un name,
 une url,
 une condition on_stop,
 une action en réponse de la condition précédente.
...
deploy:demo:
stage: deploy
environment: demo # Déclaration simple de l'environnement
script:
- make deploy
deploy:production:
environment: # Déclaration étendue de l'environnement
name: production
url: 'https://blog.eleven-labs/fr/gitlab-ci/' # Url de l'application
script:
- make deploy

GitLab CI/CD
En déclarant des environments vous pouvez, depuis l’interface web de GitLab, déployer / redéployer votre application ou
directement accéder à votre site si vous avez déclaré une url. Ceci se fait dans Operations > Environment.
Le bouton undo permet de redéployer, le bouton external link
permet d’aller sur l’application et le bouton remove
permet de supprimer l’environnement.
on_stop et action seront utilisés pour ajouter une action
à la fin du déploiement, si vous souhaitez arrêter
votre application sur commande.
Utile pour les environnements de démonstration
...
deploy:demo:
script: make deploy
environment:
name: demo
on_stop: stop:demo
stop:demo: # Ce job pourra être visible et exécuté uniquement après le job
`deploy:demo`
script: make stop
environment:
name: demo
action: stop
Voici le lien officiel de la documentation
sur les environments si vous souhaitez aller plus loin.

GitLab CI/CD
variables
Cette déclaration permet de définir des variables pour tous les jobs ou pour un job précis.
Ceci revient à déclarer des variables d’environnement.
...
variables: # Déclaration de variables pour tous les `job`
SYMFONY_ENV: prod
build:
script: echo ${SYMFONY_ENV} # Affichera "prod"
test:
variables: # Déclaration et réécriture de variables globales pour ce `job`
SYMFONY_ENV: dev
DB_URL: '127.0.0.1'
script: echo ${SYMFONY_ENV} ${DB_URL} # Affichera "dev 127.0.0.1"

GitLab CI/CD
Comme pour environment je vous laisse regarder la documentation officielle sur les variables si vous souhaitez aller plus
loin.
Il est aussi possible de déclarer des variables depuis l’interface web de GitLab Settings > CI/CD > Variables et de leur
spécifier un environnement

GitLab CI/CD
cache
Cette directive permet de jouer avec du cache. Le cache est intéressant
pour spécifier une liste de fichiers et de répertoires à mettre en cache tout
le long de votre pipeline. Une fois la pipeline terminée le cache sera
détruit.
Plusieurs sous-directives sont possibles :
 paths : obligatoire, elle permet de spécifier la liste de fichiers et/ou
répertoires à mettre en cache
 key : facultative, elle permet de définir une clé pour la liste de fichiers
et/ou de répertoires. Personnellement je n’en ai toujours pas vu l’utilité.
 untracked : facultative, elle permet de spécifier que les fichiers ne
doivent pas être suivis par votre dépôt git en cas d’un push lors de votre
pipeline.
 policy : facultative, elle permet de dire que le cache doit être
récupéré ou sauvegardé lors d’un job (push ou pull).
stages:
- build
- deploy
job:build:
stage: build
image: node:8-alpine
script: yarn install && yarn build
cache:
paths:
- build # répertoire mis en cache
policy: push # le cache sera juste sauvegardé, pas de
récupération d'un cache existant
job:deploy:
stage: deploy
script: make deploy
cache:
paths:
- build
policy: pull # récupération du cache

GitLab CI/CD
artifacts
Les artefacts sont un peu comme du cache mais ils peuvent être récupérés depuis une
autre pipeline. Comme pour le cache il faut définir une liste de fichiers ou/et répertoires
qui seront sauvegardés par GitLab. Les fichiers sont sauvegardés uniquement si le job
réussit.
Nous y retrouvons cinq sous-directives possibles :
 paths : obligatoire, elle permet de spécifier la liste des fichiers et/ou dossiers à
mettre en artifact
 name: facultative, elle permet de donner un nom à l’artifact. Par défaut elle sera
nommée artifacts.zip
 untracked : facultative, elle permet d’ignorer les fichiers définis dans le
fichier .gitignore
 when : facultative, elle permet de définir quand l’artifact doit être créé. Trois choix
possibles on_success, on_failure, always. La valeur on_success est la valeur par défaut.
 expire_in : facultative, elle permet de définir un temps d’expiration
job:
script: make build
artifacts:
paths:
- dist
name: artifact:build
when: on_success
expire_in: 1 weeks

GitLab CI/CD
dependencies
Cette déclaration fonctionne avec les artifacts,
il rend un job dépendant d’un artifact.
Si l’artifact a expiré ou a été supprimé / n’existe
pas,alors la pipeline échouera.
build:artifact:
stage: build
script: echo hello > artifact.txt
artifacts: # On ajoute un `artifact`
paths:
- artifact.txt
deploy:ko:
stage: deploy
script: cat artifact.txt
dependencies: # On lie le job avec 'build:artifact:fail' qui n'existe pas donc la pipeline échouera
- build:artifact:fail
deploy:ok:
stage: deploy
script: cat artifact.txt
dependencies: # On lie le job avec 'build:artifact' qui existe donc la pipeline n'échouera pas
- build:artifact

GitLab CI/CD
coverage
Cette déclaration permet de spécifier une expression régulière
pour récupérer le code coverage pour un job.
...
test:unit:
script: echo 'Code coverage 13.13'
coverage: '/Code coverage d+.d+/'
Le code coverage sera visible dans les informations du job dans l’interface web de GitLab :
Ajouter le code coverage sur les MR avec avec GitLab-CI

GitLab CI/CD
retry
Cette déclaration permet de ré-exécuter le job en cas d’échec. Il faut indiquer le nombre de fois où vous voulez ré-exécuter
le job
job:retry:
script: echo 'retry'
retry: 5

GitLab CI/CD
include
Pour cette fonctionnalité il vous faudra un compte premium. Cette fonctionnalité permet d’inclure des “templates”. les
“templates” peuvent être en local dans votre projet ou à distance.
Les fichiers sont toujours évalués en premier et fusionnés récursivement. Vous pouvez surcharger ou remplacer des
déclarations des “templates”.
• template en local
# template-ci/.lint-template.yml
job:lint:
stage: lint
script:
- yarn lint
• template à distance
# https://gitlab.com/awesome-project/raw/master/template-ci/.test-template.yml
job:test:
stage: test
script:
- yarn test

GitLab CI/CD
• manifeste principal
# .gitlab-ci.yml
include:
- '/template-ci/.lint-template.yml'
- 'https://gitlab.com/awesome-project/raw/master/template-ci/.test-template.yml'
stages:
- lint
- test
job:lint:
before_script:
- yarn install
job:test:
script:
- yarn install
- yarn unit

GitLab CI/CD
stages:
- lint
- test
job:lint:
stage: lint
before_script: # on surcharge `job:lint` avec `before_script`
- yarn install
script:
- yarn lint
job:test:
stage: test
script: # on remplace la déclaration `script` du "template" https://gitlab.com/awesome-project/raw/master/template-ci/.test-template.yml
- yarn install
- yarn unit
Voici ce que gitlab CI/CD va interpréter :
Ceci peut être intéressant dans le cas où votre manifeste est gros, et donc plus difficile à maintenir.

GitLab CI/CD
Anchors
Cette fonctionnalité permet de faire
des templates réutilisables plusieurs fois.
.test_template: &test_template
stage: test
before_script:
when: on_success
.db_template:
services:
- postgres
- mongo
test:unit:
<<: *test_template
script:
- bin/phpunit --coverage-text --colors=never tests/
test:functional:
<<: *test_template
services: *db_template
script:

GitLab CI/CD
Voici ce que gitlab CI/CD va interpréter :
test:unit:
stage: test
before_script:
script:
- bin/phpunit --coverage-text --colors=never tests/
when: on_success
test:functional:
stage: test
services:
- postgres
- mongo
before_script:
script:
when: on_success

GitLab CI/CD
La question ou ce lance ce pipeline CI/CD

GitLab CI/CD
Runner execution flow Executors :
• SSH
• Shell
• Parallels
• VirtualBox
• Docker
• Docker Machine (auto-scaling)
• Kubernetes
• Custom

GitLab CI/CD
Runner SaaS
Si vous utilisez GitLab autogéré ou que vous utilisez GitLab.com mais que vous souhaitez utiliser vos propres
runners , vous pouvez installer et configurer vos propres runners.
Si vous utilisez GitLab SaaS (GitLab.com), vos tâches CI s'exécutent automatiquement sur les exécuteurs fournis
par GitLab. Aucune configuration n'est requise.
Vos tâches peuvent s'exécuter sur :
 Linux runners.
 Windows runners (beta).
 macOS runners (beta).

GitLab CI/CD
Registering runners
L'enregistrement d'un runner est le processus qui lie le runner à une ou plusieurs instances GitLab.
Vous pouvez enregistrer plusieurs runners sur la même machine hôte, chacun avec une configuration différente, en
répétant la commande register
Avant d'inscrire un runner, vous devez d'abord : Installez-le sur un serveur distinct de celui
où GitLab est installé
Obtenir un ‘tokern’ :
 Pour un runner partagé ’shared’, demandez à un administrateur d'aller dans la zone
d'administration de GitLab et de cliquer sur Présentation > runners
 Pour un runner de groupe, allez dans Paramètres > CI/CD et développez la section
runners
 Pour un runner spécifique au projet, accédez à Paramètres> CI/CD et développez la
section runners

GitLab CI/CD
Mise en place d’un runner sur Linux
# Download the binary for your system
sudo curl -L --output /usr/local/bin/gitlab-runner
https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
# Give it permissions to execute
sudo chmod +x /usr/local/bin/gitlab-runner
# Create a GitLab CI user
sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
# Install and run as service
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner start
#Command to register runner
sudo gitlab-runner register --url https://gitlab.com/ --registration-token $REGISTRATION_TOKEN

GitLab CI/CD
Faut installer Docker sur les machines et le relancer :
Set up the repository
Update the apt package index and install packages to allow apt to use a repository over HTTPS:
Add Docker’s official GPG key:
Use the following command to set up the stable repository. To add the nightly or test repository, add the word nightly or test (or both) after the word stable in the commands below. Learn about nightly and test channels.
Install Docker Engine
Update the apt package index, and install the latest version of Docker Engine and containerd, or go to the next step to install a specific version:
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg lsb-release
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo
"deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg]
https://download.docker.com/linux/ubuntu
$(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io

GitLab CI/CD
Mise en place d’un runner sur Windows avec executor shell
# Run PowerShell:
https://docs.microsoft.com/en-us/powershell/scripting/windows-powershell/starting-windows-pow
ershell?view=powershell-7#with-administrative-privileges-run-as-administrator
# Create a folder somewhere in your system ex.: C:GitLab-Runner
New-Item -Path 'C:GitLab-Runner' -ItemType Directory
# Enter the folder
cd 'C:GitLab-Runner'
# Dowload binary
Invoke-WebRequest -Uri "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/
gitlab-runner-windows-amd64.exe" -OutFile "gitlab-runner.exe"
# Register the Runner (steps below), then run
.gitlab-runner.exe install --password “password"
.gitlab-runner.exe start
.gitlab-runner.exe register --url https://gitlab.com/ --registration-token $REGISTRATION_TOKEN

GitLab CI/CD
Ajout d’un nouveau
runner test avec un tag
totowindows avec un
shell comme executor

GitLab CI/CD
Configuration des runners windows dans le fichier config.toml
Préciser avc lancer le shell :
powershell

GitLab CI/CD
Mise en place d’un runner sur Windows avec executor docker-windows
Image : ziedzinelabidine/dotnet:5.0
git clone https://gitlab.com/zinelabidine.zied/dotnet-gitlab-ci.git
https://git-scm.com/download/win

GitLab CI/CD
 Faut installer docker pour windows:
Install-Module -Name DockerMsftProvider `
-Repository PSGallery `
-Force
Install-Package -Name docker `
-ProviderName DockerMsftProvider
Restart-Computer -Force
docker info

191
Rappel Docker
VM Container
Le principe du concept de conteneurisation :
• Le principe est de faire tourner des environnements Linux isolés les uns des autres dans des conteneurs partageant le
même noyau avec la machine host.
• Le conteneur virtualise l’environnement d’exécution (comme le processeur, la mémoire vive ou le système de fichier…) et
ne virtualise donc pas la machine. C’est pour cela que l’on parle de « conteneur » et non de machine virtuelle (VM).
• Comme le conteneur n’’embarque pas d’OS, il est donc beaucoup plus léger que la VM. Le conteneur est donc plus facile
à migrer ou à télécharger, et plus rapide à sauvegarder ou à restaurer..
• La virtualisation par conteneur permet au serveur d’héberger potentiellement beaucoup plus de conteneurs que s’il
s’agissait de machines virtuelles.

192
Introduction
Avantages point de vue développeur :
• Un environnement portable pour exécution des apps .
• Chaque application s’exécute dans son propre conteneur : avec ses propres versions des librairies .
• Facilite l’automatisation des tests unitaire , fonctionnelles , intégrations …
• Elimine les problèmes de compatibilité entres les plateformes .
• Cout ressource très bas pour lancer un container. On peut en lancer des dizaines sur un poste développeur .

193
Avantages point de vue SysAdmin et Devops :
• Configure once…run anything & evreywhere .
• Elimine les inconsistances entre les différents environnements Dev , recette , statging , preprod , prod
• Améliore la rapidité et la fiabilité du déploiement continu .
• Micro-service , Les applications sont séparées en petits morceaux indépendants et peuvent être déployés et
gérés dynamiquement – pas une stack monolithique dans une seule machine à tout faire.
• Facilite la mise en place des pipeline CI/CD .
Introduction

194
Rappel l’architecture de Docker
Docker est composé des éléments suivants:
 le daemon Docker qui s’exécute en arrière-
plan et qui s’occupe de gérer les
conteneurs (Containerd avec runC) .
 une API de type REST qui permet de
communiquer avec le daemon .
 Le client en CLI (command line interface) :
commande docker
 une image est un ensemble de fichiers
inertes en read-only.
 Un conteneur est une instance une active
(started) ou inactive (stopped) d’une
image. L’éxecution d’un conteneur n’altère
jamais une image.

195
Télécharger une image (commande : docker pull ) :
Lancer un conteneur (commande : docker run ) :
• La commande docker run qui permet de lancer un conteneur peut également télécharger
l’image si elle n’est pas disponible localement
Rappel sur les commandes de base

196
• Connaitre l’historique de création de l’image (commande : docker history ) :

197
• Lister les images présentent localement (commande : docker images ou
docker image ls )
• Ajouter un tag à une image (commande : docker image tag )

198
• Supprimer une image (commande : docker rmi)
Cette commande permet de supprimer une image à condition de ne pas avoir
de conteneur lié.

199
Lister les conteneurs en cours d’exécution (commande : docker ps )
La commande docker ps qui permet de lister les conteneurs en cours
d’éxècutions ne retourne effectivement rien :
Pour obtenir la liste complète des conteneurs, il faut utiliser l’option
docker ps –a :

200
Obtenir une session interactive (docker run –it id_container Ou
docker exec –it id_container )
On peut obtenir une session intéractive (option -i ) en se branchant sur
l’entrée standard du conteneur et en connectant un pseudo terminal TTY
(option -t ) :
Lancer un conteneur en mode daemon (option : -
d )

201
Obtenir la configuration détaillée d’un conteneur
$ docker inspect <nom_conteneur> ou <CID>
Récupérer la sortie standard d’un conteneur
$ docker logs <nom_conteneur> ou <CID>
Pousser l’image dans la registry

GitLab CI/CD
Mise en place d’un runner pour la mise à jour et les publications des images Docker
a. Créer un nouveau projet sur gitlab.com et aussi un runner windows .
b. Le projet va contenir deux fichiers à créer le Dockerfile et .gitlab-ci.yml
 Dockerfile est déjà fait dans l’ancien projet

GitLab CI/CD
Le pipeline se lance que sur la branch main : Only : main
Job Login : « Login pour docker hub avec les credentials»
before_script: docker info
script : docker login -u ${CI_REGISTRY_USER} -p ${CI_REGISTRY_PASSWORD}
Job Build : « Builder l’image »
script : docker build -t ${CI_REGISTRY}/${CI_PROJECT_PATH}:{TAG} .
Job Publish: « publier l’image »
Script: docker push ${CI_REGISTRY}/${CI_PROJECT_PATH} :{TAG}
After_script : logout
 .gitlab-ci.yml avec les instructions :

GitLab CI/CD
Tag : docker-builder

GitLab CI/CD
https://gitlab.com/zinelabidine.zied/build-docker

GitLab CI/CD
Mise en place d’une image Docker de runner avec SonarQube et on rajoute le job Verify-code-Quality
Installation de SonarQube :
sudo docker run -d --name sonarqube -p 8000:9000
-e sonar.forceAuthentication=true
-e sonar.telemetry.enable=false sonarqube:8.1-community-beta
Admin/admin

GitLab CI/CD
Ensuite rajouter le job SonarQube dans le .gitlab-ci.yml du projet php
sonar:
stage: code-Quality
image: sonarsource/sonar-scanner-cli:latest
script:
- sonar-scanner -Dsonar.qualitygate.wait=true
allow_failure: true
variables:
SONAR_TOKEN: "f3b8b11edd557e4782d018aea69fb4ac936b5ea4"
SONAR_HOST_URL: "http://15.237.107.159:8000"

GitLab CI/CD
La phase final et de déployer vers les environnements ciblées , surtout la production et ce job dépends de
l’hébergement de l’application ( cloud , on promise , Kubernetes , openstack ..) en générale et manuel comme
Job avec aussi un Job pour rollback .

Le déploiement vers le cloud AWS.
Exemple de déploiement sur AWS avec la ligne de cmd aws ;
token de sécurité sur gitlab .
GitLab &&Kubernet

Introduction à Kubernet
Rappel sur Kubernetes

Le Kubernetes executor et la répartition des jobs dans un cluster Kubernetes.

Terraform
GitLab && Infrastructure as code

Formation gitlab-ci Zied Zinelabidine.pptx

Contenu connexe

Similaire à Formation gitlab-ci Zied Zinelabidine.pptx

Formation gitlab-ci Zied Zinelabidine.pptx

Notes de l'éditeur