GitLab
======
__Christian Tritten__
Présentation
------------
* GitLab est une solution d’hébergement de projets Git public ou privés.
* Fonctionnalités comparables à celles de GitHub.
* Interface graphique simple et agréable.
* Utilisable par tous les métiers
(Product Owner, Dev, Exploitant)
* S'inscrit totalement dans la mouvance DevOps.
3 versions distinctes
---------------------
* Version hébergée sur gitlab.com
* Version on-premise
* Version communautaire gratuite et open source
GitLab en tête selon Forrester
------------------------------
(septembre 2017)
Groupe / Projet
---------------
* GitLab utilise un découpage en Groupes et Projets
* En gros : 1 projet = 1 application / composant
* Les groupes permettent l'organisation des projets
Chaque projet possède
---------------------
* un mode d'accès : _privé_, _interne_ ou _public_
* une liste de contributeurs avec différents niveaux de droits
* des outils (dépôt de code, wiki, intégration continue, ...)
Note:
- accès privé : sur invitation seulement
- accès interne : tous les membres authentifiés
- accès public : tout le monde
Fonctionnalités principales
---------------------------
* Dépôt de code source
* Suivi d'anomalies et de fonctionnalités
* Collaboration via Merge Requests
* Documentation
Autres fonctionnalités
----------------------
* Wiki
* Intégration et livraison continues
* Entrepôt d'images Docker
* Hébergement de sites web statiques
* Intégration avec des plateformes de communication collaboratives (Mattermost, Slack...)
Tout en un !
------------
* GitLab se positionne tranquillement sur l'ensemble de la chaine DevOps.
* GitLab fourni au sein d'une interface unifiée un maximum d'outils permettant de faciliter la mise en place d'une approche DevOps sur un projet de développement.
Dépôt de code source
--------------------
* C'est la fonctionnalité première de GitLab
* Seule la technologie _git_ est supportée
* Multi-utilisateurs
* Multi-projets
Suivi d'anomalies et de fonctionnalités
---------------------------------------
* Le terme "issue" peut représenter :
- un ticket de déclaration d'anomalie (un bug !)
- un ticket de demande de fonctionnalité
- un ticket de suggestion d'amélioration
- un ticket de tâche à effectuer
- ...
### Labels
* Une "issue" peut être associée à un ou plusieurs labels.
* Les labels permettent l'organisation et le filtrage des issues, par niveau de traitement ou type d'activité par exemples.
### Assignation
* Une "issue" peut être assigné à une des personnes associées au projet en vue de son traitement.
* La personne en question se voit automatiquement notifiée.
### Discussion
* Une "issue" peut être discutée via un système de commentaires intégré.
### Organisation
* La vue "Board", présentée sous la forme d'un tableau à colonne permet :
- d'avoir une vision complète des tickets en cours,
- d'organiser le travail selon un workflow configurable,
- de prioriser les tickets les uns par rapports aux autres.
Collaboration via Merge Requests
--------------------------------
* GitHub a popularisé un principe de partage de code appelé _Pull Request_.
* Ce concept est également présent dans GitLab sous le nom de _Merge Request_.
### Qu'est-ce qu'une Merge Request ?
* Les Merge Requests permettent d'échanger du code facilement et facilitent la collaboration entre les personnes qui travaillent sur le même projet.
* Une Merge Request est simplement une demande (Request) de fusion (Merge) d'une branche git dans une autre.
### Workflow d'une Merge Request
1. Cloner le projet
2. Créer une branche et travailler dessus
3. Publier la branche
4. Créer la Merge Request
5. Revue de code (+ Discussion) du contenu de la Merge Request
6. Fusionner la branche
Documentation
-------------
* La documentation d'un projet s'effectue via la création de fichiers textes :
- au format Markdown (extension `.md`),
- eux-même versionnées dans le projet,
- par exemple le README.md qui décrit un projet.
* L'édition en ligne est possible.
* Syntaxe Markdown : https://daringfireball.net/projects/markdown/syntax
Wiki
----
* Chaque projet peut avoir son propre wiki dédié.
* Les fichiers du wiki sont versionnés séparément des fichiers du projet.
Entrepôt d'images Docker
------------------------
Plateforme de communication
---------------------------
* Via l'outil Mattermost
* Fonctionnalités
- Discussion instantanée
- individuelle, en groupe public ou privés
- Partage de fichiers
Hébergement de pages web statiques
----------------------------------
* GitLab Pages est un service d'hébergement de pages web statiques.
* GitLab Pages permet par exemple de publier la documentation de vos applications.
* Gitlab Pages
- utilise Gitlab CI, le système d'intégration continue de Gitlab,
- pour générer des sites statiques
- à partir de simple pages html
- ou à l'aide de générateurs (tels que Hugo ou Pelican).
Intégration et livraison continues
----------------------------------
GitLab CI / CD
--------------
### L'intégration continue
consiste à vérifier à chaque
modification du code source
que le résultat des modifications
ne produit pas de régression
dans l'application développée.
### Intérêt de l'intégration continue
* Résultats de la compilation et des tests visibles par l'ensemble de l'équipe.
* Détection et correction des problèmes d'intégration au plus tôt lors du développement.
(avant de merger dans la branche de production)
* Automatisation de l'exécution de suites de tests qui vérifient la qualité et la cohésion du code produit.
Note:
- Problèmes d'intégration : par exemple, un oubli d'inclusion, des dépendances cassées, des régressions possibles, ...
- Qualité du code : par exemple, les test unitaires, le respect des normes de nommage, de programmation, ...
### La livraison continue
consiste à délivrer les applications
dans des cycles courts,
permettant ainsi de les mettre à disposition
à n’importe quel moment.
### Le déploiement continu
consiste à déployer le résultat
de la livraison sur un serveur
sans opération manuelle.
La livraison d’une application sur un serveur n’est pas une opération anodine et triviale.
Elle implique souvent l'exécution de multiples tâches annexes et présente toujours un risque qu'il faut maîtriser lorsque il s'agit de l'environnement de production.
### Intérêt de la livraison et du déploiement continus
* Automatisation du packaging, de la livraison et du déploiement de l'application afin de rendre ces processus fiables et répétables.
* Augmentation de la fréquence des livraisons et du déploiement.
### Déclenchement
Ces étapes d'intégration et de livraison continues sont déclenchables selon des évènements pré-définis, comme :
* le push d'un commit git,
* la création d'un tag git,
* une planification,
* un appel sur l'API GitLab,
* un déclenchement manuel.
### Pipelines, Stages et Jobs
* Le processus complet est appelé _Pipeline_.
* Chaque _Pipeline_ est composé
d'une ou plusieurs étapes (_Stages_).
* Chaque _Stage_ est composé
d'une ou plusieurs tâches (_Jobs_).
### Déclaration d'un Pipeline
* Dans GitLab un Pipeline est défini dans le fichier `.gitlab-ci.yml`
* Ce fichier est directement versionné dans le projet.
### Runners
Chaque étape du Pipeline est exécutée sur une machine spéciale appelée _Runner_.
* Chaque étape peut faire appel à un Runner différent, spécialisé pour la tâche en question (build, packaging, ...).
* Les Runners peuvent être conteneurisés.
### Exécution du Pipeline
* L'exécution d'un Pipeline peut être dans les états :
- running,
- pending,
- passed,
- failed.
Dans tous les cas il est possible d'accéder au détail de la tâche pour débugger.
Un gros Pipeline !
Possibilité de forcer un mode manuel pour les mises en production.
### Configurer un Pipeline CI / CD
`.gitlab-ci.yml`
`.gitlab-ci.yml`
```yaml
stages:
- build-script
- build-image
- deploy
- check-deployment
variables:
IMAGE_RELEASE_NAME: who-is-there:$CI_COMMIT_TAG
IMAGE_REGISTRY_RELEASE_NAME: $DOCKER_HUB_USER/who-is-there:$CI_COMMIT_TAG
DEPLOYMENT_WIT_REPLICAS: 3
```
`.gitlab-ci.yml`
```yaml
# Compile go source file
build-go-script:
stage: build-script
image: golang:1.9.2
only:
# Execute the job only if a git tag is pushed
- tags
tags:
# Execute the job only on the runner tagged 'kubernetes'
- kubernetes
before_script:
# Create a symbolic link under $GOPATH,
# this is needed for local build
- cd $GOPATH/src
- mkdir -p gitlab/$CI_PROJECT_NAMESPACE
- cd gitlab/$CI_PROJECT_NAMESPACE
- ln -s $CI_PROJECT_DIR
- cd $CI_PROJECT_NAME
script:
# Build full static binary
- go build -ldflags "-linkmode external -extldflags -static" -o who-is-there
- chmod +x who-is-there
artifacts:
paths:
- who-is-there
```
`.gitlab-ci.yml`
```yaml
# Build a Docker image containing the binary
# generated in job build-go-script
build-docker-image:
stage: build-image
image: docker:18.03
only:
# Execute the job only if a git tag is pushed
- tags
tags:
# Execute the job only on the runner tagged 'kubernetes'
- kubernetes
dependencies:
- build-go-script
script:
- ls -l
- docker build -t $IMAGE_RELEASE_NAME .
- docker tag $IMAGE_RELEASE_NAME $IMAGE_REGISTRY_RELEASE_NAME
- docker image ls
- docker login -u $DOCKER_HUB_USER -p $DOCKER_HUB_PASS
- docker push $IMAGE_REGISTRY_RELEASE_NAME
```
`.gitlab-ci.yml`
```yaml
# Deploy or update the application
# on the Kubernetes cluster
deploy-on-k8s:
stage: deploy
image: xian310/kubectl-proxy:1.11
only:
# Execute the job only if a git tag is pushed
- tags
tags:
# Execute the job only on the runner tagged 'kubernetes'
- kubernetes
script:
- cat k8s/wit.deployment.yml.template | envsubst \
'$IMAGE_REGISTRY_RELEASE_NAME,$DEPLOYMENT_WIT_REPLICAS' > k8s/wit.deployment.yml
- ls -l
- kubectl apply -f k8s/wit.namespace.yml
- kubectl apply -f k8s/wit.service.yml
- kubectl apply -f k8s/wit.deployment.yml
```
`.gitlab-ci.yml`
```yaml
# Check the deployment of the application
# on the Kubernetes cluster
check-deployment-on-k8s:
stage: check-deployment
image: busybox
only:
# Execute the job only if a git tag is pushed
- tags
tags:
# Execute the job only on the runner tagged 'k8s'
- kubernetes
script:
- for i in 1 2 3 4 5 ; do wget wit.wit.svc.cluster.local:8080 -qO - ; sleep 1 ; done
```
Liens
-----
GitLab
* https://blog.axopen.com/2017/02/gitlab-cest-quoi/
* https://fr.slideshare.net/viniciusban/gitlab-flow-solo-39625228
* https://speakerdeck.com/ogom/gitlab-flow?slide=28
* https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/
* https://docs.gitlab.com/ee/README.html
Liens
-----
Git
* https://github.com/gitpitch/gitpitch
* https://mfilotto.github.io/gitlab-presentation
* https://speakerdeck.com/singingwolfboy/get-started-with-git?slide=34
* https://speakerdeck.com/singingwolfboy/advanced-git-2?slide=12
* https://blog.axopen.com/2017/02/git-comprendre-la-gestion-de-versions/