Introduction

Dans ce tutoriel nous allons voir comment mettre en place un CI/CD avec Gitlab.

Si vous voulez en savoir plus sur gitlab CI/CD j'ai aussi écrit un article sur le blog Eleven Labs CI/CD avec Gitlab-ci

Vous pouvez retrouver toute la documentation sur le site officiel de gitlab :

Le programme du tutoriel

Alors dans ce tuto nous allons mettre en place une CI/CD pour une application Vue.js avec GitLab-ci.

Voici les étapes du tuto :

  • Conception et préparation de l'environnement applicatif
  • Initialisation de la CI/CD et préparation de notre application pour notre CI/CD
  • Mise en place des phases de code style et de test
  • Déploiement de notre application sur Google Cloud PLatform
  • Test et conclusion

Pré-requis

Pour pouvoir faire ce tuto je vous conseille d'avoir d'installé node version 8 avec yarn.

  • Installation de node 8 :
# Using Ubuntu
curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -
sudo apt-get install -y nodejs

# Using Debian, as root
curl -sL https://deb.nodesource.com/setup_8.x | bash -
apt-get install -y nodejs
  • Installation de yarn
curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list

sudo apt-get update && sudo apt-get install yarn

yarn --version

Il faut aussi :

Suivant

Définition des besoins et préparation de notre application

Conception et préparation de l'environnement applicatif

Pour cette première étape nous allons commencer par définir nos besoins en termes de technologies à mettre en place mais aussi en termes de workflows git et de CI/CD. Puis nous allons initialiser notre application.

Conception

Les technologies

Docker pour notre environnement de développement. Node avec npm et yarn pour exécuter notre application sur notre environnement de dév. Make pour simplifier nos commandes dans la phase de développement.

Le workflow de le CI/CD

Voici les trois workflows de notre CI/CD que nous aurons a la fin de ce tutoriel :

Workflow gitlab-ci app js

Initialisation de l’application Vue.js

Pour faire simple et pour aller vite nous allons utiliser vue-cli. Nous allons donc installer vue-cli et initialiser un projet Vue.js.

$ yarn global add @vue/cli@3.0.1
# ...
$ vue --version
3.0.1

Si vous avez des soucis avec la commande vue pensez à regarder votre configuration npm/yarn, et si le chemin des exécutables npm/yarn est bien déclaré dans la variable $PATH.

Pour la prochaine étape : espace vous permet de sélectionner les choix, les flêches bas et haut de vous déplacer et entrée de valider

vue create .

# ---------------------------

Vue CLI v3.0.1
? Generate project in current directory? (Y/n) y

# ---------------------------

Vue CLI v3.0.1
? Please pick a preset:
  default (babel, eslint)
❯ Manually select features

# ---------------------------

Vue CLI v3.0.1
? Please pick a preset: Manually select features
? Check the features needed for your project:
❯◉ Babel
 ◯ TypeScript
 ◯ Progressive Web App (PWA) Support
 ◉ Router
 ◉ Vuex
 ◉ CSS Pre-processors
 ◉ Linter / Formatter
 ◉ Unit Testing
 ◉ E2E Testing

# ---------------------------

Vue CLI v3.0.1
? Please pick a preset: Manually select features
? Check the features needed for your project: Babel, Router, Vuex, CSS Pre-processors, Linter, Unit, E2E
? Use history mode for router? (Requires proper server setup for index fallback in production) (Y/n) Y

# ---------------------------

Vue CLI v3.0.1
? Please pick a preset: Manually select features
? Check the features needed for your project: Babel, Router, Vuex, CSS Pre-processors, Linter, Unit, E2E
? Use history mode for router? (Requires proper server setup for index fallback in production) Yes
? Pick a CSS pre-processor (PostCSS, Autoprefixer and CSS Modules are supported by default): (Use arrow keys)
❯ SCSS/SASS
  LESS
  Stylus

# ---------------------------

Vue CLI v3.0.1
? Please pick a preset: Manually select features
? Check the features needed for your project: Babel, Router, Vuex, CSS Pre-processors, Linter, Unit, E2E
? Use history mode for router? (Requires proper server setup for index fallback in production) Yes
? Pick a CSS pre-processor (PostCSS, Autoprefixer and CSS Modules are supported by default): SCSS/SASS
? Pick a linter / formatter config:
  ESLint with error prevention only
  ESLint + Airbnb config
