Road-to-DevOps/Pepiniere/Pepinière/gitlab-presentation/introduction-a-gitlab.md

GitLab
======

<!-- .slide: data-background="#2E2E2E" data-state="nologo-slide" -->
![GitLab](images/gitlab-logo.svg "Gitlab logo") <!-- .element: width="200px" -->

__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  
<small>(Product Owner, Dev, Exploitant)</small>

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

![Forrester has evaluated GitLab as a Leader in Continuous Integration](images/forrester-ci-wave-graphic.png)

(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


![gitlab screen projects](images/gitlab-screen-projects.png)


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.


![Cycle de vie DevOps avec Gitlab](images/gitlab-devops-lifecycle-2.png)



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


![gitlab screen files](images/gitlab-screen-files.png)


![gitlab screen commits](images/gitlab-screen-commits.png)


![gitlab screen commit diff](images/gitlab-screen-commit-diff.png)



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.


![gitlab screen issues list](images/gitlab-screen-issues-list.png)


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


![gitlab screen issue](images/gitlab-screen-issue.png)


### Discussion

* Une "issue" peut être discutée via un système de commentaires intégré.


![gitlab screen issue](images/gitlab-screen-issue.png)


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


![gitlab screen issue board](images/gitlab-screen-issues-board.png)



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


![mattermost screen](images/mattermost-screen-chat.png)



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.  
<small>(avant de merger dans la branche de production)</small>

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


![CI-CD](images/ci-cd.png)


### 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_).


![gitlab screen pipelines](images/gitlab-screen-pipelines-2.png)


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


![gitlab screen pipeline definition](images/gitlab-screen-pipeline-definition.png)


### Runners

![Architecture runners](images/ci-cd-runners-architecture.png) <!-- .element: width="600px" -->

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.


![gitlab screen pipelines](images/gitlab-screen-pipeline-success.png)


![gitlab screen pipelines](images/gitlab-screen-pipeline-faillure.png)


Dans tous les cas il est possible d'accéder au détail de la tâche pour débugger.


![gitlab screen pipelines](images/gitlab-screen-pipeline-debug.png)


Un gros Pipeline !

![gitlab screen pipeline with a lot of stages](images/gitlab-screen-pipeline-with-a-lot-of-stages.png)


Possibilité de forcer un mode manuel pour les mises en production.


### Configurer un Pipeline CI / CD
`.gitlab-ci.yml`

![pipeline](images/gitlab-wit-pipeline-4.png)


<!-- .slide: data-state="small-code" -->
`.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
```


![pipeline](images/gitlab-wit-pipeline-1.png)

<!-- .slide: data-state="small-code" -->
`.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
```


![pipeline](images/gitlab-wit-pipeline-2.png)

<!-- .slide: data-state="small-code" -->
`.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
```


![pipeline](images/gitlab-wit-pipeline-3.png)

<!-- .slide: data-state="small-code" -->
`.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
```


![pipeline](images/gitlab-wit-pipeline-4.png)

<!-- .slide: data-state="small-code" -->
`.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/