Au début…
La première version de ce blog statique était mise en production manuellement :
-
Construction et test du site en local, sur ma machine de développement.
-
Déploiement du site construit via
rsync.
Pour les besoins d’un blog perso, ça suffit amplement. Cependant, ce blog servant également à faire des tests, je voulus aller plus loin.
Déploiement continu V1
Ce blog étant initialement hébergé sur un beau serveur dédié Dedibox, il y avait la place pour d’autres services. Entre autres, Gitorious et Jenkins.
La premier script de déploiement continu fut donc l’occasion de tester (et d’approuver) les pipelines.
Plus tard, le code fut migré vers Bitbucket, un des premiers hébergeurs à proposer des dépôts privés gratuitement. Le pipeline de déploiement a été conservé sur Jenkins.
Vers Gitlab
D’autres offres existent :
C’est cette dernière option qui m’a convaincu de migrer l’hébergement des sources du blog. Elle m’a également fourni un remplaçant plus simple au pipeline Jenkins de déploiement continu. L’existence de ce remplaçant a aidé à la décision d’abandonner la Dédibox.
Il ne restait plus qu’à écrire le script de déploiement .gitlab-ci.yml.
Je me suis pour cela inspiré de la documentation et des posts de Philippe Charrière.
image: ruby:2.6
stages:
- build
- deploy
variables:
JEKYLL_ENV: production
LC_ALL: C.UTF-8
cache: (1)
paths:
- /vendor
before_script:
- gem install bundler
- 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )' (2)
build:
stage: build
script:
- bundle install --path=/vendor
- bundle exec jekyll build -d blog
artifacts: (3)
paths:
- blog
deploy:
stage: deploy
script:
- mkdir .ssh
- chmod 700 .ssh
- echo $KNOWN_HOSTS > .ssh/known_hosts (4)
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | ssh-add -
- "scp -r blog $BLOG_USER@$BLOG_SERVER:" (5)
dependencies: (3)
- build
only:
- master| 1 | L’utilisation du cache permet de conserver les gems d’un build au suivant. |
| 2 | Précaution non nécessaire pour cette image, qui contient déjà ssh-agent. |
| 3 | La déclaration d’un artefact dans une étape de build permet de réutiliser celui-ci dans une étape ultérieure, via une dépendance. |
| 4 | Utilisation des secrets Gitlab : les variables définies dans le projet sont injectées lors de l’exécution du script. |
| 5 | rsync est plus adapté, mais n’est pas installé par défaut dans l’image ruby. |
Avec ce pipeline, le site est construit à chaque push sur Gitlab, et la branche master déployée automatiquement.
Conclusion
Ce nouveau script de déploiement me donne plainement satisfaction, en particulier pour sa simplicité : un seul service (Gitlab) gère le code, l’intégration continue, et le déploiement.
Une alternative aurait pu être d’utiliser Cloudbess Codeship. Mais cette solution aurait nécessité un service supplémentaire. C’est la raison pour laquelle je me suis plutôt orienté vers Gitlab, dont j’apprécie la simplicité et l’approche "tout en un".