❯ ESLint + Standard config
  ESLint + Prettier

# ---------------------------

Vue CLI v3.0.1
? Please pick a preset: Manually select features
? Check the features needed for your project: Babel, Router, Vuex, CSS Pre-processors, Linter, Unit, E2E
? Use history mode for router? (Requires proper server setup for index fallback in production) Yes
? Pick a CSS pre-processor (PostCSS, Autoprefixer and CSS Modules are supported by default): SCSS/SASS
? Pick a linter / formatter config: Standard
? Pick additional lint features: (Press <space> to select, <a> to toggle all, <i> to invert selection)
❯◉ Lint on save
 ◯ Lint and fix on commit

# ---------------------------

 Vue CLI v3.0.1
 ? Please pick a preset: Manually select features
 ? Check the features needed for your project: Babel, Router, Vuex, CSS Pre-processors, Linter, Unit, E2E
 ? Use history mode for router? (Requires proper server setup for index fallback in production) Yes
 ? Pick a CSS pre-processor (PostCSS, Autoprefixer and CSS Modules are supported by default): SCSS/SASS
 ? Pick a linter / formatter config: Standard
 ? Pick additional lint features: Lint on save
 ? Pick a unit testing solution: (Use arrow keys)
 ❯ Mocha + Chai
   Jest

# ---------------------------

Vue CLI v3.0.1
? Please pick a preset: Manually select features
? Check the features needed for your project: Babel, Router, Vuex, CSS Pre-processors, Linter, Unit, E2E
? Use history mode for router? (Requires proper server setup for index fallback in production) Yes
? Pick a CSS pre-processor (PostCSS, Autoprefixer and CSS Modules are supported by default): SCSS/SASS
? Pick a linter / formatter config: Standard
? Pick additional lint features: Lint on save
? Pick a unit testing solution: Mocha
? Pick a E2E testing solution: (Use arrow keys)
❯ Cypress (Chrome only)
 Nightwatch (Selenium-based)

# ---------------------------

Vue CLI v3.0.1
? Please pick a preset: Manually select features
? Check the features needed for your project: Babel, Router, Vuex, CSS Pre-processors, Linter, Unit, E2E
? Use history mode for router? (Requires proper server setup for index fallback in production) Yes
? Pick a CSS pre-processor (PostCSS, Autoprefixer and CSS Modules are supported by default): SCSS/SASS
? Pick a linter / formatter config: Standard
? Pick additional lint features: Lint on save
? Pick a unit testing solution: Mocha
? Pick a E2E testing solution: Cypress
? Where do you prefer placing config for Babel, PostCSS, ESLint, etc.?
 In dedicated config files
❯ In package.json

# ---------------------------

Vue CLI v3.0.1
? Please pick a preset: Manually select features
? Check the features needed for your project: Babel, Router, Vuex, CSS Pre-processors, Linter, Unit, E2E
? Use history mode for router? (Requires proper server setup for index fallback in production) Yes
? Pick a CSS pre-processor (PostCSS, Autoprefixer and CSS Modules are supported by default): SCSS/SASS
? Pick a linter / formatter config: Standard
? Pick additional lint features: Lint on save
? Pick a unit testing solution: Mocha
? Pick a E2E testing solution: Cypress
? Where do you prefer placing config for Babel, PostCSS, ESLint, etc.? In package.json
? Save this as a preset for future projects? (y/N) y

# ---------------------------

Vue CLI v3.0.1
? Please pick a preset: Manually select features
? Check the features needed for your project: Babel, Router, Vuex, CSS Pre-processors, Linter, Unit, E2E
? Use history mode for router? (Requires proper server setup for index fallback in production) Yes
? Pick a CSS pre-processor (PostCSS, Autoprefixer and CSS Modules are supported by default): SCSS/SASS
? Pick a linter / formatter config: Standard
? Pick additional lint features: Lint on save
? Pick a unit testing solution: Mocha
? Pick a E2E testing solution: Cypress
? Where do you prefer placing config for Babel, PostCSS, ESLint, etc.? In package.json
? Save this as a preset for future projects? Yes
? Save preset as: .vuerc

# ---------------------------

