• Installer et prendre en main un serveur Gitlab
• Comprendre les bases de l'intégration continue
• Installer Gitlab CI
• Expérimenter les possibilités

Autre chose ?

• Je ne suis pas un expert mais un experimenteur
• Domaine en constante évolution
• => Avoir les clés pour être autonome pour la suite

Accessible sur : https://slides.kgaut.net/node/4

Gitlab Cheat Sheet : https://docs.google.com/document/d/1suN0-sxsLUZsVc616ccL0QJ-IOR-6ss_WqYUaEPyu4g/edit#

• Github
• Bitbucket
• ...

Repo publics gratuits, privés payants.

• Gogs - gogs.io
• Gitea - gitea.io (fork de Gogs)

• Solution robuste et éprouvée
• Beaucoup d'intégrations
• Intégration de Mattermost
• CI incluse

• Serveur sous CentOS ou Debian / Ubuntu
• Accès SSH
• Compte e-mail type gitlab@entreprise.com avec accès pop et SMTP
• Connaissances basiques en CLI GNU/Linux

CF : https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/installation.md

CF : https://about.gitlab.com/downloads/

• Ubuntu 12.04, 14.04, 16.04 (recommended)
• Debian 7, 8
• CentOS 6, 7
• OpenSUSE 12.1, 13.2
• Raspberry PI 2 on Raspbian

• OS : CentOS 7 minimal
• IP : 192.168.1.18
• Domaine : gitlab.vm

Depuis un autre poste : ssh root@gitlab.vm

Si cela ne fonctionne pas :

• installation de ssh-server
• vérification du fichier /etc/ssh/sshd_config (PermitRootLogin yes)

yum update

yum install vim

Procédure : https://about.gitlab.com/downloads/

sudo yum install curl policycoreutils openssh-server openssh-clients
sudo systemctl enable sshd
sudo systemctl start sshd
sudo yum install postfix
sudo systemctl enable postfix
sudo systemctl start postfix
sudo firewall-cmd --permanent --add-service=http
sudo systemctl reload firewalld

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash
sudo yum install gitlab-ce

sudo gitlab-ctl reconfigure

Identifiant : http://gitlab.vm/profile/account

email, mot de passe : http://gitlab.vm/profile

# Modification du fichier de configuration
vim /etc/gitlab/gitlab.rb

# Reconfiguration de gitlab
gitlab-ctl reconfigure

...

Automatiser la construction d'une "build"

• Génération des assets
• « Compilation »
• Tests unitaires
• ...

Github + Travis CI (https://travis-ci.org/)

Quand push sur "master" -> lancement de tests

• Script exécuté lors d'une action
• Local (pre commit) distant (post receive)
• scripts dans le .git/hooks d'un dépot

Attention : Gitlab utilise déjà ces hooks pour fonctionner, ne pas les modifier ! utiliser les "custom_hooks"

Exemple.

• Solution type "travis"
• Intégrable facilement à côté d'un gitlab
• n gitlab <=> n gitlab CI (même sur des serveurs différents)
• Principe de "Runner"

https://docs.gitlab.com/runner/install/linux-repository.html

=> Pas besoin de docker pour l'instant

Si erreur X509 : https://kgaut.net/journal/2016/gitlab-ci-resoudre-lerreur-x509-certific…

1. Création d'un dépot
2. Création du fichier .gitlab-ci.yml
3. Tests

Défini le comportement.

stages:
  - deploy

prod-deployment:
  stage: deploy
  script:
    -  ssh slides_kgaut_net@slides.kgaut.net 'bash -s' < scripts/prod-deployment.sh
  only:
    - master

mail:
  script: "echo 'coucou' | mail -s 'test email' contact@kgaut.net"

mail:
  script: "echo 'coucou' | mail -s 'test email' contact@kgaut.net"
mail2:
  script: "echo 'coucou' | mail -s 'test email 2' contact+test@kgaut.net"

mail:
  script: "echo 'push sur master' | mail -s 'push sur master' contact@kgaut.net"
  only:
    - master
mail2:
  script: "echo 'coucou' | mail -s 'push une branche' contact+test@kgaut.net"

Groupement de jobs qui seront exécutés en parallèle.

Si plusieurs étapes, alors l'étape N+1 ne sera lancée que si l'étape N s'est correctement exécutée.

NB : la clé allow_failure : true permet de ne pas impacter la suite au niveau d'un job

stages:
  - etape_1
  - etape_2

mail_admin:
  script: "echo 'push sur master' | mail -s 'push sur master' contact@kgaut.net"
  stage: etape_1
  only:
    - master
fail:
  script: "lorem"
  stage: etape_1

mail_2:
  script: "echo 'coucou' | mail -s 'push une branche' contact+test@kgaut.net"
  stage: etape_2

• Test d'une application php : https://docs.gitlab.com/ee/ci/examples/php.html
• Création et déploiement d'une build : https://docs.gitlab.com/ee/ci/examples/deployment/composer-npm-deploy.h…

Au push :

1. Le runner va se connecter à notre serveur distant
2. Il va exécuter une ou plusieurs commande commande
3. Nous en retournera le résultat

Genérer une clé SSH :

sudo -u gitlab-runner -H ssh-keygen -t rsa -C "contact@kgaut.net"

Ajouter la clé au trousseau du serveur distant

sudo -u gitlab-runner -H ssh-copy-id user@serveur

Note : Il peut être pratique d'ajouter cette clé dans /etc/skel/.ssh/authorized_keys.

Tester

sudo -u gitlab-runner -H ssh user@serveur

Génération d'une clée :

ssh-keygen -t rsa -C "contact@kgaut.net"

cat .ssh/id_rsa.pub

Ajout de cette clé aux clés de déploiements du dépôt.

Serveur :
User :
Password :

Script bash qui sera executé sur le serveur distant :

ssh user@serveur 'bash -s' < scripts/prod-deployment.sh

• Le script sera versionné.
• Langage "bash"

#!/bin/bash
set -e
cd /home/slides_kgaut_net
~/vendor/bin/drush @sli sql-dump --gzip > db/`date +%Y-%m-%d_%H-%M-%S`-slides.kgaut.net-drush.sql.gz
git pull
composer install
composer install
cd web
~/vendor/bin/drush @sli updb -y
~/vendor/bin/drush @sli cr
~/vendor/bin/drush @sli config-import

git clone git@github.com:kgaut/silex-composer-example.git
git remote rm origin
git remote add origin ...
git push -u origin master