2. Qu’est-ce que l’intégration continue ?
« L'intégration continue est un ensemble de
pratiques utilisées en génie logiciel consistant à
vérifier à chaque modification de code source que le
résultat des modifications ne produit
pas de régression dans l'application développée. »
Source : https://fr.wikipedia.org/wiki/Int%C3%A9gration_continue
3. Qu’est-ce que le déploiement continu ?
Le déploiement continu est une approche de génie
logiciel dans lequel les équipes produisent des
logiciels dans des cycles courts et veille à ce que le
logiciel soit fiable à tout moment.
Il vise à la construction, les essais et la diffusion des
logiciels plus rapidement et plus fréquemment.
Source : https://en.wikipedia.org/wiki/Continuous_delivery
4. Orchestrateur de tâches
Intégration continue via plugins
Intégration continue
Déploiement continu
Gestion du code source
Intégration continue
Déploiement continu
Collaboration entre les dev
Dashboard pour les issues
{
$129 / mois
11. Ajouter des runners Gitlab CI
Disponible sous Linux, Mac OS, Windows ou Docker
$ sudo gitlab-ci-multi-runner register
--url "https://gitlab.com/"
--registration-token "PROJECT_REGISTRATION_TOKEN"
--description "docker-php-7.0"
--executor docker
--docker-image php:7.0
… much more
12. Pipeline CI de merge request valide✅
composer install
npm install
…
phpunit
jasmine
…
SKIPPED
13. Pipeline CI de merge request invalide❌
composer install
npm install
…
phpunit
jasmine
…
SKIPPED
14. image: php:7.0
stages:
- build
- test
- notify
- deploy
Récupère l’image php:7.0 sur Docker hub
Exécutés dans l’ordre défini
Exécuté lors du merge (develop) ou
manuellement (production)
{ Exécutés lors d’une merge request
gitlab-ci.yml
15. build:
stage: build
before_script:
- bash ci/build-install.sh >
/dev/null
script:
- make build
artifacts:
paths:
- bin/
- vendor/
Build
Nom de la tâche
Nom du stage
Script d’installation du container
Tâche du Makefile ( ) exécutée
{ Ces répertoires seront récupérés
dans les stages suivantes
16. test:
stage: test
before_script:
- bash ci/test-install.sh > /dev/null
script:
- make test
except:
- master
- develop
when: on_success
artifacts:
paths:
- ./
Installation de xdebug pour les
rapports PHPUnit, …
{
Cette tâche ne se déclenchera pas
sur les branches master et develop
(mais se déclenchera sur les
branches des merge requests)
Les tests sont exécutés uniquement
si le build du projet n’a pas échoué
Test
17. notify:test:success:
stage: notify
before_script:
- bash ci/notify-install.sh > /dev/null
script:
- make notify-merge-request-success
when: on_success
notify:test:failure:
stage: notify
before_script:
- bash ci/notify-install.sh > /dev/null
script:
- make notify-merge-request-failure
when: on_failure
Notification en cas de succès des tests
Notification en cas d’échec des tests
Notify
19. Instance web d’une merge request
SERVEUR
NGINX
hook.php
Requête HTTP
(job Notify)
Récupération artifact
server {
server_name ~^(?<subdomain>.+).test-ci.composieux.fr$;
root /var/www/test-ci/$subdomain;
…
20. deploy:recette:
stage: deploy
script:
- make deploy-recette
environment: recette
only:
- develop
when: on_success
Déploiement automatique sur la recette
lors du merge d’une nouvelle
fonctionnalité
Déploiement si build réussi uniquement
Deploy
21. deploy:production:
stage: deploy
before_script:
- bash ci/deploy-install.sh > /dev/
null
script:
- make merge-master
- make deploy-production
environment: production
only:
- develop
when: manual
Merge sur la branche master
puis
déploiement en production
Déploiement manuel
seulement
{
Deploy
23. composer config cache-files-dir .composercache
cache:
paths:
- .composercache/
Composer
Cache les dépendances composer
entre les builds
À exécuter dans le container
24. deploy:recette:
before_script:
- 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
- eval $(ssh-agent -s)
- ssh-add <(echo "$SSH_PRIVATE_KEY")
- mkdir -p ~/.ssh
- '[[ -f /.dockerenv ]] && echo -e "Host *ntStrictHostKeyChecking nonn" >
~/.ssh/config’
script:
- ssh eleven-labs.com
Partager sa clé SSH avec les runners
À ajouter dans les variables du projet
Idéalement, mettre tout ceci dans le Makefile
25. Obtenir l’identifiant de la MR en cours …
curl -s -H "PRIVATE-TOKEN: $CI_API_TOKEN"
https://gitlab.com/api/v3/projects/$$CI_PROJECT_ID/merge_requests?state=opened
| jq '.[] | select(.source_branch|contains("$(shell echo $CI_BUILD_REF_NAME)")) | .id'
Token du compte @wilson-ci
Nom de la branche source de la merge request
26. Déclencher des builds CI via les « Triggers »
Disponible pour chaque projet dans « Triggers »
curl -X POST
-F token=TOKEN
-F ref=REF_NAME
https://gitlab.com/api/v3/projects/PROJECT_ID/trigger/builds
Nom de la branche à builder
27. job:
variables:
CI_DEBUG_TRACE: "true"
Nouveautés Gitlab CI 8.13
Pour débuguer les commandes shell, lister les variables, …
job:
variables:
GIT_STRATEGY:
none
Pour désactiver les opérations Git lorsque non nécessaire
(par exemple : déploiements via artifacts)
28. Conclusion
• Le module CI de Gitlab est un outil très complet
• « Pipeline simple » facile à mettre en place
• « Pipeline complexe » demande du code supplémentaire et
d’implémenter des webhooks / triggers
• CI sur merge requests demande d’être amélioré