? Pick the package manager to use when installing dependencies: (Use arrow keys)
❯ Use Yarn
 Use NPM

Voilà pour l’installation, on vérifie que l’application fonctionne avec cette commande :

yarn serve

Screenshot app Vue.js init

Make

Pour simplifier les commandes docker et pour que l’application soit sous docker, j'ai fait un makefile. Je l’utilise dans la majorité de mes applications et ça fonctionne bien.

Comme le tuto ne porte pas sur ce sujet je vous le donne sans vous donner l'explication mais ça sera peut-être un sujet que j’aborderai dans l’avenir :).

Voici le lien vers le makefile en question : Makefile pour application node

PrécédentSuivant

Initialisation de la CI/CD et préparation de notre application pour notre CI/CD

Initialisation de la CI/CD et préparation de l'application pour notre CI/CD

Pour cette deuxième étape nous allons initialiser la CI/CD et préparer notre application pour le temps d'exécution de notre CI/CD.

Initialisation du repository gitlab

Bon, sur cette partie je pense que je ne vais rien vous apprendre. Rendez-vous sur l’interface de gitlab, puis dans projet, et enfin cliquez sur New project.

Screenshot create project gitlab

Ensuite depuis votre console :

mkdir gitlas-ci-js && cd gitlas-ci-js

git init
git remote add origin git@gitlab.com:ngrevin/gitlab-ci-js.git
git add .
git commit -m "Initial commit"
git push -u origin master

# Si vous avez plusieurs comptes Github / GitLab / … pensez à changer votre config
git config user.name "ngrevin"
git config user.email "ngrevin@eleven-labs.com"

On va en profiter pour créer notre branche demo et protéger les branches demo et master, ainsi que tous les tags. Pour ce faire rendez-vous sur l'interface web de Gitlab et allez dans Settings > General > Repository

Screenshot protected branch Screenshot protected tag

Initialisation de la CI/CD de gitlab-ci

Pour cette partie, rien de compliqué. Il faut juste ajouter un fichier .gitlab-ci.yml à la racine de votre projet et pour que la CI puisse fonctionner nous allons juste mettre une déclaration script dans un job.

init:gitlab-ci:
  script:
   - echo 'hello gitlab-ci'

On push nos modifications :

git checkout -b gitlab-ci-js/hello-gitlab-ci
git add .
git commit -m “gitlab-ci-js/hello-gitlab-ci - add .gitlab-ci.yml”
git push origin gitlab-ci-js/hello-gitlab-ci

Et voilà le résultat :

Resultat initialisation gitlab-ci

Préparation de notre application pour notre CI/CD

Lors de l'exécution de la CI/CD nous aurons besoin de notre application déjà construite avec toutes ces dépendances.

On va avoir besoin de notre application dans deux états : La version construite avec les dépendances de développement pour les codes styling et les tests La version construite sans les dépendances de développement et les fichiers compilés pour le futur déploiement

stages:
  - build

.template_build: &template_build # Template commun aux deux jobs de la stage build
  stage: build # On lie les jobs au stage de build
  image: node:8-alpine # On utilise l’image de node 8

build:node_modules:
  <<: *template_build # on appelle notre template
  script: # Les scripts exécutés pendant ce job
    - yarn install
  cache: # on définit notre cache
    policy: push
    paths:
      - ./node_modules
  except: # On définit une règle d'exécution : ce job sera fait tout le temps sauf sur master et demo, mais aussi en cas de tag
    - master
    - demo
    - tags

build:app:
  <<: *template_build # on appelle notre template
  before_script: # On met à jour la version de package.json si nous sommes sur un tag
    - if [ ! -z "${CI_COMMIT_TAG}" ]; then npm version ${CI_COMMIT_TAG:1}; fi
  script: # Les scripts exécutés pendant ce job
    - yarn install
    - yarn build
  after_script: # On sauvegarde le fichier package.json dans le répertoire "dist" pour le mettre en cache
    - cp package.json dist/package.json
  cache: # on définit notre cache
    policy: push
    paths:
      - ./dist
      - ./node_modules
  only: # On définit une règle d'exécution : ce job sera fait uniquement sur demo ou en cas de tag
    - demo
    - tags
  except: # On définit une règle d'exécution : ce job ne se fera pas sur master
    - master

