Sunny Tech 2019 – focus GitLab

Sunny Tech 2019, conférence Tech organisée par des passionnés pour des passionnés, était le rendez-vous à ne pas manquer en juin à Montpellier. Malgré la chaleur écrasante, l’équipe organisatrice a su maîtriser les aléas pour nous permettre de faire le plein de bonnes pratiques au fil des conférences.

Sur celles auxquelles j’ai pu assister, j’en ai sélectionné deux du même thème, qui me permettent d’aller plus loin dans mes process au quotidien.

Utilisation de la CI/CD GitLab :

Lors de ces conférences, nous avons pu constater que la CI/CD de GitLab avait fait le bonheur de beaucoup de DevOps. En effet, que ce soit pour automatiser de simples tâches ou mettre en place des tests, tout le monde y trouve son compte.

Logan Weber et Kevin Davin ont mis à disposition une CI complète avec job, stage et intégration avec des outils externes (PostgreSQL, Artifactory, Google Cloud Platform…), tout en la gardant simple et versionnable.

Lors de ces conférences, j’ai pu apprendre que nous pouvions utiliser des fonctions dans nos .yaml pour re factoriser et obtenir des CI/CD plus claires.

Exemple de fonction que j’ai pu utiliser pour un projet Kaliop :

.cicd_before_running: &cicd_before_running |
  function prereq() {
    echo "Preparing environment"
    ## Login to Harbor registry
    echo "$DOCKER_PASSWORD" | docker login docker-registry.kaliop.net -u "$DOCKER_USER" --password-stdin
    ## Run ssh-agent (inside the build environment)
    eval $(ssh-agent -s)
    ## Add the SSH key stored in SSH_PRIVATE_KEY variable to the agent store
    echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add - > /dev/null
    echo "$SSH_ANCA_PRIVATE_KEY" | tr -d '\r' | ssh-add - > /dev/null
    ## Create the SSH directory and give it the right permissions
    mkdir -p ~/.ssh
    chmod 700 ~/.ssh
    ## Add remote server ssh host key to known hosts
    ssh-keyscan -H '10.249.8.200' >> ~/.ssh/known_hosts
    ssh-keyscan -H '10.34.200.214' >> ~/.ssh/known_hosts
  }

## Deploy on dev (rec6) if merge ok on branches dev
deploy_rec:
  image: "klabs/automation"
  stage: deploy_rec
  tags:
    - kaliop-deploy-clients
  script:
    - *cicd_before_running
    - prereq
    - ssh -v -A -o StrictHostKeyChecking=no -o ProxyCommand='ssh -A site@10.34.200.214 -W %h:%p' root@172.17.214.200 "cd /opt/anca-deployment/ansible/ && ansible-playbook playbook_uat_composer_app.yml -vvv --tags=composer_app_update"
    - echo "Deployed with success !!!"
  when: on_success
  only:
    - dev

J’ai aussi pu voir la manière dont les speakers utilisaient le cache et les variables, ainsi que la réutilisation des artifacts, également utilisés pour un projet Kaliop :

# cache using branch name
# https://gitlab.com/help/ci/caching/index.md
cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - .npm
    - cache/Cypress
    - node_modules

Cette directive permet de jouer avec du cache. Le cache est intéressant pour spécifier une liste de fichiers et de répertoires à mettre en cache tout le long de votre pipeline. Une fois le pipeline terminé, le cache sera alors détruit.

artifacts:
    expire_in: 1 week
    when: always
    paths:
    - /builds/customers/aeroports-de-la-cote-d-azur/anca-ezplatform/anca-cypress/cypress/screenshots
    - /builds/customers/aeroports-de-la-cote-d-azur/anca-ezplatform/anca-cypress/cypress/videos

Les artefacts sont un peu comme du cache, mais ils peuvent être récupérés depuis un autre pipeline. Comme pour le cache, il faut définir une liste de fichiers ou/et répertoires qui seront sauvegardés par GitLab. Les fichiers sont sauvegardés uniquement si le job réussit.

Ont également été abordés, les outils de reporting, d’audit et de métrique. De JUnit à DAST, en passant par OpenMetrics, tout est mis en place pour la qualité et la sécurité. Par le biais d’exemples sur l’utilisation de DAST, nous avons vu comment étaient utilisés les templates dans la CI/CD.

Cette fonctionnalité permet de faire des templates réutilisables plusieurs fois.

.test_template: &test_template
  stage: test
  image: registry.gitlab.com/username/project/php:test
  before_script:
    - composer install -n
  when: on_success

.db_template:
  services:
    - postgres
    - mongo

test:unit:
  <<: *test_template
  script:
    - bin/phpunit --coverage-text --colors=never tests/

test:functional:
  <<: *test_template
  services: *db_template
  script:
    - codecept run functional

Voici ce que GitLab va interpréter :

test:unit:
  stage: test
  image: registry.gitlab.com/username/project/php:test
  before_script:
    - composer install -n
  script:
    - bin/phpunit --coverage-text --colors=never tests/
  when: on_success

test:functional:
  stage: test
  image: registry.gitlab.com/username/project/php:test
  services:
    - postgres
    - mongo
  before_script:
    - composer install -n
  script:
    - codecept run functional
  when: on_success

Avant de passer sur les Runners et leur installation, nous avons fait un bref passage sur les services.

Cette déclaration permet d’ajouter des services (container docker) de base pour vous aider dans vos jobs. Par exemple, si vous voulez utiliser une base de données pour tester votre application, c’est dans service que vous le demanderez.

test:end2end:
  image: klabs/automation:test
  services:
    - cypress # On appel le service `cypress` comme outil de test e2e
 before_script:
   - composer install -n
 script:
   - cypress run -b chrome

Lors de l’explication sur l’installation des runners, nous avons abordé l’auto scaling avec Kubernetes sur Google Platform. Cette conférence était assez courte (45 minutes), mais intense dans son contenu.

Pour visionner la présentation, les slides sont disponibles ici.

Utilisation de GitLab pour la gestion de projet / d’entreprise :

Lors de ces conférences, nous avons pu constater que GitLab fait bien plus que du versionning… En effet, que ce soit pour gérer un workflow de projet, des user stories, des avant-ventes, ou même une entreprise, cet outil semble être à la hauteur dans bien des domaines.

Philippe Charrière, Gestionnaire de compte technique chez GitLab et Fondateur de Bots.Garden, nous a fait une courte présentation de son parcours et de la naissance de l’idée d’utiliser un DCVS pour gérer un projet ou une entreprise.  Grâce à une démo, nous avons pu voir comment utiliser le système d’issues…

Couplé à des scripts en CI, cela permet de faire un changement automatique de statut, de tag ou même clôturer certaines tâches, ce qui facilite encore plus les processus. La rédaction de description étant effectuée en Markdown, cela peut être un frein pour des personnes non-familières avec le langage. Hormis ceci, tout reste très simple à comprendre et le workflow simple d’utilisation.

Pour visionner la conférence, la vidéo est disponible ici.

Ces deux conférences sur GitLab m’ont permis de découvrir des possibilités offertes par cet outil et d’ouvrir des portes sur des zones inconnues ou trop sombres. Philippe Charrière nous a démontré que GitLab ne sert pas seulement de DCVS mais bien plus. Tout est question de visions, d’idées et de workflows.

Un grand merci à tous les speakers ainsi qu’à l’équipe Sunny Guard !