.gitlab-ci.yml

Dans le Makefile, des étapes de base ont été définies afin de construire l’image de l’application, la stocker sur la registry, et lancer les services décrits dans le fichier docker-compose.yml.

Pour le moment la CI ne comprend pas encore la phase de tests de l’application, mais on peut déjà scénariser ces étapes de l’intégration en respectant la syntaxe de Gitlab dans le fichier .gitlab-ci.yml:

Définir les étapes #

Dans le fichier .gitlab-ci, on liste dans l’ordre les étapes de la pipeline qui seront lancées par la CI:

# stages to run in the ci (ordered)
stages:
    - pull       # pull latest images required for our build
    - build      # build the image
    - push       # push the image to the local registry
    - staging    # deploy the compose project on a staging server
    - production # deploy the compose project on a production server

Préparation #

Cette étape effectue des compilations diverses et la préparation des assets. Le travail se fait dans un conteneur, mais les sources et les destinations sont des volumes montés, et ainsi le résultat se trouvera sur place, disponible pour les étapes suivantes.

pull:
    # stage for this step
    stage: pull
    # command(s) to run
    script:
        # pull images (see Makefile)
        - make pull

Construction de l’image #

La CI va construire la ou les images contenant l’application, et va la pousser dans le registre, dument étiqueté pour pouvoir conserver un historique des versions sans risque de confusion.

build:
    stage: build
    script:
        # build images (see Makefile)
        - make build
push:
    stage: push
    script:
        # login to the local registry
        - echo $CI_BUILD_TOKEN | docker login -u $CI_REGISTRY_USER --password-stdin $CI_REGISTRY
        # push images (see Makefile)
        - make push

Déploiement #

La CI va déclencher le déploiement, qui utilisera la ou les images Docker disponibles dans le registre, tel que décrit dans le fichier docker-compose.yml.

NB: la phase de déploiement décrite ci-dessous concerne une application conteneurisée. Dans le cadre d’un déploiement en mode classique pour une application de type LAMP, c’est un autre système qui est utilisé.

staging:
    stage: staging
    environment:
        name: staging
        url: http://<myapp>.staging.bearstech.com
    only:
        - master
    script:
        # use the factory-deploy script to deploy the compose project
        # this will (re)start docker-compose on the target after pulling the new image
        - factory-deploy

production:
    stage: production
    environment:
        name: production
        url: http://yourwebsite.com
    script:
        - factory-deploy
    # we trigger deployement on the production serveur manualy
    when: manual
    # only for branch master
    only:
        - master
    # and we force this step to fail on failure
    allow_failure: false

Ici la phase de déploiement se fait sur 2 environnements: staging et production. Le déclenchement du déploiement en production est manuel: un bouton apparaît dans la pipeline uniquement lorsque le code est poussé sur la branche master.

Au final, vue dans Gitlab, la pipeline récapitule l’éxecution de toutes les étapes définies dans le .gitlab-ci.yml du projet (dans la capture ci-dessous, l’étape des tests a été ajoutée), où le déploiement en production reste une étape manuelle.