Voici quelques liens pour avoir des explications sur les définitions utilisés :

On push nos modifications :

git checkout -b gitlab-ci-js/step1
git add .
git commit -m “gitlab-ci-js/step1 - add .gitlab-ci.yml”
git origin gitlab-ci-js/step1

Et voilà notre CI/CD :

Résultat CI/CD stage build

Vous créez une PR et vous la mergez dans master. Et voilà pour la première étape ! Passons à la suivante.

PrécédentSuivant

Mise en place des phases de code style et de tests

Mise en place des phases de code style et de test

Pour cette troisième étape, nous allons mettre en place le code style et les tests sur notre CI. Pour ce faire nous allons devoir ajouter des dépendances à notre projet pour le code style du scss.

Installation des dépendances

Pour le code style du scss nous allons avoir besoin de stylelint avec stylelint-processor-html pour fonctionner avec Vue.js. Nous utiliserons les règles de base avec stylelint-config-standard

make yarn "add -D stylelint stylelint-processor-html stylelint-config-standard"

Configuration de stylelint

Nous allons mettre en place une configuration standard dans le fichier que vous devez créer sous nom de .stylelintrc et qui doit être placé à la racine de votre projet.

{
  "processors": ["stylelint-processor-html"],
  "extends": "stylelint-config-standard"
}

Création des commandes

Pour faire fonctionner notre code style scss nous allons ajouter une commande au fichier package.json et en modifier une autre

  "scripts": {
    "serve": "vue-cli-service serve",
    "build": "vue-cli-service build",
-    "lint": "vue-cli-service lint --no-fix",
+    "lint": "yarn lint:js && yarn lint:scss",
+    "lint:js": "vue-cli-service lint --no-fix",
+    "lint:scss": "stylelint '**/*.vue' --syntax scss",
    "test": "yarn test:unit && yarn test:e2e",
    "test:unit": "vue-cli-service test:unit",
    "test:e2e": "vue-cli-service test:e2e"
  },

Application à la CI/CD

Nous n'avons plus qu'à ajouter deux étapes comprenant chacune deux jobs.

stages:
  - build
  - lint # Nouvelle étape pour les code style
  - test # Nouvelle étape pour les tests

# ...

.template_lint_and_test: &template_lint_and_test # Définition du template pour les codes style et les tests
  image: node:8-alpine # On utilise l’image de node 8
  cache: # Définition des règles de cache pour récuperer les caches de l'étape de build
    paths:
      - ./node_modules
    policy: pull
  when: on_success # Condition d'exécution : sera exécuté uniquement si les jobs de l'étape précédente réussissent
  except:
    - tags
    - master

lint:js:
  <<: *template_lint_and_test # on appel notre template
  stage: lint # On lie le job au stage de lint
  script: # Les scripts exécutés pendant ce job
    - yarn lint:js

lint:scss:
  <<: *template_lint_and_test # on appelle notre template
  stage: lint # On lie le job au stage de lint
  script: # Les scripts exécutés pendant ce job
    - yarn lint:scss

test:unit:
  <<: *template_lint_and_test # on appel notre template
  stage: test # On lie le job au stage de test
  script: # Les scripts exécutés pendant ce job
    - yarn test:unit

test:e2e:
  <<: *template_lint_and_test # on appel notre template
  image: cypress/base:8 # On utilise un image différente pour les test e2e. overwrite de l'image de base du template
  stage: test # On lie le job au stage de test
  cache: {} # On désactive le cache pour cette étape
  script: # Les scripts exécutés pendant ce job
    - yarn install
    - yarn cypress install
    - yarn run test:e2e --headless

# ...

Voici quelques liens pour avoir des explications sur les nouvelle définitions utilisés :

On push nos modifications :

git checkout -b gitlab-ci-js/step2
git add .
git commit -m “gitlab-ci-js/step2 - update .gitlab-ci.yml”
git origin gitlab-ci-js/step2

Et voilà notre CI/CD :

résultat CI/CD stage lint et test

Vous créez un PR et vous la mergé dans master. Et voilà pour la deuxième étape, passons à la suivante.

PrécédentSuivant

Déploiement de notre application sur Google Cloud Platform

pour cette quatrième et dernière partie nous allons voir comment déployer notre application sur Google Cloud PLatform (GCP) avec App Engine.

