Les environnements Gitlab-CI
Publié le : 11 mai 2021 | Mis à jour le : 27 juin 2023Pendant le développement d’un logiciel, il peut y avoir de nombreuses étapes jusqu’à ce qu’il soit prêt pour la production. Vous voulez certainement d’abord tester votre code, puis le déployer dans un environnement de test ou de préproduction avant de le publier sur la production.
GitLab-CI a introduit les environments pour permettre de suivre facilement les déploiements pour chacun d’eux. Pour chaque déploiement, vous pouvez voir le commit associé ainsi aue la branche pour laquelle il a été créé. GitLab-CI permet de faire des rollback pour remettre vos environments à l’état avant déploiement.
Il est possible d’indiquer pour chaque environment une url permettant de se rendre directement sur l’application déployée.
Nous verrons qu’il est possible de restreindre des environnements à des branches spécifiques.
Il existe deux types d’environnement:
- Les environnements statiques ont des noms statiques comme
staging
,testing
,development
, ou encoreproduction
. - Les environnements dynamiques ont des noms dynamiques utilisant des variables CI/CD
Création d’environnements statiques
Il est possible de créer des environnements statiques soit :
- dans l’interface de gitlab : Operations > Environments > New Environment
- dans votre fichier
.gitlab-ci.yml
deploy_staging:
stage: deploy
script:
- echo "Deploy to staging server"
environment:
name: staging
url: https://staging.example.com
Choissisez un nom claire permettant d’iddentifier facilement le niveau de votre environnemen.
Introduit dans la version 13.10 de gitlab, il est possible de choisir des noms en dehors de ceux indiqué ci-dessus en ajoutant le mot clé deployment_tier. Cette clé indique le niveau de l’environnement :
deploy:
script: echo
environment:
name: customer-portal
deployment_tier: production
On peut donc enfin crée des environments multi-clients.
Création d’environnements dynamiques
Cette fois ces environnements ne sont créés que dans le fichier .gitlab-ci.yml
:
deploy_review:
stage: deploy
script:
- echo "Deploy a review app"
environment:
name: review/$CI_COMMIT_REF_NAME
url: https://$CI_ENVIRONMENT_SLUG.example.com
Variables CI/CD propre aux environments
Lorsque vous créer un environment, vous indiquez son nom et son URL. Si vous souhaitez les utiliser dans vos scripts alors ils sont accessibles via les noms de variables suivants :
- $CI_ENVIRONMENT_NAME.
- $CI_ENVIRONMENT_SLUG. un nom d’environement propre et unique qui peut être utilisé dans les DNS ou les URL.
- $CI_ENVIRONMENT_URL.
Il est possible de surcharger la variable $CI_ENVIRONMENT_NAME
mais la
variable $CI_ENVIRONMENT_SLUG
restera inchangé pour éviter les effets de
bords.
Restreindre un environnement à une ou des branches spécifiques
Avec l’ajout de rules gitlab-ci il est possible de restreindre des environnements à des branches définies.
Par exemple si nous souhaitons déployer sur l’environment
review\$CI_COMMIT_REF_NAME
ci-dessus toutes les branches à l’exeption de la
banche master :
deploy_review:
stage: deploy
script:
- echo "Deploy a review app on $CI_ENVIRONMENT_SLUG"
environment:
name: review/$CI_COMMIT_REF_NAME
url: https://$CI_ENVIRONMENT_SLUG.example.com
only:
- branches
except:
- master
Par contre si on ne souhaite déployer que sur la production que la branche master:
deploy_prod:
stage: deploy
script:
- echo "Deploy on prod"
environment:
name: production
url: https://www.example.com
only:
- master
when: manual
Vous pouvez aussi ajouter la condition when: manual
pour ne pas déclencher
automatiquement ce déploiement en production.
Stopper un environment
Il est possible de stopper un environment mais pour cela il faut que dans votre
ci contienne une étiquette on_stop: nom de l'étape
et une action: stop
associé:
deploy_review:
stage: deploy
script:
- echo "Deploy a review app"
environment:
name: review/$CI_COMMIT_REF_NAME
url: https://$CI_ENVIRONMENT_SLUG.example.com
on_stop: stop_review
rules:
- if: $CI_MERGE_REQUEST_ID
stop_review:
stage: deploy
script:
- echo "Remove review app"
environment:
name: review/$CI_COMMIT_REF_NAME
action: stop
rules:
- if: $CI_MERGE_REQUEST_ID
when: manual
Il est également possible de stopper un environment au bout d’un certain temps
via l’ajout de l’étiquette auto_stop_in: 1 week
review_app:
script: deploy-review-app
environment:
name: review/$CI_COMMIT_REF_NAME
on_stop: stop_review_app
auto_stop_in: 1 week
rules:
- if: $CI_MERGE_REQUEST_ID
stop_review_app:
script: stop-review-app
environment:
name: review/$CI_COMMIT_REF_NAME
action: stop
rules:
- if: $CI_MERGE_REQUEST_ID
when: manual
Si vous souhaiter que cette durée soit prolongé il faut se rendre dans l’interface de gitlab : Operations > Environments et d’épingler celui-ci.
Faire un rollback d’un environment
Comme dis plus haut il est possible de faire un rollback d’environment. Pour que cela fonctionne correctement il faut que vos scripts le gère correctement.