DevOps #5 - Gitlab CI

DevOps #5 Gitlab CI

Ce workshop s’effectuer sur la plateforme Gitlab

Processus de CI/CD

Une étape de CI

stages est utilisé pour définir les étapes qui contiennent des travaux et est défini globalement pour le pipeline.

La spécification de stagespermet d’avoir des pipelines flexibles à plusieurs étages. L’ordre des éléments dans stagesdéfinit l’ordre d’exécution des jobs:

• Les travaux de la même étape sont exécutés en parallèle.
• Les travaux de l’étape suivante sont exécutés une fois les travaux de l’étape précédente terminés.

Créer un fichier gitlab-ci.yml

image: alpine:3.12.0

stages:
   - dependencies
   - test
   - build
   - staging
   - preproduction
   - release
   - production

"dependencies 1":
  stage: dependencies
  script: 
    - echo "Je récupère mes dépendances"

1. Tout d’abord, tous les travaux de dependencies sont exécutés en parallèle.
2. Si tous les travaux dependencies réussissent, les test travaux sont exécutés en parallèle.
3. Si tous les travaux test réussissent, les build travaux sont exécutés en parallèle.
4. Si toutes les tâches build réussissent, la validation est marquée comme passed.
5. Si l’une des tâches précédentes échoue, la validation est marquée failed et aucune tâche de l’étape ultérieure n’est exécutée.

Parallèle des stages

Les tâches dependencies 1 et dependencies 2 sont executés en parallèle.

"dependencies 2":
  stage: dependencies
  before_script :
    - echo "Avant le script !"
  script: 
    - echo "Hello World"
    - exit 1
  after_script :
    - echo "Après le script !"

before_scriptest utilisé pour définir une commande qui doit être exécutée avant chaque travail, y compris les travaux de déploiement, Les scripts spécifiés dans before_scriptsont concaténés avec tous les scripts spécifiés dans le main script, et exécutés ensemble dans un seul shell.

after_scriptest utilisé pour définir la commande qui s’exécute après chaque travail, y compris les échecs. Les scripts spécifiés dans after_scriptsont exécutés dans un nouveau shell, séparé de tout script before_scriptou script.

Only / Except

only et except sont deux paramètres qui définissent une stratégie de travail à limiter lorsque des travaux sont créés:

• only définit les noms des branches et des balises pour lesquelles le travail s’exécute.
• exceptdéfinit les noms des branches et des balises pour lesquelles le travail ne s’exécute pas .

Vous pouvez utiliser l’indicateur | scalaire de bloc multiligne YAML (littéral) pour écrire des commandes sur plusieurs lignes dans la script section d’une description d’une étape. Chaque ligne est traitée comme une commande distincte.

"test 1":
  stage: test
  script: 
    - echo "Hello World"
  only:
    - master

"test 2":
  stage: test
  script: 
    - echo "Hello World"
  except:
    - master

"test 3":
  stage: test
  script: 
    - echo "Hello World"

"test 4":
  stage: test
  script: |
    echo "première commande"
    echo "deuxième commande"
    echo "troisième commande"

Merge request

On peut spécifier en plus des branches ou des tags des merges requests.

"build":
  stage: build
  script: 
    - echo "Hello World"
  only :
    - merge_request

Spécifique sur un fichier

Créer un fichier nommé README.md

# Hello :smile:

Modifier le fichier .gitlab-ci.yml

"dependencies 1":
  stage: dependencies
  script: 
    - echo "Je récupère mes dépendances"
  except:
    changes:
      - "README.md"

Environnement

environmentest utilisé pour définir qu’un travail se déploie dans un environnement spécifique. Si environmentest spécifié et qu’aucun environnement sous ce nom n’existe, un nouveau sera créé automatiquement.

"delivery staging":
  stage: staging
  script: 
    - echo "Hello World"
  environment:
    name: staging
    url: http://localhost:8080/

Dans l’exemple ci-dessus, le delivery staging sera marqué comme effectué un déploiment dans l’enviornnment staging.

Release

releaseindique que le travail crée une version.

Ces méthodes sont prises en charge:

• tag_name
• name (optionnel)
• description (optionnel)
• ref (optionnel)
• milestones (optionnel)
• released_at (optionnel)