Pour ce faire nous allons devoir :

  • Créer un projet sur Google Cloud Platform.
  • Configurer le projet Google Cloud Platform.
  • Créer un credential pour pouvoir se connecter depuis notre CI/CD.
  • Créer le fichier app.yml pour App Engine.
  • Créer une image docker personnalisée pour notre déploiement
  • Créer un token pour pouvoir faire des pushs depuis notre CI/CD
  • Ajouter un stage de déploiement.

Création du projet Google Cloud Platform

La première chose à faire c’est de se connecter ou s'inscrire sur la console de Google Cloud Platform. Si tout va bien vous arriverez sur cette page :

Home page de la console Google Cloud Platform

Puis vous cliquez sur créer et vous entrez le nom de votre projet. Vous pouvez aussi customiser l’ID de votre projet :

Page de création de projet GCP

/!\ Dans mon cas, l’ID du projet est déjà utilisée car je l’avais déjà créée.

Configuration du projet Google Cloud Platform

Pour le déploiement sur GCP App Engine il faut activer deux APIs :

  • App Engine Admin API : cette API permet de provisionner et de manager des applications App Engine.
  • Compute Engine API : cette API permet de créer et de démarrer des machines dans GCP.

Pour activer une API il faut, depuis la console GCP, aller dans le menu droite dans API et services. Ensuite, allez dans la bibliothèque, et avec la barre de recherche trouvez les APIs que vous intéressent. Accédez à la page de l’API et activez-la.

Création de credential

Il nous faudra aussi des identifiants pour nous connecter depuis la CI/CD. Pour ce faire, toujours dans API et services, allez dans la sous-section identifiant et cliquez sur créer des identifiants puis créer une clé de compte de service.

Vous arrivez sur l'écran ci-dessous. Sélectionnez App Engine default service account et json.

Création de clé de compte de service

Un fichier au format json est automatiquement téléchargé sur votre ordinateur. Copiez l'intégralité du contenu de ce fichier et allez dans l’interface web de Gitlab dans Settings > CI/CD > Variables.

Ici, nous créons une nouvelle variable que l’on va nommer GCP_CREDENTIALS et contenant le contenu du fichier précédemment téléchargé.

Gitlab - CI/CD Settings - Variables

Voilà pour le credential.

/!\ N'activez pas la protection, autrement la variable ne pourra pas être utilisée dans les prochaines étapes

fichier app.yaml pour le déploiement sur App Engine

Nous allons faire un template pour le fichier app.yaml afin qu’il soit généré selon son environnement grâce l’outil envsubst du paquet gettext.

Voici le template du fichier app.yaml :

service: ${CI_ENVIRONMENT_NAME}
runtime: python27
api_version: '1'
env: standard
threadsafe: true
instance_class: F1

handlers:
  - url: /
    application_readable: false
    static_files: dist/index.html
    require_matching_file: false
    upload: dist/index.html

  - url: '/(.*)'
    application_readable: false
    static_files: "dist/\\1"
    require_matching_file: false
    upload: 'dist/.*'

Nous allons nommer ce fichier app.template.yaml. Dans notre CI/CD nous éxécuterons la commande suivante envsubst < app.template.yaml > app.yaml, elle nous permettera de modifier les variables d'environnement de notre fichier et de créer le fichier app.yml.

Création d'une image docker personnalisée pour notre déploiement

Nous allons avoir besoin d'une image personnalisée car nous allons avoir besoin de node, de git et du sdk de Google Cloud Plateform.

Dans le cas où vous n'auriez pas besoin de git et de node sachez qu'il existe une image docker avec le sdk de GCP déjà installé. google/cloud-sdk

Pour ce faire, créez un fichier Dockerfile-ci dans un nouveau répertoire nommé docker. Voici le Dockerfile :

FROM node:8-alpine

ARG CLOUD_SDK_VERSION=216.0.0
ENV CLOUD_SDK_VERSION=$CLOUD_SDK_VERSION

