Environnements et deploiements
GitLab modelise les environnements de deploiement (staging, production, review apps) dans l'interface. Chaque deploiement est trace, visualisable et potentiellement reversible depuis GitLab sans acces direct aux systemes cibles.
Definition d'un environnement
deploy-staging:
stage: deploy
script:
- ./deploy.sh staging
environment:
name: staging
url: https://staging.example.com
rules:
- if: $CI_COMMIT_BRANCH == "develop"
deploy-production:
stage: deploy
script:
- ./deploy.sh production
environment:
name: production
url: https://example.com
rules:
- if: $CI_COMMIT_BRANCH == "main"
when: manualReview Apps
Les Review Apps deployent automatiquement une instance de l'application pour chaque MR. GitLab affiche un bouton "View app" directement dans la MR. L'environnement est nomme dynamiquement (review/$CI_COMMIT_REF_SLUG) et nettoye a la fermeture de la MR.
review:
stage: deploy
script:
- ./deploy-review.sh $CI_COMMIT_REF_SLUG
environment:
name: review/$CI_COMMIT_REF_SLUG
url: https://$CI_COMMIT_REF_SLUG.review.example.com
on_stop: stop-review
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
stop-review:
stage: deploy
script:
- ./teardown-review.sh $CI_COMMIT_REF_SLUG
environment:
name: review/$CI_COMMIT_REF_SLUG
action: stop
when: manualHistorique des deploiements
GitLab conserve l'historique des deploiements par environnement : qui a declenche quoi, quand, depuis quel commit. La page Environments affiche l'etat actuel de chaque environnement (version deployee, commit, date). Un rollback se fait en re-declenchant un pipeline sur un commit anterieur ou via le bouton "Re-deploy" dans l'interface.
Environnements proteges
Un environnement peut etre protege : seuls les membres ayant un role specifique (Maintainer, Owner) peuvent declencher des deploiements vers cet environnement. Cela empeche un Developer de pousser directement en production. Les variables d'environnement peuvent egalement etre restreintes aux environnements proteges.