"release":
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  rules:
    - if: $CI_COMMIT_TAG                  # Run this job when a tag is created manually
  script:
    - echo 'running release_job'
  release:
    name: 'Release $CI_COMMIT_TAG'
    description: 'Created using the release-cli $EXTRA_DESCRIPTION'  # $EXTRA_DESCRIPTION must be defined
    tag_name: '$CI_COMMIT_TAG'                                       # elsewhere in the pipeline.
    ref: '$CI_COMMIT_TAG'
    milestones:
      - 'm1'

Include

L’utilisation du includemot - clé permet l’inclusion de fichiers YAML externes. Cela permet de décomposer la configuration CI / CD en plusieurs fichiers et augmente la lisibilité des longs fichiers de configuration. Il est également possible que les fichiers de modèle soient stockés dans un référentiel central et que les projets incluent leurs fichiers de configuration. Cela permet d’éviter la configuration dupliquée, par exemple, les variables globales par défaut pour tous les projets.

includenécessite que le fichier YAML externe ait les extensions .ymlou .yaml, sinon le fichier externe n’est pas inclus.

include prend en charge les méthodes d’inclusion suivantes:

• local : Incluez un fichier du référentiel de projet local.
• file : Incluez un fichier d’un référentiel de projet différent.
• remote : Incluez un fichier à partir d’une URL distante. Doit être accessible au public.
• template : Incluez les modèles fournis par GitLab.

Créer un répertoire template, dans ce répertoire créer le fichier Delivery-Preproduction.gitlab-ci.yml.

"delivery preproduction":
  stage: preproduction
  script: 
    - echo "Hello World"
  environment:
    name: preproduction
    url: http://localhost:8080/

Ajouter cette ligne dans votre fichier gitlab-ci.yml

include: 
  - local: '/template/Delivery-Preproduction.gitlab-ci.yml'

Etape semi-manuel

Les actions manuelles sont un type spécial de travail qui ne sont pas exécutées automatiquement, elles doivent être explicitement démarrées par un utilisateur. Un exemple d’utilisation d’actions manuelles serait un déploiement dans un environnement de production. Les actions manuelles peuvent être lancées à partir des vues de pipeline, de travail, d’environnement et de déploiement.

"delivery production":
  stage: production
  script: 
    - echo "Hello World"
  environment:
    name: production
    url: http://localhost:8080/
  only:
    - tags
  when: manual

Fichier final

image: alpine:3.12.0

stages:
   - dependencies
   - test
   - build
   - staging
   - preproduction
   - release
   - production


"dependencies 1":
  stage: dependencies
  script: 
    - echo "Je récupère mes dépendances"
  except:
    changes:
      - "README.md"

"dependencies 2":
  stage: dependencies
  before_script :
    - echo "Avant le script !"
  script: 
    - echo "Hello World"
    - exit 1
  after_script :
    - echo "Après le script !"
  retry: 
    max: 2
    when: runner_system_failure
  allow_failure : true

"test 1":
  stage: test
  script: 
    - echo "Hello World"
  only:
    - master

"test 2":
  stage: test
  script: 
    - echo "Hello World"
  except:
    - master

"test 3":
  stage: test
  script: 
    - echo "Hello World"

"test 4":
  stage: test
  script: |
    echo "première commande"
    echo "deuxième commande"
    echo "troisième commande"

"build":
  stage: build
  script: 
    - echo "Hello World"
  only :
    - merge_request

"delivery staging":
  stage: staging
  script: 
    - echo "Hello World"
  environment:
    name: staging
    url: http://localhost:8080/

"release":
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  rules:
    - if: $CI_COMMIT_TAG                  # Run this job when a tag is created manually
  script:
    - echo 'running release_job'
  release:
    name: 'Release $CI_COMMIT_TAG'
    description: 'Created using the release-cli $EXTRA_DESCRIPTION'  # $EXTRA_DESCRIPTION must be defined
    tag_name: '$CI_COMMIT_TAG'                                       # elsewhere in the pipeline.
    ref: '$CI_COMMIT_TAG'
    milestones:
      - 'm1'

"delivery production":
  stage: production
  script: 
    - echo "Hello World"
  environment:
    name: production
    url: http://localhost:8080/
  only:
    - tags
  when: manual

include: 
  - local: '/template/Delivery-Preproduction.gitlab-ci.yml'