ENV PATH /google-cloud-sdk/bin:$PATH
RUN apk --no-cache add \
        curl \
        python \
        py-crcmod \
        bash \
        libc6-compat \
        openssh-client \
        git \
        gnupg \
        gettext \
    && curl -O https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-${CLOUD_SDK_VERSION}-linux-x86_64.tar.gz && \
    tar xzf google-cloud-sdk-${CLOUD_SDK_VERSION}-linux-x86_64.tar.gz && \
    rm google-cloud-sdk-${CLOUD_SDK_VERSION}-linux-x86_64.tar.gz && \
    ln -s /lib /lib64 && \
    gcloud config set core/disable_usage_reporting true && \
    gcloud config set component_manager/disable_update_check true && \
    gcloud config set metrics/environment github_docker_image && \
    gcloud --version


RUN apk add --update --no-cache git

RUN rm -rf /var/cache/apk/*

Nous allons mettre notre image sur le registry de notre dépôt. Pour ce faire nous éxécutons les commandes suivantes :

# On se connecte au registry de gitlab.com
docker login registry.gitlab.com

# Nous construissons notre image docker
docker build -t registry.gitlab.com/ngrevin/gitlab-ci-js/deploy-image .

# Et nous poussons notre image sur le registry
docker push registry.gitlab.com/ngrevin/gitlab-ci-js/deploy-image

Token gitlab

Pour créer un token sur gitlab rendez-vous sur la page Personal Access Token Profile > Personal Access Token. Donnez-lui un nom, ici j'ai choisi PERSONAL_ACCESS_TOKEN, et donnez-lui les droits suiffisants.

En suite, comme pour les credentials de GCP, créez une variable d'environnement dans votre projet avec l'access token précédement créé.

/!\ N'activez pas la protection, autrement la variable ne pourra pas être utilisée dans les prochaines étapes

Le stage deploy

Maintenant que tout est prêt il nous reste juste à déployer notre application avec Gitlab-ci.

Nous allons donc ajouter deux nouveaux jobs dans notre dernière stage.

.deploy_template: &deploy_template # On defini notre template pour le deploiement de notre application
  stage: deploy # On lie nous prochain job avec le stage 'deploy'
  image: registry.gitlab.com/ngrevin/gitlab-ci-js/deploy-image #
  before_script: # Avant le script principale nous faisons :
    - echo ${GCP_CREDENTIALS} > /tmp/${CI_PIPELINE_ID}.json # Nous récuperons notre variables 'GCP_CREDENTIALS' et on la sauvegarde dans un fichier
    - gcloud auth activate-service-account --key-file /tmp/$CI_PIPELINE_ID.json # Grâce au fichier précédement créer nous nous connectons à GCP
    - envsubst < app.template.yaml > app.yaml # Nous créons notre fichier 'app.yml'
  after_script: # Après le script principale nous faisons :
    - rm /tmp/$CI_PIPELINE_ID.json  # On supprime toute trace de nos credentials GCP
  cache: # Définition des règles de cache pour récuperer les caches de l'étape de build
    paths:
      - ./dist
    policy: pull

deploy:demo:
  <<: *deploy_template # on appel notre template
  environment: # On définit notre environnment
    name: demo
    url: https://demo-dot-gitlab-ci-js.appspot.com # on indique l'url de notre application de demo
  script:
    # Nous déployons notre application avec la commande 'gcloud app deploy ./app.yml --project=gitlab-ci-js'
    # Comme nous ne voulons pas d'interaction nous ajoutons l'option 'quiet'
    # Comme nous voulons voir le log lors du déploiement nous ajoutons l'option 'verbosity' avec la valeur à 'error'
    # Le numéro de version sera l'id de la pipeline
    # Avec '--promote --stop-previous-version' nous arrêtons la version précédente en promouvant la nouvelle version
    - gcloud --quiet --verbosity=error app deploy ./app.yaml --project=gitlab-ci-js --version=${CI_PIPELINE_ID} --promote --stop-previous-version
  only:
    - demo

deploy:production:
  <<: *deploy_template # on appelle notre template
  environment: # On définit notre environnment
    name: production
    url: https://production-dot-gitlab-ci-js.appspot.com # on indique l'url de notre application de production
  script:
    # Idem que pour l'environnment de demo
    - gcloud --quiet --verbosity=error app deploy ./app.yaml --project=gitlab-ci-js --version=${CI_PIPELINE_ID} --promote --stop-previous-version
    # Nous configurons git et nous mettons à jour l'origine avec notre token
    - git config --global user.name "ngrevin"
    - git config --global user.email "${GITLAB_USER_EMAIL}"
    - git remote rm origin
    - git remote add origin https://${GITLAB_USER_LOGIN}:${PERSONAL_ACCESS_TOKEN}@gitlab.com/ngrevin/gitlab-ci-js.git
    - git fetch --all
    # Nous passons sur demo et nous copions 'dist/package.json' à la racine de notre projet pour remplacer l'ancien fichier 'package.json' car la version a été mise à jour lors de job build:app
    - git checkout demo
    - cp dist/package.json .
    # On récupère le numéro de version grâce a la commande 'yarn versions' et nous la formattons sans d'autre information que le numéro, et sans couleur
    - NEW_VERSION=$(yarn versions | grep gitlab-ci-js | sed "s/\('\| \|,\)//g" | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g" | cut -d":" -f2)
    # On ajoute nos modifications, on commit et on pousse les modifications
    - git add --all
    - git commit -m "NEW VERSION - v${NEW_VERSION}"
    - git push https://${GITLAB_USER_LOGIN}:${PERSONAL_ACCESS_TOKEN}@gitlab.com/ngrevin/gitlab-ci-js.git demo
    # Ici nous allons merge demo dans master en écrasant master par rapport à demo, puis nous poussons les modifications sur master
    - git merge -s ours origin/master -m "Merge for new version"
    - git checkout master
    - git merge --no-ff --commit -m "NEW VERSION - v${NEW_VERSION}" demo
    - git push https://${GITLAB_USER_LOGIN}:${PERSONAL_ACCESS_TOKEN}@gitlab.com/ngrevin/gitlab-ci-js.git master
  artifacts:
    name: "${CI_COMMIT_TAG:1}"
    untracked: false
    paths:
      - .
  only:
    - tags

Voici quelques liens pour avoir des explications sur les nouvelle définitions utilisés :

  • [environment]/fr/introduction-gitlab-ci/#environment)
  • artifacts

On push nos modifications :

git checkout -b gitlab-ci-js/step3
git add .
git commit -m “gitlab-ci-js/step3 - add .gitlab-ci.yml”
git origin gitlab-ci-js/step3

Vous créez une PR et vous la mergez dans demo

Et voilà le résultat de notre CI/CD pour le déploiement en démo :

résultat CI/CD déploiement production

PrécédentSuivant

Test et conclusion

Voilà nous arrivons au terme de ce tutoriel.

je vous ai présenté comment mettre en place une CI/CD avec Gitlab et Google Cloud Platform.

Avant de conclure ce tutoriel je vais vous montrer quelques résultats de tests que j'ai effectués.

Test

Lors de mes phases de tests j'ai arrêté quelques déploiements en demo suite à un push de la pipeline de déploiement en production. Vous pouvez voir sur la capture d'écran ci-desous les différences de version.

Workflow gitlab-ci app js

Je ne vous ai pas montré le résultat d'une pipeline suite à un tag donc voici ce que ça donne :

résultat CI/CD déploiement production

Et voici une vue d'ensemble d'un déploiement sur demo et production :

résultat CI/CD déploiement demo et production

Nous pouvons très clairement voir que suite à un merge (ici ce fut un push de correction) la pipeline de deploiement en demo est exécuté. Puis j'ai créé un nouveau tag "v0.0.28" ce qui a déclenché la pipeline de depliement en production. Suite a ce tag les branches se sont mises à jour et la pipeline de deploiement en demo s'est déclenchée avec comme nom de commit NEW VERSION - v0.0.28

Conclusion

Les étapes de build, de lint et de test restent très simples à mettre en place mais ça se complique lors du déploiement car il y a plus de choses à prendre en compte. De plus, dans ce tutoriel je n'ai pas eu envie de faire les choses simplement avec des mises à jour de branche dans la pipeline.

Je vous ai montré un exemple mais il existe des milliers de possibilités de configuration. Cela ne dépend que de vous et de votre projet.

Peut-être l'aurez-vous remarqué, mais gitlab peut être quelque fois lent ou présenter des bugs. Pour des petits projets ce n'est pas forcément dérangeant.

J'éspère que ce tutoriel vous a été utile et vous a donné envie de mettre une CI/CD dans vos projet pour les rendre plus Agiles avec le mouvement DevOps.

Précédent